A ban that was really about a cache hit rate

The setup: a very good deal that couldn’t last

OpenClaw was an open-source agent harness — think of it as a wrapper that drives Claude in long, autonomous loops to get work done. It let you authenticate with your normal Claude subscription instead of an API key. On paper, that’s a fantastic deal for an indie developer. A Max 20x plan is a flat $200/month. The same volume of Opus tokens, billed through the API, could easily run well past $1,000 a month for a heavy user.

That spread is the arbitrage. Anthropic priced its subscriptions for humans typing in a chat window and doing some coding, not for automated agents running long reasoning loops all day. When a tool let you point those agents at your flat-rate subscription, you were buying wholesale compute at retail-chat prices. That was never going to last.

But the price gap isn’t the explanation Anthropic led with. It led with caching.

Prompt caching, and why Claude Code is built around it

Every time you send a request to a large language model, the model has to process your entire prompt (system instructions, tool definitions, conversation history, all of it) before it generates a single new token. For a long agent session, that prompt can balloon to hundreds of thousands of tokens. Reprocessing all of it on every turn is wasteful, because most of it hasn’t changed since the last turn.

Prompt caching is the fix. Anthropic and the other providers cache the stable prefix of your prompt and, on the next request, skip reprocessing the part that’s identical. The economics are steep: a cache read costs roughly a tenth of what it costs to process those same tokens fresh, so a cache hit is about 10x cheaper than a cache miss. At that ratio, a high cache hit rate is what keeps a flat subscription profitable. (Whether caching pays off on a given workload — the write premium, the read discount, the break-even — is its own subject; Prompt Caching Explained works it out.)

Anthropic has been explicit about how central this is to Claude Code. In an engineering post, the team wrote: “At Claude Code, we build our entire harness around prompt caching… we run alerts on our prompt cache hit rate and declare SEVs if they’re too low.” A SEV is an incident, the kind of thing that pages engineers at 3 a.m.

The catch is that caching is fragile. The cache matches on an exact, byte-for-byte prefix. Change one thing near the front of the prompt (a timestamp, the order of your tool definitions, a stray capital letter) and everything after it is invalidated. You pay full price to reprocess the whole tail. Claude Code is built carefully around this: static content goes first, updates get injected as messages instead of edits to the system prompt, tools never change mid-session, tool lists are sorted deterministically. All of it keeps that prefix byte-stable so the cache keeps hitting.

Where the third-party tools went wrong

Third-party harnesses weren’t built with that discipline, and it showed. OpenClaw’s own issue tracker is the best evidence. One report measured a real session across 143 consecutive API calls: the cache was written on 96% of requests but read on only 10.5%. Almost every request was reprocessing 100,000-plus tokens from scratch. The cause was mundane. Dynamic content like the current time and runtime info was packed into the same block as the static system prompt, so the prefix changed on every turn and busted the entire cache.

Another OpenClaw issue captured the same failure from the cost side: cache writes swamping cache reads, with calls billing $0.35–0.50 each against an expected $0.02–0.04 — in some cases $0.51 for zero output tokens. The trigger was a release that compacted skill file paths in the system prompt, a small structural change near the front of the request that was enough to break the byte-exact prefix and invalidate the cache on every turn. Same work, an order of magnitude more expensive — the exact kind of read-side prefix break covered in troubleshooting a stuck cache.

Now put yourself in Anthropic’s position. Someone on a flat $200 plan is running an agent that, because of a cache bug, burns 3 to 10 times the compute a well-behaved client would. Multiply that across an estimated 135,000 OpenClaw instances and the flat plan stops paying for itself.

Did Anthropic actually fix the caching, or just blame it?

Boris Cherny, who leads Claude Code at Anthropic, didn’t just cite caching in a press statement. He opened three pull requests against OpenClaw to fix it: compacting the newest tool results first to preserve the cached prefix, sorting MCP tools deterministically, and delaying image pruning so recent history stayed byte-identical. They were merged. Cherny said he’d “just put up a few [pull requests] to improve prompt cache efficiency for OpenClaw specifically” and that “this is more about engineering constraints.”

And those PRs give you something concrete to check: named commits fixing named cache bugs.

And that keeps the story on caching, where it belongs. A flat subscription only works if the client keeps the cache warm, and an agent that busts the prefix on every turn breaks the arithmetic the plan was priced on. You can debate how much of Anthropic’s decision was about protecting revenue, but the mechanism stands on its own: an OpenClaw session cost more than an equivalent Claude Code session because of cache misses, and the fix was to stop generating them. Anthropic later reinstated third-party agents through metered “Agent SDK credits”, which moves that same efficiency cost from their books onto yours. One more reason to keep your own cache warm.

Why this is your problem too

The lesson underneath the drama applies to every provider on your invoice, not just Anthropic.

Your effective token price is a function of your cache hit rate, and you probably aren’t watching it. The same workload cost one OpenClaw user 10x more before a caching fix than after, with no change in output. That variance doesn’t go away when the tool you’re using is polished; it just gets harder to see. If you’re paying per token through any API, whether Anthropic, OpenAI, or Gemini, a low cache hit rate is money leaking on every call, and it never shows up as a line item that says “wasted.” It shows up as a total higher than you expected.

A cache hit rate is also easy to lose track of, because the dashboards that would tell you live in a dozen separate consoles you have to log into one at a time. It’s the kind of number you go looking for only once something feels off, and by then you often find out the way those OpenClaw users did: after the bill arrives.

That’s the case for putting the number in front of you before the invoice does. Whether you’re piping Opus through an agent, generating audio on ElevenLabs, or renting GPUs on RunPod, the pattern is the same. The providers optimize for their own margins, the efficiency traps are invisible until you measure them — the hidden economics of AI coding is full of them — and no one is going to page you when your costs triple. For a solo developer paying out of pocket, watching that number is the difference between a normal month and one ten times higher. Tracking AI costs across providers is how you keep it in view.

Anthropic banned OpenClaw over a cache hit rate. You should know yours.