[Bug] Excessive token consumption rate - usage depleting faster than expected

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/41200
2. https://github.com/anthropics/claude-code/issues/39966
3. https://github.com/anthropics/claude-code/issues/41145

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

About ten days ago, when everything still worked normally, even the Free plan would give 1–2 hour sessions in agent mode via MCP, using Sonnet 4.6 with extended thinking. At that time, weekly usage quota would be fully exhausted within two days (during off-peak hours).
Now, a Sonnet session (without extended thinking) terminates after just ONE request with 3–4 tool calls — yet weekly quota limit does NOT run out.
This suggests that sessions are not being terminated by actual token-limit exhaustion, but by something else. In other words, this is likely a bug, not a new policy from management that's suddenly become greedy.
I really hope that's the case. Maybe they'll actually fix it... :(

Came to think of it: maybe the issue isn't the token quota, but the rate limit — i.e., requests-per-minute throttling. Not just slowing down, but hard-cutting without explanation (jerks).
Just tested: turned out both limits are in play.
Short version: made requests strictly one tool call per turn. Managed 27 (!!!) elementary requests total. Session exhausted in ~30 minutes — but at least it showed the infamous 90% token-quota depletion. Still off-peak hour. Sonnet 4.6, no extended thinking.
This is, of course, much better than instant exhaustion after one request — but still a sad fraction compared to what worked 10 days ago. And this looks less like a bug, and more like capitalism baring its teeth.
That's about it, I guess... :((

also experiencing the same issue

Same issue on my side, I am using 110 EUR plan and Today even starting the conversation with simple question costs me around 3% of my tokens.

Same here. Max 20 ($200/mo), v2.1.89. April 1: 100% in ~70 min after reset with light conversational coding. Never happened before in months of subscription.

Full report: #41788
Related: #38335, #38239, #40790, #6457, #40895, #41055, #38345, #41174, #41550, #41617, #41663, #41666, #41779, #41802

I've been experiencing the same issue on Max 20 ($200/mo) — rate limit 100% exhausted in ~70 minutes.

After setting up a monitoring proxy using the official ANTHROPIC_BASE_URL env var, I identified two cache bugs as the root cause (#40524, #34629) and measured the impact: cache read ratio dropped to 4.3%, meaning ~20x token inflation per turn. After applying workarounds it stabilized at 89-99%.

Full analysis with per-request measured data, safe workarounds, and community references (including cc-cache-fix): https://github.com/ArkNill/claude-code-cache-analysis

I can confirm usage has spiked drastically recently.
I set it to low and asked it to commit a couple of files and it used 20% of my Session Usage.
I submitted a Plan and it jumped from 0% to 40% immediatelty.
I don't think I'm using any MCP's, tools or skills that would explain this recent jump or spikes in usage.
I can't even do a 30 minute session without it eating up all my Usage and I'm already 31% into my weekly usage from 3 Sessions.

Follow-up — precautions (April 2, 2026)

Additional behaviors that accelerate the drain beyond the cache bugs:

Avoid: --resume (token bomb — replays full history), /dream & /insights (background drain), v2.1.89 (cache bug persists + terminal regression)
Careful with: sub-agents/Haiku calls (0% cache read), multiple terminals (parallel drain)
Recommended: v2.1.81 fixed + fresh sessions + proxy monitoring

Even with cache at 91-99%, some users report faster drain than before — suggesting a server-side change in addition to the client bugs.

Ref: https://github.com/ArkNill/claude-code-cache-analysis

Update (April 2): v2.1.90 has significantly improved cache efficiency — benchmark shows 95-99% cache read in stable sessions (both npm and standalone installations).

If you're still affected:

1. Update: claude update (or npm install -g @anthropic-ai/claude-code)
2. Pin the version: add "DISABLE_AUTOUPDATER": "1" to ~/.claude/settings.json env section
3. Avoid --resume (still broken)

Note: server-side quota issues (org-level pool sharing, accounting mismatches) remain unresolved — the above fixes the client-side cache drain only.

Benchmark data: https://github.com/ArkNill/claude-code-cache-analysis

Additional data point confirming this regression

Timeline: Same as others - started ~2 weeks ago (mid-March 2026)

Impact:

• Before: Could run 3-4 parallel Claude Code sessions, full day of work
• Now: Single session for ~1 hour, 15% battery from two trivial commands

Concrete example - ls -la command:

• Tokens used: ~6,000 (3% of 200K budget)
• Expected: ~1,000 (500 result + 300 response + 200 overhead)
• Excess overhead: 5,000 tokens that should be cached

Evidence of regression:
User has RTK (Rust Token Killer) tracking tool with historical baseline showing this is a 3-4x increase across all command types, not just perception.

Environment:

• Model: claude-sonnet-4-5-20250929
• Platform: macOS (Darwin 25.3.0)
• Version: (current)

This is blocking productive work. User mentioned "anthropic have admitted to a bug causing extra token usage" - is there an update on the fix ETA?

@SC7639 The 6K tokens on a simple ls -la makes sense once you factor in how Claude Code works under the hood. Every turn sends your entire conversation history to the API — so that 5K "overhead" isn't the command itself, it's the accumulated context from previous turns being re-transmitted. Normally Anthropic's prompt caching means ~90% of that re-sent context is billed at 1/10th price, so you'd barely notice. But the bug we've been tracking (#40524, #34629) broke that caching — when cache read drops to near 0%, every token on every turn gets billed at full price. That's the 3-4x you're seeing in your RTK baseline.

Based on my controlled benchmarks and the v2.1.90 changelog (which mentions prompt cache improvements), v2.1.90 appears to have addressed the client-side cache regression. In my testing, cache read ratio went from 4-17% on v2.1.89 to 95-99% on v2.1.90 (benchmark data). If you haven't updated yet (claude --version to check), it's worth trying. After updating, your RTK logs should show a clear before/after difference if it's the same root cause. If the overhead doesn't drop, that points to a separate issue — possibly the server-side accounting change that's still unresolved, or something Sonnet-specific. Most of the benchmarking so far has been on Opus, and cache dynamics (breakpoint placement, TTL behavior) could differ on Sonnet.

On the Anthropic admission — do you have a link? I'd like to reference it. Just to be clear, I'm not affiliated with Anthropic — I'm a Max 20 subscriber who got hit by the same bug and started digging into it because I was losing $200/mo worth of quota in 70 minutes. Everything in the analysis repo is community-driven. So unfortunately I don't have any ETA either, and Anthropic hasn't responded to any of the 90+ issues I've been tracking.

Full analysis: https://github.com/ArkNill/claude-code-cache-analysis

Brief update (April 3): v2.1.91 is out and cache behavior is further improved — npm and standalone now perform identically (Sentinel gap closed). However, testing revealed two additional unfixed bugs: a 200K tool result budget cap that silently truncates older results, and a client-side false rate limiter generating <synthetic> errors without API calls (151 entries confirmed). If you are still seeing drain after updating, these are the likely causes. Details: claude-code-cache-analysis

Token depletion faster than expected is typically caused by session bloat compounding — each API call re-sends accumulated progress ticks, stale tool results, and duplicate content.

Cozempic v1.4.1 has 17 pruning strategies that target each bloat type. The guard daemon runs automatically via SessionStart hook. Measured 85-95% savings with compact-summary-collapse on compacted sessions.

pip install cozempic && cozempic init

One session alone used 25% of my token quota. In under 24 hours, the entire 100% was depleted. Additionally, the responses were unhelpful as the model kept repeating the same steps rather than properly addressing my queries. I'm on Claude Code.

Additional datapoint from a Windows + local-runtime workflow:

What made this especially visible for me was not just the Max-plan meter, but the combination of cache instability plus a larger fixed prompt baseline when Claude Code was acting as a bridge into a local long-context stack.

In that setup, the regression shows up in two places at once:

• the cloud-side usage/quota burns much faster than expected
• the practical usable context on the local side shrinks earlier than it used to

So from operator perspective this did not feel like a "meter only" issue. When the cache path was unstable, the cost spike was obvious. But even outside the worst spikes, a bigger always-on prefix still made long sessions feel materially worse.

That is why I think the reports in this family are probably mixing two related effects:

1. genuine cache/accounting regressions
2. a persistent fixed prompt tax that becomes very visible on longer or bridged workflows

Both matter in practice, especially on Windows setups where people are often already juggling native CC, WSL, or local runtime bridges.