[BUG] Pro Max 5x Quota Exhausted in 1.5 Hours Despite Moderate Usage

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/24147
2. https://github.com/anthropics/claude-code/issues/44494
3. https://github.com/anthropics/claude-code/issues/43274

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

This is not a duplicate — the hypothesis that cache_read tokens 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.

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 init

Feedback welcome.

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.jsonl log (q5h_pct, q7d_pct, and peak_hour fields, 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_read count 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.

| Hypothesis | Mean implied 100% quota | CV across 6 windows |
|---|---|---|
| cache_read = 0.0x (cache_read does NOT count for quota) | ~4.66M token-equivalents | 34.4% ★ |
| cache_read = 0.1x (counts at the published billing rate) | ~24.4M tok-eq | 101.6% |
| cache_read = 1.0x (counts at the full input rate — @molu0219's hypothesis) | ~201.6M tok-eq | 123.7% |

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_read does 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:

• Single account, ~24 hours of data
• Q5h is a 5-hour sliding window; we approximate as discrete reset boundaries by detecting q5h_pct drops ≥ 5pp
• The cache_creation TTL weight is averaged at 2.0 (1h tier); accounts with mixed 5m/1h would shift this slightly
• Only Anthropic knows the exact quota formula

We 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.jsonl and report your own best-fit hypothesis. The whole methodology is open-source and re-runnable:

npm install -g claude-code-cache-fix
# Use the interceptor for at least 24 hours so the log accumulates resets
node $(npm root -g)/claude-code-cache-fix/tools/quota-analysis.mjs

If your data also lands on cache_read = 0.0x as 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.

cc'ing for visibility — your input on this would be specifically valuable:

• @molu0219 — your hypothesis is what motivated the analysis. The data lands on the opposite of what you predicted, but we want to make sure you see the methodology and have a chance to point out anything we're missing or any framing assumption you'd push back on. The headline finding directly addresses your concern; the methodology is open-source and re-runnable on your own data.
• @TigerKay1926 — you found Mechanism 2 (the 1h TTL GrowthBook gating) using the interceptor's flag dump. If you run the new quota-analysis.mjs tool against your own usage.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.

I've updated your plugin to the latest version. I'll test it out to see how it works. Thank you very much!

Here is my data https://github.com/anthropics/claude-code/issues/46829

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:

1. Cache miss rate is the hidden multiplier. Since the cache TTL was reduced to 5 minutes (#46829), every session that pauses for more than 5 min triggers a full cache_create on resume. Cache_create tokens cost ~12.5x more quota than cache_read. A developer who takes a coffee break mid-session comes back to significantly higher burn rate.
2. Context window inflation compounds the problem. As conversations get longer, each turn sends more tokens. Combined with frequent cache misses, the effective cost per interaction scales non-linearly.

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 /compact aggressively to keep the context window lean.

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:

1. 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_WINDOW=400000 claude.
2. People pulling in a large number of skills, or running many agents or background automations, which sometimes happens when using a large number of plugins. This was the case for a surprisingly large number of users, and we are actively working on (a) improving the UX to make these cases more visible to users and (b) more intelligently truncating, pruning, and scheduling non-main tasks to avoid surprise token usage.

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!

I experienced the same thing yesterday. I solved it by resetting the session for each task and continuing with a new session.

1. 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_WINDOW=400000 claude.

This comment seems to say the cache window was reduced to 5m, not 1h. Meaning most sessions involving any kind of non-trivial work will result in a cache miss. Am I misunderstanding something?

In the process, we ruled out a large number of hypotheses: adaptive thinking, other kinds of harness regressions, model and inference regressions.

Sharing my debug mode skill that can be used to rule out hypotheses more effectively using Claude Code.

SKILL.md

That is why we use opencode and pi-coding-agent but you guys blocked.

Suggestion - the harness should compact the conversation at the allowance limit and on resume:

• ask the user to continue from summary
• allow the user the continue but they have to be aware of the costs
• suggest the user to start fresh.

Such continued conversations are a clear candidate for 1 hour cache TTL.

If a user is at limit, it’s very likely they won’t continue their session (not many users will opt for extra usage), so the TTL can be reduced to 10m for the prompts after the limits are hit, unless the system detects that the user refilled the extra usage allowance.

Using Claude-Code to work on any software now with Pro, currently I get 2 prompts per 5 hours, and usually hits 100% during the second, even on a fresh context. I keep it as a backup and use it as such because I can't really use it for much else, now it's not even really worth that.

@mikebutash — 2 prompts per 5 hours on Pro is consistent with what several users across plan tiers are reporting. The root cause is prompt cache rebuilding on every turn instead of reading from the prior turn's cache, so each message pays full cache-creation cost even on a fresh context.

Two things that help right now:

1. Pin to v2.1.81 (last release before the regression):

``bash
npm install -g @anthropic-ai/claude-code@2.1.81
``

1. Stack the cache-fix interceptor (forces 1h cache TTL, fixes fingerprint instability):

``bash
npm install -g claude-code-cache-fix@1.7.1
``
Setup: https://github.com/cnighswonger/claude-code-cache-fix

A community user on Max 20x reported ~3-4× quota improvement from the version pin alone. Another validated 98.4% cache hit rate with the interceptor across a 7.5-hour session. Both fixes work on Pro.

regardless of the cache-window-duration it currently seems impossible to hit caches on new sessions

• at all times https://github.com/anthropics/claude-code/issues/47098
• and especially when actual work is getting done https://github.com/anthropics/claude-code/issues/47107

before those are fixed likely any 5 minutes vs 1 h discussion is entirely moot since numbers are totally flawed

@wadabum — your point is well-taken, and the two bugs you filed (#47098, #47107) identify cache-busting mechanisms that are upstream of the TTL discussion. If the system prompt changes on every git status update (#47107) and skills/CLAUDE.md blocks in messages[0] regenerate non-deterministically on every new session (#47098), then the prefix can never stabilize long enough for ANY TTL tier to help.

We posted a more detailed response on #47098 with what we see from our interceptor's telemetry. The short version: our interceptor addresses part of this (sorting and stabilizing the skills/deferred-tools/MCP blocks within messages[0] to reduce ordering jitter), but doesn't currently address the git-status system-prompt instability you found in #47107. That's a good lead for a future fix.

You're right that these are foundational — they need to be addressed before the TTL tier even matters for affected sessions.

I wish we had more control over what we want to put into the context. This feels like claude code fills context with whatever you choose for us, rather than giving us the freedom to work with a context that we manage.
I love Claude and what you guys have built, but I find myself questioning your sincerity, especially after banning pi.
I hope you make it right for us. Thank you

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: 1. 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.

Hi Boris! Jarred Sumner says here that you swapped to 5 min TTL in March, I guess then the issue compounds quite a bit with 1M tokens? Are we currently on 5 min or 1 hr TTL for the main agent and can we swap on the user end?

Are we currently on 5 min or 1 hr TTL for the main agent and can we swap on the user end?

I think I can reply here based off on my reading of both tickets yesterday:

• the harness will decide the TTL. Subagents are near guaranteed or guaranteed to have 5m TTL. For the main agent, it's up to harness to decide. From Claude Code you cannot influence this, unless you install https://github.com/cnighswonger/claude-code-cache-fix This might or might not fit your workloads. If you run long running intensive sessions - then probaby this fix is for you. If you usually do short bursts - then probably no.

@bcherny developer behavior has not changed over the past month, but suddenly everyone is busting through their usage limits. This seems to indicate the problem is on Anthropic's side, not the two points you brought up.

Also experiencing this, yesterday was able to work on a code base for most of the day, building features, plans, fixing bugs with agents too. Didn't hit a limit.

Today, spent 1 hour fixing two basic bugs and creating a plan - hit the limit in an hour.

I’m seeing the same issue. My quota reset 2 minutes earlier, and after a single Claude Code prompt asking a basic question, 27% of my session limit was already consumed. That burn rate seems far beyond normal usage. I also have a screenshot of the usage limit if that would help

<img width="1048" height="203" alt="Image" src="https://github.com/user-attachments/assets/ba977b07-4849-4363-a668-77e004517764" />

@crypto-a @JamesMahy — if you just arrived at this thread and your quota is draining fast:

npm install -g @anthropic-ai/claude-code@2.1.104
npm install -g claude-code-cache-fix@1.8.0

Setup (2 min): https://github.com/cnighswonger/claude-code-cache-fix

Community-validated at 99.5% cache hit rate across a 61-hour session. Multiple users in this thread have confirmed 3-4× quota improvement. Details in our writeup: https://veritassuperaitsolutions.com/three-layer-gate-quota-overage/

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: 1. 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,

For myself, clear, transparent usage statistics after each agent response, would totally clear up these questions about what’s happening with my usage budget.
Maybe Anthropic wants to avoid this for whatever reason, but, I suspect people are going to be confused about what’s happening with their usage budget unless something like this is reported.

@mikebutash — 2 prompts per 5 hours on Pro is consistent with what several users across plan tiers are reporting. The root cause is prompt cache rebuilding on every turn instead of reading from the prior turn's cache, so each message pays full cache-creation cost even on a fresh context. Two things that help right now: 1. Pin to v2.1.81 (last release before the regression): npm install -g @anthropic-ai/claude-code@2.1.81 2. Stack the cache-fix interceptor (forces 1h cache TTL, fixes fingerprint instability): npm install -g claude-code-cache-fix@1.7.1 Setup: https://github.com/cnighswonger/claude-code-cache-fix A community user on Max 20x reported ~3-4× quota improvement from the version pin alone. Another validated 98.4% cache hit rate with the interceptor across a 7.5-hour session. Both fixes work on Pro.

@cnighswonger https://github.com/ArkNill/claude-code-hidden-problem-analysis seems to suggest 2.1.104 may actually be the best version to use (given 29% cache miss rate versus 79% on 2.1.91).

Is there a reason you'd recommend 2.1.81 instead of 2.1.91 or 2.1.104?

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: 1. 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_WINDOW=400000 claude. 2. People pulling in a large number of skills, or running many agents or background automations, which sometimes happens when using a large number of plugins. This was the case for a surprisingly large number of users, and we are actively working on (a) improving the UX to make these cases more visible to users and (b) more intelligently truncating, pruning, and scheduling non-main tasks to avoid surprise token usage. 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!

Absolutely nothing you've said on this matter has had ANY effect or relevance to the absolute shitshow I've been experiencing with Claude Code the past 2 weeks.

Not the adaptive thinking toggle, not the effort setting, not the cache misses, not the skills loaded, not the chat length, none of it. Stop gaslighting us @bcherny.

⏩📲🔱🪐✅⌚️🌩️💲🐉🐸✝️💕💕💕💕

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: 1. 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_WINDOW=400000 claude. 2. People pulling in a large number of skills, or running many agents or background automations, which sometimes happens when using a large number of plugins. This was the case for a surprisingly large number of users, and we are actively working on (a) improving the UX to make these cases more visible to users and (b) more intelligently truncating, pruning, and scheduling non-main tasks to avoid surprise token usage. 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!

The 1M context window shipped as a headline feature.

Now it's a quota hazard the team wants to default away from? And I can promise you the issue is not leaving sessions open overnight or resuming old sessions constantly.

Please... if you need data I can give it. I can send you an archive of 4 different computers .clade/projects/ logs since December.

On top of that it is now the new default and not possible to change back from in /model or /settings...

Users who adopted 1M (or forced upon) are now told their context window is part of the problem.

Because of this issue, even the weekly quota is about to be almost completely used up. There's definitely a problem.

"keeping your context clean" gets you punished too:

• https://github.com/anthropics/claude-code/issues/47756
• https://github.com/anthropics/claude-code/issues/47098

Yes same here, max 20x plan exhausted in a day, I was not even able to reach 20% earlier

@sinoru @niyaskc007 — the quota drain is caused by prompt cache misses. Two-minute fix:

npm install -g @anthropic-ai/claude-code@latest
npm install -g claude-code-cache-fix@1.9.1

Setup: https://github.com/cnighswonger/claude-code-cache-fix

Community-validated at 99.5% cache hit rate across a 1,610-call session. Multiple users in this thread have reported 3-4x quota improvement.

Same here—my 20x plan ran out within just a few hours. 200$ for only 2-3 sessions / week.

Same here. Burned through my 5× Max plan in about an hour. Even worse, after enabling extra usage, a single question is costing me around $3–$5.

@TueVNguyen @wongyun-yu — the fix:

npm install -g @anthropic-ai/claude-code@latest
npm install -g claude-code-cache-fix@1.9.1

Setup (2 min): https://github.com/cnighswonger/claude-code-cache-fix

@wongyun-yu — the \$3-5 per question on extra usage is consistent with what we've measured: a cache miss on a large context (500K+ tokens) at overage rates is extremely expensive. The interceptor eliminates most of those misses. With it running, we sustained a 1,610-call session at 99.5% cache hit rate.

@sinoru @niyaskc007 — the quota drain is caused by prompt cache misses. Two-minute fix: npm install -g @anthropic-ai/claude-code@latest npm install -g claude-code-cache-fix@1.9.1 Setup: https://github.com/cnighswonger/claude-code-cache-fix Community-validated at 99.5% cache hit rate across a 1,610-call session. Multiple users in this thread have reported 3-4x quota improvement.

@cnighswonger That is workaround. Not a proper fix by Anthropic. I don't want a duck-tape. Especially when I'm paying to Antropic.

Anthropic you are burning your credit with serious devs on this thread. It's clearly a change to increase cost. I could go all day with what takes minutes now and I'm maxed. "Oddly enough" each session is costing 2.50+ in extra credit that never once was used before. Fix this please... or just be honest it's intentional.

For everyone hitting quota drain in this thread — we published the full optimization guide:

How to Get 99.5% Cache Hit Rate on Your Claude Code Subscription

61 hours, 1,610 API calls, 99.5% cache hit rate on Max 5x. Setup takes 15 minutes. Covers all subscription tiers (Pro, Max 5x, Max 20x).

Quick start:
\\\bash
npm install -g @anthropic-ai/claude-code@latest
npm install -g claude-code-cache-fix@latest
\\\

Setup: https://github.com/cnighswonger/claude-code-cache-fix

For everyone hitting quota drain in this thread — we published the full optimization guide: How to Get 99.5% Cache Hit Rate on Your Claude Code Subscription 61 hours, 1,610 API calls, 99.5% cache hit rate on Max 5x. Setup takes 15 minutes. Covers all subscription tiers (Pro, Max 5x, Max 20x). Quick start: ``bash npm install -g @anthropic-ai/claude-code@latest npm install -g claude-code-cache-fix@latest `` Setup: https://github.com/cnighswonger/claude-code-cache-fix

This is just coming across as spam at this point. It's annoying, it's not helping the conversation and whilst I looked at your solution initially your insistence on spamming it in this post means I wouldn't touch it or anything you've made.

Here are some facts (correct me if I am wrong):

• fix (posted above, by community member) is based on the fact that Claude Code client is sabotaging the API by sending modified context and therefore context cache has to be regenerated
• Anthropic has issues fixing the problem which means they can't locate it in their code
• Anthropic has no interest in producing dissatisfied customers
• Anthropic has no interest in DDoS-ing their servers. Just imagine. Claude Code client makes their servers overloaded. It MAKES these servers recalculate context over and over again which makes the whole service unresponsive and shortens the session length for customers.

IMHO, this problem should generate a FULL STOP in the Claude Code team so that they can focus on the REAL fix.

While waiting for a quota fix, here's what I measured: 32% fewer tokens and 18.8% lower cost per task by stacking 12 optimization techniques (response shaping, noise filtering, thinking budget cap, Haiku subagent for exploration, output compression, early compaction).

Dry-run (no install, no writes — just scans your repo and estimates savings):

curl -fsSL https://raw.githubusercontent.com/sravan27/context-os/main/setup.sh | bash -s -- --measure

Install:

curl -fsSL https://raw.githubusercontent.com/sravan27/context-os/main/setup.sh | bash

Real benchmark against any repo: scripts/benchmark.sh /path/to/repo --model sonnet — parses actual claude --print --output-format json usage, reports input/output/cache/cost delta.

Fully reversible (--uninstall). Zero dependencies. https://github.com/sravan27/context-os

Opus 4.7 Q5h observation: First metered 4.7 session showed significantly elevated Q5h burn rate vs 4.6 baseline — ~15% consumed in 38 minutes of work. Seeking validation from other 4.7 users.

Details: https://github.com/cnighswonger/claude-code-cache-fix/discussions/25

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: 1. 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_WINDOW=400000 claude. 2. People pulling in a large number of skills, or running many agents or background automations, which sometimes happens when using a large number of plugins. This was the case for a surprisingly large number of users, and we are actively working on (a) improving the UX to make these cases more visible to users and (b) more intelligently truncating, pruning, and scheduling non-main tasks to avoid surprise token usage. 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!

------

Why not backup 1M KV cache to S3, and then pull back when the user returns.

Loading 342k token context... (ETA: 30sec) Type /clear to clear context

Cheaper than inference?

Funny that Boris references the 1hr cache windows but then Anthropic confirmed that they silently switched to a 5 minute cache window and said that it was a planned move and they're not switching back or letting users set the window for themselves. Why go from 1hr to 5 minutes? It's pretty common to have Claude work on something, then come back to it 15-20 minutes later.

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 /cost output - 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

More details for https://github.com/anthropics/claude-code/issues/45756#issuecomment-4300196884:

• Same issues with Opus 4.7 and without 1H cache enabled.
• Also tried changing the effort level (from high to medium) - no help
• Another weirdness that is quite likely related: /context reporting "Messages: 101k" after telling Claude "hi" twice!

% claude --model sonnet
▐▛███▜▌   Claude Code v2.1.118
▝▜█████▛▘  claude-4-6-sonnet-aws-comm-il2[1m] with medium effort · API Usage Billing
  ▘▘ ▝▝    ~/some_dir

❯ hi                                                                                                                                      

⏺ Hi! What can I help you with?                                                                                                           

❯ hi                                                                                                                                      

⏺ Still here. What do you need?                                                                                                           

❯ /context                                                                                                                                
  ⎿  Context Usage
     ⛁ ⛀ ⛁ ⛀ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   claude-4-6-sonnet-aws-comm-il2[1m]                                                         
     ⛁ ⛁ ⛁ ⛁ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   113.6k/1m tokens (11%)                                                                 
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶                                                                                              
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   Estimated usage by category                                                                
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ System prompt: 5.6k tokens (0.6%)                                                        
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ Custom agents: 19 tokens (0.0%)                                                          
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ Memory files: 3.6k tokens (0.4%)                                                         
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ Skills: 3.4k tokens (0.3%)
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ Messages: 101k tokens (10.1%)
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛀   ⛁ Compact buffer: 3k tokens (0.3%)
                                               ⛶ Free space: 883.4k (88.3%)

    [...]
❯ /usage                                                                                                                                  

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   Status   Config   Usage   Stats                                                                                                    

  Session                                                                                                                             
  Total cost:            $0.95 (costs may be inaccurate due to usage of unknown models)                                               
  Total duration (API):  6s                                                                                                           
  Total duration (wall): 32s                                                                                                          
  Total code changes:    0 lines added, 0 lines removed
  Usage by model:
  claude-4-6-sonnet-aws-comm-il2[1m]:  113.6k input, 23 output, 56.8k cache read, 56.8k cache write ($0.95)

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_tokens field consistently shows 1-3 tokens per call (just the new user message), while cache_read_input_tokens shows 300K+ (the full cached context). If double-counting were happening, input_tokens would 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%):

| Model | cache_read weight | Implied 100% budget | Match? |
|-------|------------------|---------------------|--------|
| cache_read = 0x | 0 | 1.9M tokens | Too low |
| cache_read = 0.1x | 0.1 | 18.8M tokens | Matches cross-validated data |
| cache_read = 1.0x | 1.0 | 170M tokens | Too high |

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_read inside input_tokens at the API response level, which is a different behavior than what direct Anthropic subscription auth returns. The timing correlation with CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS flip 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

@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/messages and routes to Bedrock via the Invoke API (not Converse). The relevant file is litellm/llms/bedrock/messages/invoke_transformations/anthropic_claude3_transformation.py, not converse_transformation.py that 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 streaming message_stop event into message_delta. It contained this line:

delta_usage["input_tokens"] = uncached + cache_creation + cache_read

It was pre-inflating input_tokens on the delta to "the full count." But downstream calculate_usage then added cache_creation and cache_read again to form prompt_tokens, giving:

prompt_tokens = (uncached + cache_creation + cache_read) + cache_creation + cache_read
              = uncached + 2×cache_creation + 2×cache_read

The fix

Commit f0d2d26301 (Apr 11, 2026), shipped in v1.83.6-nightly / v1.83.7-stable:

# before
delta_usage["input_tokens"] = uncached + cache_creation + cache_read
# after
delta_usage["input_tokens"] = raw_input   # keep uncached-only; downstream adds cache once

Commit message: "fix(bedrock): avoid double-counting cache tokens in Anthropic Messages streaming usage" — which is exactly what you were seeing.

Affected versions

| Version | Status |
| ---------------------- | ----------------------- |
| 1.81.9 | Fine (predates the bug) |
| 1.83.3 – 1.83.6 stable | Buggy |
| 1.83.7 stable onwards | Fixed |

Answers to your original questions

• Real costs or accounting bug? Pure LiteLLM accounting bug. AWS billed correctly; LiteLLM's /cost was inflated because prompt_tokens - cache - cache_creation gave a fake huge "non-cached" count.
• Did AWS change anything? No. Your docs quote was correct — inputTokens never included CacheReadInputTokens. My earlier hypothesis was wrong; I was looking at the wrong file (Converse, not Invoke/Messages).

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/**/*.jsonl and 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)

| Date | API-equiv cost | Weekly quota state |
|------|---------------:|-----|
| 17 Apr | $2,127 | within usual envelope |
| 18 Apr | $1,447 | within usual envelope |
| 19 Apr | $1,414 | within usual envelope |
| 21 Apr | $2,804 | peak day, never hit weekly cap |
| 22 Apr | $1,781 | within usual envelope |
| 24 Apr | $754 | normal day |
| 28-29 Apr (36h, today) | $1,339 | 29% of weekly quota consumed |

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

1. Confirm or deny: was the Max 20x weekly ceiling reduced (or its quota weighting changed) on or around 23-25 April? If so, when, and what was the magnitude?
2. Publish a comparison of "tokens billed against quota per dollar of equivalent API spend" before and after the change.
3. Notify users in advance when subscription economics shift this materially. The pattern of #46829 (silent March 6 TTL change) and this thread is undermining trust in the plan.

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.

@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.

@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.

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".

@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 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.

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.

You don't know about the economics at scale now and in the future.

@criscola Neither do you.

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.

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.

@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.

> 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. @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.

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.

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