[BUG] Extreme Token Burn with Claude Code CLI - Normal Work Impossible!

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 followed your advice meticulously but it didnt help. From my point of view, what they call "adjusting limits" is a de facto price increase. Same plan, same price, less output. What worked fine for me until last Friday doesn't work on Tuesday — and there's nothing wrong on my side.

1. v2.1.68 + npm
2. 1:14pm in Germany = 4:14am PT — well outside the stated peak hours right now still have the problem.
3. Paying 200 bucks for what 100 bucks already covered — completely unreasonable.

How is that reasonable to have a contract for a service that fits my needs and for which I accept a certain pricing and I start to develop with it but then I am basically cut off in the middle of my project because the limits dont allow me to progress? To me this honestly feels like a scam. If I sell you a service for a monthly price and at some point I just say "Ha now you just get a quarter of the service for the same money" -> what would you call that?

Thanks for trying the downgrade — sorry it didn't help in your case.

A quick clarification: all my testing and the workarounds I shared were done strictly in the CLI environment (claude command in terminal on Linux). I haven't tested with the VSCode extension or Claude Code Desktop, and the cache behavior may differ there.

A couple of follow-up questions that might help narrow it down:

1. Which environment are you using? — CLI (claude in terminal), VSCode extension, or Desktop app?
2. After downgrading to v2.1.68, did you verify with the monitoring proxy that the cache read ratio actually improved? The downgrade alone doesn't guarantee the fix — the proxy data is what confirms whether the cache bug is the root cause in your setup.

If your cache read ratio is already healthy (80%+) even on the latest version, then the token drain you're seeing may have a different root cause than the cache bugs I identified.

Thx mate!

1. I am also working in Linux Ubuntu 24 on CLI environment (classic terminal)
2. Yes did that and currently I am around 87% so that looks fine (8 out of 10 last sessions are 91-99% cache read ratio, the other two were just too short for meaningful results, 3- and 2-turn sessions .. quick tests)

Follow-up to @peterhaehnel-codes — you're right, and thanks for confirming.

The cache fix alone doesn't fully solve it. After more investigation, I've identified that there are two layers to this problem:

1. Client-side cache bug (fixable) — restores cache read to 89-99%, reducing per-turn cost significantly
2. Server-side factor (not fixable from our end) — even with cache working perfectly, the rate limit consumption is faster than it was ~2 weeks ago. This suggests Anthropic changed either the limit pool size, the cost weighting formula, or both — without any announcement.

Additional precautions that help reduce the drain

Even with or without the cache fix, these behaviors dramatically accelerate consumption:

Avoid entirely:

• --resume — replays your full conversation history as billable input. A single resume on a long session can burn 500K+ tokens instantly
• /dream and /insights — trigger background API calls that consume tokens without visible output
• v2.1.89 — still has the cache bug + a new terminal rendering regression

Be careful with:

• Sub-agents (parallel Agent tool calls) — Haiku sub-agent calls get 0% cache read. I measured 317K input tokens across just 31 calls
• Multiple terminals — each is an independent session, drains quota ~2x
• Large CLAUDE.md — sent as input every single turn, keep it lean

Recommended:

• Start fresh sessions (don't resume), use CLAUDE.md to restore context
• Monitor via local proxy (ANTHROPIC_BASE_URL) — at least you can see what's happening
• One terminal at a time, minimize sub-agent use

This won't fully solve the server-side problem, but it stretches whatever budget we have left significantly further.

Updated analysis: 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

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

Was using v2.1.92 for like 4 days and was pretty ok with the token usage (not happy but ok!). Today the whole issue is recurring AGAIN -> Burning through tokens like there is no tomorrow on version v2.1.92 + and this was not happening before Claude (and I am not jsut talking about Opus 4.6 but also Sonnet) act clueless... things that worked flawlessly are totally broken -> I would simply describe it as if Claude has only 20% of its brain power anymore... it's misbehaving at multiple levels.

GUYS THIS IS SERIOUS, WE ARE USING CLAUDE CODE FOR WORK!!!! How long shall this continue? We are not your testing ground, we are paying customers!!!

Me too. Utterly unworkable now.

Bug Description
Massive token usage by CC Cli for simple local actions in Pro account. Session limit hit in a flash, half of weekly allowance used up, it also consumed £21.27 in Extra Usage credits. This can't be right. Something is eating all my allowance - using Sonnet on medium and Haiku should not burn credit like this - because it never has before for the simple local work I do. Something is very wrong.

Environment Info

Platform: linux
Terminal: konsole
Version: 2.1.114
Feedback ID: 76c9e695-5d1b-4b3b-803e-8b2532b70318
Errors

[{"error":"Error: 429 {\"type\":\"error\",\"error\":{\"type\":\"rate_limit_error\",\"message\":\"This request would exceed your account's rate limit. Please try again later.\"},

Also via the app, without CLI, Claude Code can burn tens of thousands of token without producing any output. One month ago it was the best coding tool, today it is useless without constant micromanagement.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

It seems the same issue is back. I just burned through the 5-hour limit (max 5x), outside of peak-hours, in less than 1 hour. And didn't even do any real work, but just had it read a couple of short text files, run one research agent and give me some text-output in an HTML.