93% rate limit consumed in ~3 minutes on fresh session (Max plan, v2.1.85)
Status Closed — not planned
Reported on v2.1.85
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 14 comments · opened Mar 27, 2026 · closed May 12, 2026
Environment
- Plan: Claude Max
- Model: Claude Opus 4.6 (1M context)
- Claude Code version: 2.1.85 (VS Code extension, win32-x64)
- OS: Windows 11 Home 10.0.26200
- Interface: VS Code extension (not terminal CLI)
What happened
Opened a fresh Claude Code session in VS Code. Within approximately 3 minutes and ~10 light exchanges, the 5-hour session rate limit hit 93%. Weekly usage jumped from ~2% to 9% (weekly had just reset the night before).
What the session actually contained
- A few short conversational messages
- Several
ToolSearchcalls (searching for MCP tool schemas — most returned empty) - One
Readof a ~130-line Python file - One
Bashexecution of that Python script - One
Grep+ oneBashto find a regex pattern in a JS file - One small
Editto update the Python file - Two small
Agentspawns (research-only, no code generation — one Explore agent, one claude-code-guide agent)
This is normal light usage that typically runs for hours without approaching rate limits.
Context window at time of issue
/context output showed:
- Tokens used: 55.4k / 1M (6%)
- Messages: 19.8k tokens
- Free space: 919.5k (92%)
So the context window was nearly empty. This was not a long-running session that accumulated cost over time.
Verification
- Only one
claude.exeprocess running (confirmed viatasklist) - No background agents or rogue processes
- No prior session on this machine — previous session was on a different PC, ended 4+ hours earlier, and that machine was powered off
- The session was resumed after a VS Code restart (extension update from prior version to 2.1.85), but the full conversation history from the fresh start is visible — nothing hidden or carried over
Expected behavior
This level of usage on a Max plan with Opus 4.6 should consume a small fraction of the 5-hour rate limit, not 93%.
Possible factors
- This occurred immediately after updating to v2.1.85
- The session used
--resumeafter a VS Code restart (for a spellcheck patch), but the entire conversation from the initial "hey" is visible in context - A large number of MCP servers are loaded (deferred tools totaling ~76k tokens of schema), though these are deferred and shouldn't be billed as output
14 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Update — the 93% was phantom usage. Confirmed by waiting out the reset.
After waiting the full 5-hour cooldown, the session reset. Resuming work in the same conversation, I ran a full farm operations check — 10 API calls to a feed bin monitoring service, 6 rooms of water/temperature data, email scan + 3 email reads + 2 attachment downloads, an xlsx parse, a PDF read, and a multi-section document update. This is significantly more work than the original 3-minute session that triggered 93%.
Result: 12% session usage. That's what real work looks like on this plan.
The original 93% was not real token consumption — it was a metering/billing error. The usage display even briefly showed "Not authenticated" and "Session 0%" during the transition before re-authenticating and showing the correct 12%.
Impact: 5 hours of dead time on a Friday waiting for a phantom rate limit to expire. On a Max plan ($200/month) specifically purchased for heavy usage.
Yeh, im hitting abnormal usage too...
Normally 1x 5 hour limit is 8% for my total week.. During promo it was 5-6%...
Today? Its 14 fking percent... Thats HALF my usage per week...
What the actual fk is going on here???????
Max20 here...
My Claude says your issue is similar to issues #38239, #37917, #39465, #39492, #39803. Let Anthropic know about this so your issues get more attention. However, since I haven't been able to update for the past 4 days, I'm not sure whether they have fixed this issue yet.
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_URLenv 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
<img width="583" height="360" alt="Image" src="https://github.com/user-attachments/assets/2cea7f11-1d83-4a8b-8301-7f9456da7905" />
Done in ~3 days and i slowed down the last day and i was on .88. and .89...
Zero difference for me... Thats about HALF my usage this week...
This is max20... 200 usd per month... Unacceptable....
Everyone should cancel their sub, even if you intend to resume it in x weeks? Cancel it... If 10-100k of us do it? It will be statistically big enough to force their hand... Its the only way at this point...
For me, 01/04/2026, this morning: rate limit 100% exhausted in ~50 minutes. I waited 4 hours and the rate limit was 100% exhausted again with a single prompt.
Follow-up — precautions (April 2, 2026)
93% in ~3 minutes on fresh session = cache completely broken. Additional precautions:
Avoid:
--resume,/dream,/insights, v2.1.89Careful: sub-agents (Haiku = 0% cache read, 317K/31 calls), multiple terminals, large CLAUDE.md
Use: v2.1.81 fixed + fresh sessions + proxy monitoring (
ANTHROPIC_BASE_URL)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:
claude update(ornpm install -g @anthropic-ai/claude-code)"DISABLE_AUTOUPDATER": "1"to~/.claude/settings.jsonenv section--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
A user in #40584 may have found the root cause for your rate limit issue. Two findings:
See #40584 for the full analysis with log evidence from two independent occurrences.
@marlvinvu Good cross-reference. See my response in #40438 — the #40584 client-side rate limiter bug and the cache regression (#40524/#34629) are two separate issues that both cause rapid drain through different mechanisms.
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.