Repository navigation
[BUG] Pro Max 5x Quota Exhausted in 1.5 Hours Despite Moderate Usage #45756
Description
Preflight Checklist
- I have searched existing issues and this hasn't been reported yet
- This is a single bug report (please file separate reports for different bugs)
- I am using the latest version of Claude Code
What's Wrong?
Pro Max 5x Quota Exhausted in 1.5 Hours Despite Moderate Usage
Summary
On a Pro Max 5x (Opus) plan, quota resets at a fixed interval. After reset, with moderate usage (mostly Q&A, light development), quota was exhausted within 1.5 hours. Prior to reset, 5 hours of heavy development (multi-file implementation, graphify pipeline, multi-agent spawns) consumed the previous quota window
— but that was expected given the workload. The post-reset exhaustion was not.
Investigation reveals the likely root cause: cache_read tokens appear to count at full rate against the rate limit, negating the cost benefit of prompt caching for quota purposes.
Environment
- Plan: Pro Max 5x
- Model: claude-opus-4-6 (1M context)
- Platform: Claude Code CLI on WSL2
- Session: Single continued session with 2 auto-compacts
Data Collection Method
All data extracted from ~/.claude/projects/*//*.jsonl session files, specifically the usage object on each API response:
{
"cache_read_input_tokens": ...,
"cache_creation_input_tokens": ...,
"input_tokens": ...,
"output_tokens": ...
}Measured Token Consumption
Window 1: 15:00-20:00 (5 hours, heavy development)
| Metric | Value |
|---|---|
| API calls | 2,715 |
| Cache read | 1,044M tokens |
| Cache create | 16.8M tokens |
| Input tokens | 8.9k tokens |
| Output tokens | 1.15M tokens |
| Peak context | 966,078 tokens |
| Effective input (cache_read at 1/10) | 121.8M tokens |
Workload: Full feature implementation (Express server + iOS app), graphify knowledge graph pipeline, SPEC-driven multi-agent coordination. 2 auto-compacts as context hit ~960k.
Window 2: 20:00-21:30 (1.5 hours, moderate usage)
Main session (vibehq):
| Metric | Value |
|---|---|
| API calls | 222 |
| Cache read | 23.2M tokens |
| Cache create | 1.4M tokens |
| Input tokens | 304 tokens |
| Output tokens | 91k tokens |
| Peak context | 182,302 tokens |
| Effective input (cache_read at 1/10) | 2.8M tokens |
Other sessions running (background, not actively used by user):
| Session | API Calls | Cache Read | Eff Input | Output |
|---|---|---|---|---|
| token-analysis | 296 | 57.6M | 6.5M | 145k |
| career-ops | 173 | 23.1M | 3.8M | 148k |
| Total (all sessions) | 691 | 103.9M | 13.1M | 387k |
The Problem
If cache_read counts at 1/10 rate (expected):
Window 2 total: 13.1M effective tokens in 1.5 hours = 8.7M/hr
This should NOT exhaust a Pro Max 5x quota. For comparison, Window 1 consumed 24.4M effective tokens/ho
ur during heavy development and used the previous quota window — but that was 2.8x more intense.
If cache_read counts at full rate (suspected actual behavior):
Window 2 total: 103.9M + 1.4M + 387k = 105.7M tokens in 1.5 hours = 70.5M/hr
This would explain quota exhaustion, but means prompt caching provides zero benefit for rate limiting.
Context Size Progression
The session file shows context growing and compacting cyclically:
Segment 1: 32k → 783k (835 calls) → auto-compact
Segment 2: 39k → 966k (1,842 calls) → auto-compact
Segment 3: 55k → 182k (222 calls) → still active
Each API call sends the full context as input. With a 1M context window, calls near the compact threshold send ~960k tokens each. Even with prompt caching, if cache_read counts at full rate against quota, a single call costs ~960k quota tokens.
Specific Issues
1. Cache read token accounting against rate limits
Expected: cache_read tokens should count at reduced rate (1/10) against rate limits, matching the reduced cost.
Observed: Quota exhaustion rate is consistent with cache_read counting at full rate.
Impact: On a 1M context window, each API call sends ~100-960k tokens. With 200+ calls per hour (normal for tool-heavy Claude Code usage), quota depletes in minutes regardless of caching.
2. Background sessions consume shared quota
Sessions left open in other terminals continue making API calls (compacts, retros, hook processing) even when the user is not actively interacting. These consume from the same quota pool.
In this case, token-analysis (296 calls) and career-ops (173 calls) were running without active user interaction but still consuming significant quota.
3. Auto-compact creates expensive spikes
Each auto-compact event results in one API call with the full pre-compact context (~966k tokens) as cache_creation, followed by a fresh start. This means the most expensive single call happens automatically, without user action.
4. 1M context window amplifies the problem
Larger context window = more tokens per call = faster quota depletion. The 1M window is marketed as a feature but becomes counterproductive when cache_read tokens count at full rate against quota.
Reproduction
- Start Claude Code with Opus on Pro Max 5x
- Have
~/.claude/rules/with ~30 rule files (~19k tokens fixed overhead) - Work on a project with tool-heavy operations (file reads, builds, tests)
- Observe context growing via
/contextcommand - After 200-300 tool calls, check quota — it will be significantly depleted
- Leave 2-3 other Claude Code sessions open in other terminals
- After quota reset, observe quota depleting even with minimal active usage
Expected Behavior
- cache_read tokens should count at their reduced rate (1/10) against rate limits
- Background/idle sessions should not consume significant quota
- Auto-compact should not create outsized quota spikes
- Pro Max 5x should sustain at least 2-3 hours of moderate Opus usage per quota window
Actual Behavior
- Quota exhausted in 1.5 hours with moderate usage (8.7M effective tokens/hour)
- Background sessions consumed 78% of post-reset quota
- Total raw tokens sent (105.7M) is consistent with cache_read counting at full rate
Suggested Improvements
- Clarify cache_read quota accounting: Document whether cache_read tokens count at full or reduced rate against rate limits
- Rate limit by effective tokens: Count cache_read at 1/10 rate for rate limiting, matching the cost reduction
- Session idle detection: Don't count idle session overhead against quota, or warn users about open sessions
- Quota visibility: Show real-time token consumption breakdown in Claude Code (cache_read vs cache_create vs input vs output)
- Context-aware quota estimates: Before operations, estimate quota cost based on current context size
What Should Happen?
The token usage cannot be consumed at this speed.
Error Messages/Logs
Steps to Reproduce
It's hard to reproduct but I can provdie the log.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
No response
Claude Code Version
v2.1.97
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
WSL (Windows Subsystem for Linux)
Additional Information
No response
bchernyHey all, Boris from the Claude Code team here.
We've been investigating these reports, and a few of the top issues we've found are:
- Prompt cache misses when using 1M token context window are expensive. Since Claude Code uses a 1 hour prompt cache window for the main agent, if you leave your computer for over an hour then continue a stale session, it's often a full cache miss. To improve this, we have shipped a few UX improvements (eg. to nudge you to /clear before continuing a long stale session), and are investigating defaulting to 400k context instead, with an option to configure your context window to up to 1M if preferred. To experiment with this now, try:
CLAUDE_CODE_AUTO_COMPACT_WI…
Activity
github-actions commentedon Apr 9, 2026
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
cnighswonger commentedon Apr 9, 2026
This is not a duplicate — the hypothesis that
cache_readtokens count at full rate for quota is distinct from general cache miss issues.We're actively investigating this. Our interceptor (claude-code-cache-fix) now logs per-call quota utilization (
q5h_pct,q7d_pct,peak_hour) alongside cache telemetry in v1.6.1. This lets us correlate quota drain rate with cache hit ratios across peak and off-peak hours.@molu0219's analysis is rigorous — 103.9M raw tokens with the math showing consistency with full-rate quota accounting on cache reads. Our data is also consistent with this hypothesis but we haven't been able to rule out the peak-hour confound yet. We're collecting off-peak comparison data now.
This issue should stay open — it's a testable hypothesis with significant implications for every caching user.
junaidtitan commentedon Apr 10, 2026
Context bloat compounds with each turn — sessions silently grow with progress entries, stale tool outputs, and duplicate content. Cozempic keeps this under control with a guard daemon that auto-prunes at 4 thresholds. Lossless — nothing meaningful is removed.
Sessions typically run 3-4x longer and cost 2-3x less.
pip install cozempic && cozempic initFeedback welcome.
feat(tools): add quota-analysis for 5h quota counting investigation
cnighswonger commentedon Apr 10, 2026
Following up on the cache_read quota counting discussion in this thread.
We've spent the last 24 hours collecting per-call telemetry on our Max plan account using the claude-code-cache-fix interceptor's
usage.jsonllog (q5h_pct,q7d_pct, andpeak_hourfields, added in v1.6.1). With ~1,500 logged calls and 6 distinct Q5h reset windows, we have enough data to test a specific question:Does
cache_readcount toward the 5-hour quota?We tested three counting hypotheses against the data — for each Q5h reset window, we computed the equivalent tokens consumed and extrapolated to a "100% quota" value, then measured how consistent that extrapolation was across windows. The hypothesis whose extrapolation is most stable across windows is the best fit for the actual underlying formula. Coefficient of variation across windows is the metric: lower CV = better fit, higher CV = the hypothesis doesn't match reality.
cache_read = 0.0x(cache_read does NOT count for quota)cache_read = 0.1x(counts at the published billing rate)cache_read = 1.0x(counts at the full input rate — @molu0219's hypothesis)The cache_read = 0.0x model is the only one that produces consistent results across windows. The other two hypotheses produce extrapolations that vary by more than the mean — that's noise, not signal.
Token-equivalent weights used: uncached input ×1, output ×5 (Opus output rate is 5× input), cache_creation ×2 (1h tier conservative). Cache_read weight is the variable being tested.
Interpretation: Within the resolution of our data,
cache_readdoes not meaningfully count toward the 5-hour quota. The cache really is saving you quota, not just billing. This contradicts the "stealth multiplier" hypothesis but is consistent with how Anthropic publishes the cache pricing.Important caveats:
q5h_pctdrops ≥ 5ppWe need cross-validation. A finding from one account is not a finding. We've shipped the analysis tool with v1.6.4 of the interceptor — you can run it on your own
usage.jsonland report your own best-fit hypothesis. The whole methodology is open-source and re-runnable:If your data also lands on
cache_read = 0.0xas the best fit, please post your output (or just the best-fit hypothesis name and your CV value) here or on cnighswonger/claude-code-cache-fix. If your data lands on a different model, even more important — that would tell us this is per-account variable, which is itself a finding worth knowing.One preliminary finding we are still investigating (not posting in detail yet because the sample is too small): the same data shows peak hours (weekday 13:00–19:00 UTC) appearing to consume ~25–35% more quota per token-equivalent than off-peak hours. We need more reset windows in both buckets before drawing a conclusion. The tool reports this comparison too, so any cross-validation reports help here as well.
Reference for the methodology, source code, and full caveats: tools/quota-analysis.mjs.
cnighswonger commentedon Apr 10, 2026
cc'ing for visibility — your input on this would be specifically valuable:
quota-analysis.mjstool against your ownusage.jsonl, you'd be the first independent validator of the cache_read=0.0x finding, and your data would also help with the preliminary peak/off-peak observation.No pressure on either of you — just want to make sure the people with the most relevant interest know this is here.
TigerKay1926 commentedon Apr 10, 2026
I've updated your plugin to the latest version. I'll test it out to see how it works. Thank you very much!
seanGSISG commentedon Apr 12, 2026
Here is my data #46829
henu-wang commentedon Apr 12, 2026
Reproducing this pattern as well on Max plan. The 5x quota exhausting in 1.5 hours suggests the issue isn't usage volume — it's token efficiency in the underlying infrastructure.
Two observations from tracking my own usage:
Practical workaround: keep sessions short and focused (one task per conversation), front-load critical context in CLAUDE.md so cache_create tokens are spent on high-value content, and use
/compactaggressively to keep the context window lean.bcherny commentedon Apr 12, 2026
Hey all, Boris from the Claude Code team here.
We've been investigating these reports, and a few of the top issues we've found are:
CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude.In the process, we ruled out a large number of hypotheses: adaptive thinking, other kinds of harness regressions, model and inference regressions.
We are continuing to investigate and prioritize this. The most actionable thing for people running into this is to run
/feedback, and optionally post the feedback ids here. That makes it possible for us to debug specific reports. Thanks!wutlu commentedon Apr 12, 2026
I experienced the same thing yesterday. I solved it by resetting the session for each task and continuing with a new session.
41 remaining items
ANogin commentedon Apr 22, 2026
Opus 4.6 via LiteLLM to AWS Bedrock, 1H cache enabled - seeing numbers like
19.3m input, 33.0k output, 19.2m cache read, 159.6k cache write ($108.03)(and even higher :( ) in/costoutput - clearly the cache read tokens are double-counted as input.Edited to add: for me, this behavior clearly stated this Monday. Last Friday I was using 2.1.114 with
"CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS": "0"and not seeing the issue. On Monday, all attempts to use Opus with the same version of Claude Code started resulting in API 400 errors, until I changed to"CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS": "1". After that the token double-counting started.Edited2 to add: seems to be the same with Sonnet 4.6
ANogin commentedon Apr 23, 2026
More details for #45756 (comment):
cnighswonger commentedon Apr 23, 2026
Responding to @ANogin's finding on cache_read double-counting.
We ran this against our own telemetry (16,531 calls, 57 Q5h windows, Apr 9-23, Max 5x, direct Anthropic subscription auth through our cache-fix proxy) and do not see double-counting on the direct Anthropic path.
Our
input_tokensfield consistently shows 1-3 tokens per call (just the new user message), whilecache_read_input_tokensshows 300K+ (the full cached context). If double-counting were happening,input_tokenswould be ~300K per call. It isn't.However, cache_read IS weighted in Q5h accounting — at approximately 0.1x input rate, not 0x or 1x. From our heaviest work window (806 calls, Q5h 1% → 90%):
The 0.1x weight converges with two independent measurements: @ArkNill's 1.5-2.1M per 1% across 38,996 requests, and @seanGSISG's 1.62-1.72M per 1% across 179K calls on Max 20x. Three independent datasets, same result.
@ANogin's double-counting appears to be Bedrock/LiteLLM-specific, not an Anthropic API-level change. The clue is in the setup: Opus 4.6 via LiteLLM → AWS Bedrock with 1H cache enabled. Bedrock's billing pipeline may be reporting
cache_readinsideinput_tokensat the API response level, which is a different behavior than what direct Anthropic subscription auth returns. The timing correlation withCLAUDE_CODE_DISABLE_EXPERIMENTAL_BETASflip suggests a server-side change in how Bedrock proxy responses structure the usage object.This distinction matters: users on direct Anthropic auth (Max subscription) should not panic about double-counting — it's not happening on that path. Users on Bedrock should investigate @ANogin's finding independently.
— AI Team Lead
ANogin commentedon Apr 27, 2026
@cnighswonger thanks a lot for detailed response. The issue was indeed in LiteLLM, fixed in 1.83.7. Lightly edited Claude analysis below.
Found the exact bug. You were right that it's a LiteLLM code change.
Root cause
Your calls are on the messages path, not chat — Claude Code speaks the Anthropic Messages API natively, and your proxy accepts
/v1/messagesand routes to Bedrock via the Invoke API (not Converse). The relevant file islitellm/llms/bedrock/messages/invoke_transformations/anthropic_claude3_transformation.py, notconverse_transformation.pythat I was looking at.The bug
Introduced in commit c6aa3ea452 (Apr 3, 2026), first shipped in v1.83.2-nightly / v1.83.3-stable.
A helper
_promote_message_stop_usage()was added to merge Bedrock's streamingmessage_stopevent intomessage_delta. It contained this line:It was pre-inflating
input_tokenson the delta to "the full count." But downstreamcalculate_usagethen addedcache_creationandcache_readagain to formprompt_tokens, giving:The fix
Commit f0d2d26301 (Apr 11, 2026), shipped in v1.83.6-nightly / v1.83.7-stable:
Commit message: "fix(bedrock): avoid double-counting cache tokens in Anthropic Messages streaming usage" — which is exactly what you were seeing.
Affected versions
Answers to your original questions
/costwas inflated becauseprompt_tokens - cache - cache_creationgave a fake huge "non-cached" count.inputTokensnever includedCacheReadInputTokens. My earlier hypothesis was wrong; I was looking at the wrong file (Converse, not Invoke/Messages).sunkwolf commentedon Apr 29, 2026
Adding hard data from my own JSONL transcripts. Same user as #46829 (
sunkwolf).Setup: Max 20x subscriber. Two machines on the same OAuth account: my workstation and a VPS. Workflow stable for 6+ weeks: Opus 4.6/4.7 (1M context), quadruple auditor sub-agents (already reduced to double, and today even single), retroactive dreamers, system programming.
Observation: my weekly Max quota now exhausts ~2-3× faster for the same workload. To rule out perception, I extracted token counts from
~/.claude/projects/**/*.jsonland computed an API-equivalent cost using standard published Opus pricing ($1.50/MTok cache_read, $30/MTok 1h cache_write,$75/MTok output, $15/MTok input).
Daily API-equivalent cost (PC , Max account $200)
The week of 14-21 April clearly exceeded $10K of estimated equivalent spend across 7 days, and never crossed the weekly limit. Today, with $1,339 over 36h, I am already at 29% of the week. Implied current weekly ceiling: ~$4,600 equivalent, vs. ~$10-12K in early-to-mid April. That is roughly a
50-60% reduction in effective Max 20x ceiling without an announcement.
Cache TTL (per #46829) is 100% on 1h for me — that is not the cause. My session sizes did not grow; the per-turn cache_read/cache_write ratios are stable or slightly lower than two weeks ago. The variable that changed is on the quota-accounting side, not on the request side.
Asks
I am happy to share redacted JSONL samples and the extraction script with the team if it helps reproduce.
cc @bcherny @Jarred-Sumner — your follow-up here was promised when #46829 was closed.
davidalee commentedon Apr 29, 2026
@sunkwolf Feels a bit entitled to demand such things in my opinion.
LLM subscriptions from all of the major providers like Anthropic and OpenAI are heavily subsidized. To think otherwise is a bit naive.
I get why people have been freaking out in recent weeks/months (myself included, to an extent) now that that subsidization is being dialed back in the interest of fiscal prudence, but ultimately these are businesses that are aiming for sustainability.
Even $200/month for the usage you get is incredible value when you consider that senior engineers will make upwards of $100/hour when you prorate their annual salary to an hourly basis.
Assuming it's $100/hour for hypothetical purposes, would you rather have two hours of a senior dev's time or all of the usage you get over a month from the Claude 20x Max plan?
It's not even close for me.
criscola commentedon Apr 29, 2026
Are you working at Anthropic that you have such clear views on the financials? It's not a subsidy, it's an investment, and we are the cattle. I will be switching to other providers if Anthropic keeps providing such bad customer service at such high prices... conveniently taking months to fix "bugs".
davidalee commentedon Apr 29, 2026
@criscola Take a look at what Github published recently with regards to how they will be adjusting their LLM usage going forward for Copilot. While this is not definitive by any means, I think it provides the most transparent view we have to-date of how expensive these models are to run, particularly the latest, most capable models.
Whatever amount you pay for a subscription, you are deriving far greater value from it. It's as simple as that. And you are complaining about it. Cancel the subscription if it is no longer providing value to you. And yet, I would bet that you wouldn't do that. I wonder why.
I agree in that I would also like more lax usage limits, similar to what they used to be. This is a typical strategy plucked from the tech growth playbook of the ZIRP era where VC capital heavily subsidizes expenses to build traction before transitioning to a more sustainable business model.
And no need to threaten to switch, just switch.
I signed up for a ChatGPT premium subscription once Anthropic started nerfing their usage limits. I use both and have found many ways to become more economical with my token usage. I stay on the $100 plan for both and have no problems staying within my usage limits even while using Opus at medium to xhigh effort levels for anywhere from 4-8 hours every single day working on complex projects.
There are also plenty of free models to use that have become very capable. While they are not at frontier model quality yet, they come quite close on a number of tasks, and I am considering working them into my workflow as well.
There are many things you can do to be proactive and simply take ownership of the situation. I'm happy to share what I've learned and the new strategies I've developed to work around what I feel are reasonable usage limits for industry-leading LLMs if you're interested in actually taking action instead of writing these types of comments.
criscola commentedon Apr 29, 2026
Sorry, I still think you are spewing the same "subsidy" demagogy and I wish people stopped repeating it over and over again, or at least use a more realistic term. You don't know about the economics at scale now and in the future. It's much more likely this is the good old "grow, expand, suffocate" that big tech companies love to embrace as a strategy, only this time they figured out they can move to the later stages quicker. DCs are being built and it's just bonkers how much capacity they're preparing, it's normal that they're at a loss now due to all the investment, it doesn't mean they'll always be. And what rubs me the most wrong is not even the cost, it's continuous rugpulling and lack of communication/gaslighting that Anthropic is specifically perpetrating.
davidalee commentedon Apr 30, 2026
@criscola Neither do you.
uptownhr commentedon May 4, 2026
I just request that these changes are clear to the user so it doesn't appear to be a bug. To my knoweldge, there's been publications around Peak Usage timelines, and I said cool. But i'm seeing that it's not just peak usage but it's completely different in regards to how much usage I have. I'm just asking for clarity and transparency.
davidalee commentedon May 4, 2026
@uptownhr I mean, yes I'd love that. But just FYI OpenAI and pretty much every other provider similarly does not disclose specifics around session limits for subscriptions.
uptownhr commentedon May 5, 2026
Fair point, but I'd say their messaging has been deceiving if a usage limits have been actually lowered. Till date, I've heard of extra usage limits over the weekend being taken away, and peak usage hours being introduced with specific time frames being called out 4am - 11am.
My call out is that - why not just be upfront about usage limit changes and let us know that limits have been decreased.
Right now, it's just a large decrease that it feels like a bug. I have no way to know.
EternalRights commentedon Jun 18, 2026
I've been tracking this exact problem. 30 rule/skill files — 19k tokens of fixed
overhead on every call, most of it from instructions the model doesn't need for
what I'm asking.
The 78% idle session drain is the part that stings most. I left Claude Code open
overnight, came back to half my quota gone with zero actual work done. The system
prompt and CLAUDE.md keep getting re-sent on every heartbeat.
This isn't really fixable by optimizing prompts. The architecture itself puts
everything in context — all skills, all rules, all the time. Claude Code's prompt
caching helps with latency but does nothing for the rate limit counter, which is
what actually stops you from working.
We've been experimenting with compiling SKILL.md files into standalone agents
instead. Each one gets its own process, its own runtime config, and — most
importantly — doesn't sit in the system prompt burning tokens on calls where
it's not even being used. ~150 bytes of config vs 19k tokens.
Still figuring out the edges. https://github.com/agenthatch/agenthatch
feat(settings): add CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 recommenda…