[BUG] Excessive token consumption

github actions is incorrectly marking these reports as invalid.

+1. Max 20, v2.1.89. April 1: 100% in ~70 min after reset. Months of same workflow, never happened before.

Full report: #41788
Related: #38335, #38239, #41663, #40652

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 just had this experience this morning, i was fine yesterday, this morning i upgraded to the extension in VS Code to the latest version

Identifier: anthropic.claude-code
Version: 2.1.89

And boom within 1hr, i had exhausted my tokens with about 10 prompts, as well as incurred extra API Call charges.

Follow-up — precautions (April 2, 2026)

Since my root cause comment, here are additional behaviors that compound the problem:

Avoid: --resume (replays full history as billable input), /dream & /insights (silent background drain), v2.1.89 (cache bug + terminal regression)
Careful: sub-agents (Haiku = 0% cache read), multiple terminals, large context files
Recommended: v2.1.81 fixed + fresh sessions + local proxy

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

Will give it a test and see how we do. I hit the other issue with backend agents this morning. Hopefully upgrading to the v2.1.90 will improve the token usage/cache issues.

@dbrunet73 Good luck with the v2.1.90 test. One tip: if you want to measure the actual improvement, set ANTHROPIC_BASE_URL to a logging proxy before testing so you can compare cache read ratios directly. That way you'll know if the cache fix is working on your setup vs. hitting a different issue.

v2.1.88 vs v2.1.90 Cache Comparison — Real-world OTel data (April 2, 2026)

After hitting the cache bug on v2.1.88 this morning, I upgraded to v2.1.90 and compared using OTel telemetry logs. Here are the hour-by-hour results:

| Hour (CDT) | Version | Requests | Cache Hit % | Health |
|---|---|---|---|---|
| 05:00 | 2.1.88 | 114 | 94.1% | Healthy |
| 06:00 | 2.1.88 | 209 | 98.8% | Healthy |
| 07:00 | 2.1.88 | 125 | 78.0% | ⚠️ WARNING |
| 08-09 | — | — | Hit 5-hour rate limit | — |
| 10:00 | 2.1.90 | 141 | 97.7% | ✅ Healthy |
| 11:00 | 2.1.90 | 138 | 97.2% | ✅ Healthy |
| 12:00 | 2.1.90 | 21 | 99.7% | ✅ Healthy |
| 13:00 | 2.1.90 | 30 | 86.9% | ✅ Healthy |

Version Summary:

| Metric | v2.1.88 | v2.1.90 |
|---|---|---|
| Requests | 448 | 330 |
| Cache Hit Rate | 89.7% | 97.1% |
| Cache Creation | 10.2M tokens | 1.2M tokens |
| Est. Input Cost | $183.42 | $78.74 |

Key findings:

• v2.1.88 degraded to 78% at 07:00 with an 8.9M token cache creation spike — it was re-creating caches instead of reading them, which burned through my 5-hour rate limit by 7 AM
• v2.1.90 is consistently 97%+ across all hours with no degradation
• Cache creation tokens dropped 8x (10.2M → 1.2M) — the old version was wastefully re-creating prompt caches
• Cost per request improved from ~$0.41 to ~$0.24

Confirming @ArkNill's findings — v2.1.90 fixes the client-side cache drain. The 3-hour gap in my data is because v2.1.88 exhausted my token quota, forcing a cooldown before I could resume on v2.1.90.

Environment: VS Code extension, Max plan, Opus model, Windows 11.

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

Session bloat is often the root cause — each turn re-sends accumulated tool results, thinking blocks, and metadata that inflate token counts silently. Cozempic prunes this automatically with 18 strategies — lossless, nothing meaningful is removed.

Sessions typically run 3-4x longer and cost 2-3x less. The guard daemon auto-starts on every session.

pip install cozempic && cozempic init

Feedback welcome.

They sort of fixed it in 2.1.91, but now I think the problem is returning. No idea if it is still caching, but credits go quicker and weirder. Today I turned on computer, immediately went to Claude's usage page (not making any queries, no code session, nothing) and what do I see? My session started 30 minutes ago and I have spent 10% of session usage. Impossible.

Then I proceeded to usual stuff, nothing out of ordinary, and quickly reached 100%, and was charged $10 extra credits. Turned off extra credits as a feature, and everything continued to work as usual, with more credits than normal, but it never said that I would require extra credits for something. Meaning that there are deeper flaws in how credits are calculated and how account is charged. I wonder if the new "Mythic" model wrote the latest version of Claude Code. In that case it's really dangerous.

There were still issues with the /resume in these versions, so if you were doing that, it would have still eaten up all your tokens, this only fixed it for the standard sessions. V2.1.101 has fixes for the resume functionality.

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

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.