[BUG] Max x20 plan — 5-hour quota consumed in ~10 prompts (started March 14, 2026)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/34145
2. https://github.com/anthropics/claude-code/issues/33752
3. https://github.com/anthropics/claude-code/issues/34287

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

A ticket is open : 215473481043220

Problem solved with a plausible explanation:
My Claude sessions had been running for several days. On the 14th, a new default model with 1M context became available. All my local Claude sessions were still running the old 1M context model. Five models were listed in the model selector. I exited all my sessions (logout/login), selected the new 1M context model as default, and everything went back to normal.
My plausible explanation: token consumption for the old model became bugged after the new model was deployed. That said, this behavior is not normal — existing sessions on the old model shouldn't break when a new one is rolled out.

Worth noting: prompt caches are likely per-account and won't carry across accounts. If you tested including the switching between your three subscriptions, each first call on each account was a cold cache hit at whatever context size was loaded. At high context, a cold prefill is significantly more expensive than a warm one. You also mention your sessions had been running for days, meaning any idle gap longer than the cache TTL

<details>
<summary>
1 hour according to my testing and their API doc
</summary>

I was about to state >5m and say that through my personal research found to be more than 5 minutes, but huh, in my tests the lifetime of the ephemeral_5m_input_tokens stated in the jsonl files would live more than 5m, but now they're all 0 in my files and ephemeral_1h_input_tokens is non-zero, so it must be that this was a bug, so let's assume cache lives for 1h for Claude Code, and that the ephemeral_5m_input_tokens in my testings was wrongfully returned and was actually 1h.

</details>

would result in a cold prefill over the entire accumulated session context.

Switching accounts during your observations likely meant some of your data points were cold calls, which is the most expensive scenario. This would also stack on top of the old model's long-context surcharge (2x input, 1.5x output for >200k tokens) that was only removed for the new Opus 4.6 and Sonnet 4.6.

Your resolution (exit all sessions, switch model, things go back to normal) also can't be attributed to the model switch alone. You may have changed three variables at once: the model, the context size (fresh session vs days-old accumulated context), and the cache state (cold to warm after first call). Starting a fresh session on the old model might have produced the same result.

Do you think this could possibly be it? Or can you rule it out and attest that your observations did not span across different historicalchat sessions nor accounts?

confirmed this is still happening as of 3/23/2026 9am. only had Claude code app opened over night. it seems to be Claude code app related as I hadn't had this problem in the terminal, even leaving them open for days. and i just switched to Claude Code App and it happened the next day.

Summery: investigate Claude Code App as it seems to be the culprit.

Same. Max 20, v2.1.89, April 1: 100% in ~70 min after reset. ~10 prompts is all it takes.

Full report: #41788
Related: #38335, #38239, #40790, #41055, #41663

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

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

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.