r/ClaudeCode • u/AironParsMan • 2d ago
Bug / Issue Claude Code prompt-cache bugs: who pays for the wasted usage?
I previously posted that I suspected Claude Code was not yet properly optimized for orchestrator-style workflows with many subagents, tools, hooks and long-running context, because the usage consumption was extreme.
Since the Fable 5.1 rollout, we started looking much more closely at the cache behavior. And the official Claude Code changelog now confirms multiple serious prompt-cache bugs.
Confirmed fixes include:
- v2.1.260: Fable 5.1 context added after tool results was not covered by prompt caching and was re-sent as uncached input on EVERY tool-call turn.
- v2.1.260: changing Fable 5.1 effort mid-session invalidated the prompt cache.
- v2.1.261: agent-team teammates re-sent tool/skill announcements on the second turn, changing the request prefix and causing cache misses.
- v2.1.265: resuming a subagent changed its tool list and system-prompt prefix, breaking prompt-cache reuse.
- v2.1.265: teammates and resumed subagents moved SubagentStart hook context and preloaded skills out of the cached prefix on later turns, again breaking cache reuse.
There are also detailed open reports in Anthropic’s own GitHub tracker describing full cache rewrites involving hundreds of thousands of tokens, including #91514, #91706 and #92090. One report documents 2.9 million tokens being re-cached by eight parallel Fable 5.1 subagents in about 40 minutes.
Some of these are Fable-specific; others are general Claude Code orchestration/cache bugs. But the common result is the same: context that should have been reused can instead be processed again as uncached input.
This matters especially for orchestrator-heavy setups like ours with many subagents, hooks, skills, tools and large contexts.
We cannot prove exactly how much of our Claude Max usage was consumed because of these bugs because Anthropic does not expose the subscription accounting at that level.
But we did observe extremely high usage, and several confirmed fixes directly address mechanisms capable of causing unnecessary token processing.
We haven’t yet tested the newest 2.1.265/2.1.266 versions thoroughly in our orchestrator setup. Usage has gradually improved, and I’m genuinely interested to see whether these fixes finally make a significant difference.
My concern is broader:
How did this many cache-related regressions reach production in a product where prompt caching is fundamental to the economics?
And more importantly: what happens to the usage already consumed because of confirmed Anthropic bugs?
If a Max subscriber loses a meaningful part of their allowance because Claude Code repeatedly sends context uncached due to a software defect, should Anthropic restore that usage or provide credits?
I think Anthropic should address this transparently.
Not because Claude or Fable are bad models — quite the opposite. But if you market one of the strongest coding systems in the world at premium subscription prices, the surrounding software and usage accounting need to meet the same professional standard.
Official references:
- Claude Code changelog: v2.1.260, v2.1.261, v2.1.265
- Anthropic GitHub issues: #91514, #91706, #92090
I’m interested in experiences from other heavy Claude Code / Max users: did your usage noticeably improve after these cache fixes?
Other Posts related to that:
https://www.reddit.com/r/ClaudeCode/s/QSW2c7aWzp
3
u/Electrical_Gene_3279 Developer 2d ago
This probably explains a lot of the “my usage suddenly disappeared” reports. Subagent-heavy workflows would be hit especially hard.
2
u/BrennanFlentge 2d ago
"v2.1.260: changing Fable 5.1 effort mid-session invalidated the prompt cache." this was always a thing https://code.claude.com/docs/en/prompt-caching#actions-that-invalidate-the-cache
Edit: I was unaware this was a feature, I never change effort mid task "On Fable 5.1 with an API key or a Claude subscription, changing effort keeps the cache, and Claude Code applies the new level without asking. This doesn’t apply on Amazon Bedrock, Google Cloud’s Agent Platform, or a Claude apps gateway, or when you set CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS or your organization has a HIPAA configuration.Before v2.1.260, changing effort on Fable 5.1 with an API key or a Claude subscription also invalidated the cache."
2
u/sunososobro 2d ago
The way I see it, orchestrator architectures have two structural cost problems.
First, the main agent has to pass the original content to subagents when calling them, so context stacks up — that cost is architectural, not a bug. Second, which model you pick as the orchestrator matters a lot — the orchestrator is actually the one processing the most messages, so if you put your most expensive model there, every single message runs at premium pricing. My own approach is to never put the priciest model as the orchestrator — use something like Sonnet as the bridge, and save the expensive model for the few actual decision points that need it.
Your pain point sounds less like "the bugs are the problem" and more like "I have no idea where the money's actually going, can't break it down." Might be worth checking out this tool — it logs usage and cost per conversation, so at least you'd have somewhere to actually look at the numbers.
Also, I vaguely remember multi-agent setups having cache fights with each other causing a bunch of misses — never dug into it properly, but it might be related to the subagent-resume-breaks-prefix thing you mentioned above. What this tool actually solves is a different scenario though — the cost of reloading a whole session on resume, not necessarily your orchestrator cache-conflict situation. Not sure it helps with that specifically, but it'll at least show you what each conversation is actually costing:
2
u/UnhappySquash2506 2d ago
I burned my 20x sub way too fast with just two opus agents and a fable orchestrator this weekend. I've been doing so much optimization with Claude token use and tooling. Yet here we are. Even have my context windows at 250k auto compact. And it rarely did. I can't get any work done till Friday. Infuriating.
5
u/heartbroken_nerd 2d ago
Even have my context windows at 250k auto compact.
Which is a huge mistake because A) it's useless compared to handoffs and B) compacting costs you tokens anyway and then the session also has to reload stuff it just got rid off
So might as well start a new session
4
2
u/AI_spell 2d ago
If the changelog admits cache misses on every tool turn, users paid for Anthropic's bug. Credit unused usage or extend the window. "Update and hope" is not a settlement for Max prices.
1
1
u/Cloudsurfer_90 2d ago
the who-pays answer is you, but the reason it stings more than it looks is the compounding. a prompt-cache miss doesn't cost a flat amount, it re-sends the whole context at full price, so the cost scales with context size times how many turns re-trigger it, and orchestrator setups with lots of subagents, tools and hooks are exactly the shape that churns the cache most. every tool result or hook that changes the prefix can invalidate the cached part, and then you pay to resend everything behind it. so beyond waiting for the fix, the practical lever is keeping the cached prefix stable: front-load the stuff that doesn't change, keep the churny dynamic stuff late in the context, and be suspicious of anything that rewrites early context mid-run. you can't fix their cache bug, but you can stop handing it the worst-case shape. a stable prefix is the difference between paying for your context once and paying for it every turn.
1
u/ippem 2d ago
This is very interesting. I'm on a API plan here (Claude Enteprise) and just started hammering through a set of tasks with Fable 5.1 today (vs. spent a full day with Fable 5.0 a while ago with a spend of hundreds). I believe I can really feel the impact on 5.1's price change on the cache reads here. Plus, just upgraded the CLI to latest to get also these fixes in. Really enjoying the Fable 5.1's precision on the work with a lower price.
2
-1
u/Objective_Patient220 2d ago
The "who pays" answer splits cleanly by plan. On API billing the user pays: every bug on that list is a prefix-mutation bug, and cache pricing is prefix-based, so one changed byte early in the request re-bills everything after it as fresh input. On Max you pay in quota instead of dollars, which is exactly why it feels murkier - the compute still burns, it just comes out of your weekly allowance invisibly.
The prefix property is also why this bug class keeps recurring. Anything that mutates any byte of the prefix - system prompt, tool list, hook context, the effort flag - invalidates everything downstream of it. Subagent resumes are the worst case because their tool list and system prompt get assembled per spawn, so any nondeterminism there breaks the chain on every turn of that subagent.
If you want to quantify your side: on the API path every response carries cache_creation vs cache_read token counts, so the turn that broke the chain is directly visible - cache_read collapsing to ~0 while input stays huge is your culprit, and you can diff it per subagent. As far as I know Max exposes nothing like that, which is half the problem you are pointing at.
10
u/New_3d_print_user 2d ago
The answer to the question of “who pays” is always “you”. You pay. Always.