[BUG] Excessive token consumption since 2.1.88 — 66% usage in 2 questions (Max 5x, Opus 4.6)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/41506
2. https://github.com/anthropics/claude-code/issues/41504
3. https://github.com/anthropics/claude-code/issues/41479

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I've been investigating this exact issue extensively. The root cause is two client-side cache bugs that inflate billable tokens by 10-20x:

Bug 1 — Sentinel Cache Prefix Corruption (Standalone Binary)

The standalone binary (claude) replaces cache breakpoint hashes with cch=00000 during build, which breaks the cache prefix matching. This means the API never gets a cache hit on your conversation history — every turn re-sends the entire context as billable input tokens. See #40524 for the original report.

Bug 2 — Resume / deferred_tools_delta Cache Miss

Since v2.1.69, the deferred_tools_delta feature reorders tool results in the conversation payload when resuming a session. This reordering invalidates the cache prefix, causing a full cache miss on session resume. See #34629.

How to verify

If you can inspect your API traffic (e.g., via a local proxy), check the cache_read_input_tokens vs input_tokens ratio. With the bug active, cache_read_input_tokens will be near zero — meaning every token is billed at full price.

Workaround

I patched v2.1.81 to fix the cache prefix logic and run it behind a local monitoring proxy. After the fix, my cache read ratio went from ~0% to 89-99%, and token consumption returned to normal levels.

Full analysis, reproduction steps, and patch details are in my public repo:
👉 https://github.com/ArkNill/claude-code-cache-analysis

This affects all Max plan users on the standalone binary. Anthropic has not officially acknowledged or fixed either bug as of today.

Update (April 2): Much of the perceived Opus 4.6 consumption spike was likely compounded by the cache bug (Sentinel regression in standalone binary). v2.1.90 fixes this — benchmark shows 95-99% cache read in stable sessions, dramatically reducing effective token cost.

Update to v2.1.90 to isolate actual model cost from cache bug overhead: https://github.com/ArkNill/claude-code-cache-analysis

April 3 update: v2.1.91 fixes the cache regression that caused the worst drain. If you are still hitting limits after updating, there are additional unfixed mechanisms: a 200K tool result budget cap, a client-side false rate limiter, and silent context stripping — all confirmed via proxy testing. Anthropic acknowledged peak-hour tightening on X (Lydia Hallie) but stated "none were over-charging you." Measured data and analysis: claude-code-cache-analysis

👍 #45333

The problem is back and worse than ever. Token consumption on max $100 at 20x. I was forced to upgrade to max $200. Very unhappy as this appears to be punishment for max users that attempted to manage token use. I will be experimenting with Codex now as a alternative as Anthropic has broken my trust.

What’s confusing a lot of people here is that it feels like Claude is “re-reading” everything every turn, but that’s not actually what’s happening.

The context is cached, but it still gets resent with each request. The key detail is that cache reads are not free. They are cheaper than fresh tokens, but they still count toward your quota.

So when you have something like a large CLAUDE.md plus tool schemas, you are starting every turn with a 30–40K token payload before any new work is done. That payload gets included again on every message, which is why usage spikes so quickly even for small interactions.

That is also why it looks like a regression. It is not just what you send once, it is what gets replayed every turn that drives total consumption.

Makes sense. However, when I switched back to Max $200/20x subscription from the Max $100/5x, the behavior complete changed back to what I had experienced last week. The change was not 15x but more like 50-60x.

I am not surprised that Anthropic has attempted to slow the token quantities with the newer price point and a massive increase in subscribers. It would have been nice for them to come clean so I didn’t debug wasting hours.

~ sean

On Apr 10, 2026, at 11:13, Camj78 @.***> wrote: Camj78 left a comment (anthropics/claude-code#42272) <https://github.com/anthropics/claude-code/issues/42272#issuecomment-4225806017> What’s confusing a lot of people here is that it feels like Claude is “re-reading” everything every turn, but that’s not actually what’s happening. The context is cached, but it still gets resent with each request. The key detail is that cache reads are not free. They are cheaper than fresh tokens, but they still count toward your quota. So when you have something like a large CLAUDE.md plus tool schemas, you are starting every turn with a 30–40K token payload before any new work is done. That payload gets included again on every message, which is why usage spikes so quickly even for small interactions. That is also why it looks like a regression. It is not just what you send once, it is what gets replayed every turn that drives total consumption. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/42272#issuecomment-4225806017>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJDAOQP4JN32OEK5OUIYD34VE2TPAVCNFSM6AAAAACXJZ5ICWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMRVHAYDMMBRG4>. You are receiving this because you commented.

@sarob Yeah, that’s the part that makes this hard to reason about. Once the behavior changes that much between plan tiers, it stops feeling like normal cache overhead alone.

A 50–60x swing is big enough that I would not assume it is just CLAUDE.md size or session length. It could still be some interaction between cache behavior, model routing, session packaging, or plan-specific limits, but from the outside it definitely looks inconsistent.

Did you happen to compare the same repo, same CLAUDE.md, and roughly the same workflow on both plans? That would make the signal a lot stronger.

Exactly that. I am finishing up an agent fleet buildout. So very similar repo work over the past couple of weeks. ~ SeanOn Apr 10, 2026, at 11:55, Camj78 @.***> wrote:Camj78 left a comment (anthropics/claude-code#42272)
@sarob Yeah, that’s the part that makes this hard to reason about. Once the behavior changes that much between plan tiers, it stops feeling like normal cache overhead alone.
A 50–60x swing is big enough that I would not assume it is just CLAUDE.md size or session length. It could still be some interaction between cache behavior, model routing, session packaging, or plan-specific limits, but from the outside it definitely looks inconsistent.
Did you happen to compare the same repo, same CLAUDE.md, and roughly the same workflow on both plans? That would make the signal a lot stronger.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

@sarob That makes it a lot more interesting then, because that removes most of the usual variables.

If the repo, CLAUDE.md, and workflow are roughly the same, then a 50–60x swing usually means something changed in how the session is being packaged or counted, not just the raw prompt size itself.

One thing I started doing was breaking down how much of each request was new tokens versus reused context, just to see where the growth was actually coming from. In a few cases it looked stable on the surface, but the reused portion was compounding way faster than expected.

Have you been able to see where the majority of your tokens are coming from, or is it mostly just showing up as total usage?

I am pushing to meet multiple deadlines, so I am not doing my normal analysis. Once I pass through the horizon of milestones, I will definitely dig in. ~ SeanOn Apr 10, 2026, at 12:40, Sean Roberts @.> wrote:Exactly that. I am finishing up an agent fleet buildout. So very similar repo work over the past couple of weeks. ~ SeanOn Apr 10, 2026, at 11:55, Camj78 @.> wrote:Camj78 left a comment (anthropics/claude-code#42272)
@sarob Yeah, that’s the part that makes this hard to reason about. Once the behavior changes that much between plan tiers, it stops feeling like normal cache overhead alone.
A 50–60x swing is big enough that I would not assume it is just CLAUDE.md size or session length. It could still be some interaction between cache behavior, model routing, session packaging, or plan-specific limits, but from the outside it definitely looks inconsistent.
Did you happen to compare the same repo, same CLAUDE.md, and roughly the same workflow on both plans? That would make the signal a lot stronger.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

@sarob That makes sense. This is also exactly the kind of situation where it gets frustrating, because by the time you have bandwidth to dig in, the session context is already gone or hard to reconstruct.

I ran into that a few times and ended up just instrumenting my prompts to see the breakdown before sending them, mainly to understand how much was static context versus actual new input.

It made a pretty big difference just being able to see “this request is mostly reused context” before running it, instead of trying to debug it afterward.

If you end up digging into it later, I would be curious what you find. This feels like one of those cases where the numbers tell a very different story than what it looks like on the surface.

My assumption, increasing weights against token counts for subscription classes during peak periods to avoid horizontal scaling falling behind demand. Keep the Max x20 customers happy. The rest get rate limited.

@sarob Yeah I’ve seen a few people land on that conclusion, especially when the behavior lines up with plan changes like that.

The tricky part is from the outside it’s really hard to separate intentional throttling from how the system is actually packaging and counting tokens under the hood. Both can look very similar in practice.

What made it click for me was realizing how much the reused context portion can dominate without being obvious. Two runs can feel identical, but if one is carrying a much larger cached payload, the total usage can look completely disproportionate.

That’s why I ended up focusing more on breaking down where the tokens were actually coming from rather than trying to infer intent from the totals.

Adding a Max 20x data point to this thread.

Continuous Max subscriber since 2025-11-25, upgraded to Max 20x on
2026-02-12, ~$872 billed total. Affected client: Claude Code 2.1.126
(darwin-arm64), bundled in Antigravity IDE extension — within the
2.1.88+ range this issue describes.

Local evidence captured 2026-05-03 (Beijing time):

• Zero jsonl writes in ~/.claude/projects/* between 00:00 and 17:46
• ccusage shows 65-hour activity gap before next session start
• No background claude processes, no hooks, no cron jobs, no launchd
• Settings.json contains only deny rules and an autocompact env var
• Yet Max 20x session quota dashboard showed continued consumption

during the 16:00–17:30 idle window

After "Log out of all devices" + uninstalling iOS app + enabling 2FA,
the unattended drain stopped — consistent with the multi-device
amplification pattern others have reported.

Opened support ticket on 2026-05-03, Conversation ID 215474159922311.
Received four consecutive Fin AI Agent responses. The fourth reply
explicitly stated: "I'm an AI assistant and cannot process escalations
or guarantee human review outcomes." No human review has occurred.

Requesting:

1. Confirmation of whether the OpenClaw/Hermes (April 2026) compensation

precedent applies to subscribers affected by this issue.

1. A working escalation path for Max subscribers when support@ is

captured by Fin AI Agent.

Org ID: 87295fc3-3e7f-43ad-b67a-2e8be2b50dfd

jsonl mtimes, Antigravity extension logs, and Active sessions
screenshots available to a human reviewer.

This appears to be hallucinations from your bug reporting bot. Very likely a stray process caused the token burn. Cron jobs need consistent human oversight. I suggest langfuse and LLM load balancing. ~ SeanOn May 3, 2026, at 07:50, FelixWayne0318 @.***> wrote:FelixWayne0318 left a comment (anthropics/claude-code#42272)
Adding a Max 20x data point to this thread.
Continuous Max subscriber since 2025-11-25, upgraded to Max 20x on
2026-02-12, ~$872 billed total. Affected client: Claude Code 2.1.126
(darwin-arm64), bundled in Antigravity IDE extension — within the
2.1.88+ range this issue describes.
Local evidence captured 2026-05-03 (Beijing time):

Zero jsonl writes in ~/.claude/projects/* between 00:00 and 17:46
ccusage shows 65-hour activity gap before next session start
No background claude processes, no hooks, no cron jobs, no launchd
Settings.json contains only deny rules and an autocompact env var
Yet Max 20x session quota dashboard showed continued consumption
during the 16:00–17:30 idle window

After "Log out of all devices" + uninstalling iOS app + enabling 2FA,
the unattended drain stopped — consistent with the multi-device
amplification pattern others have reported.
Opened support ticket on 2026-05-03, Conversation ID 215474159922311.
Received four consecutive Fin AI Agent responses. The fourth reply
explicitly stated: "I'm an AI assistant and cannot process escalations
or guarantee human review outcomes." No human review has occurred.
Requesting:

Confirmation of whether the OpenClaw/Hermes (April 2026) compensation
precedent applies to subscribers affected by this issue.
A working escalation path for Max subscribers when support@ is
captured by Fin AI Agent.

Org ID: 87295fc3-3e7f-43ad-b67a-2e8be2b50dfd
jsonl mtimes, Antigravity extension logs, and Active sessions
screenshots available to a human reviewer.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

66% usage in 2 questions is brutal. A big part of this is accumulated context — tool outputs, file reads, and metadata all compound with each turn. Cozempic's guard daemon runs continuously and prunes this bloat across 18 strategies, so each API call sends only what is still relevant. pip install cozempic https://github.com/Ruya-AI/cozempic — let me know if it helps.

We are also seeing higher token usage by a significant factor.

We are using litellm -> bedrock

Also, prompt caching appears to be significantly missing all of a sudden as well.