[Bug] Rate limit consumption disproportionate to measured token usage for opus-5-1m with prompt caching
Bug Description
Usage limit consumed far faster than in August despite 3-4x lower measured token
consumption.
Symptom: hit ~50% of the 5-hour limit in ~50 minutes of work (4.17 hours
remaining on the window). This started a few days ago. Same workload as before:
multiple concurrent sessions, heavy code and file editing across several repos.
Measured from my local transcripts (summing input + cache_creation + cache_read
- output per assistant record, weighted 1x / 1.25x / 0.1x / 5x):
period turns/day weighted tokens/day avg context/turn
Aug 5-12 1000-2650 60-155M ~400k
Aug 24-28 700-2170 32-96M ~300k
Sep 1-4 810-1373 25-37M ~150k
Consumption is DOWN 3-4x on every axis versus early August, when I was not
hitting caps. Cache reads are ~63% of weighted cost (205M raw on Sep 4).
Ruled out locally:
- Model unchanged throughout: opus[1m] (settings.json, confirmed against a
Sep 1 backup of the same file).
- effortLevel went DOWN on Sep 1, xhigh -> high. Nothing got more expensive.
- Average context per turn dropped from ~400k to ~150k.
- Only config additions in the window: a UserPromptSubmit hook that emits
nothing below 200k context, and one unused skill directory.
Expected: limit consumption roughly proportional to tokens billed.
Actual: limit consumption up sharply while measured tokens fell 3-4x.
Question: did rate-limit weighting change for opus[1m] (long-context surcharge
above 200k, or cache-read weighting) in the last several days?
Env: Claude Code on Windows 11, model claude-opus-5[1m], effortLevel high.
Environment Info
- Platform: win32
- Terminal: windows-terminal
- Version: 2.1.260
- Feedback ID: 57c276e4-b426-4114-bd82-7f348d3da485
Errors
[]Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
I am also experiencing a sudden reduction in usable Claude Code allowance: I reach the usage limit sooner than before while remaining on the same subscription plan.
This is about hitting the cap sooner, not the usage percentage in the UI dropping.
My verified environment:
claude --version)I do not yet have a controlled before/after token comparison or an exact onset date, and I cannot confirm that my case has the same cause as the cache-related behavior described here.
Please investigate whether usage accounting, rate-limit weighting, or the applied allowance has changed. If this is an intentional change, please explain it clearly. Which measurements or diagnostics should affected users collect to help identify the cause?
Follow-up with 11 more days of data. The
opus[1m]hypothesis in my original report is dead — I switchedmodelfromopus[1m]to plainopuson 2026-09-04 and the behavior is unchanged. This is not a long-context surcharge.Methodology correction: my original table summed usage per transcript record. One API request writes several records, each carrying that request's same cumulative
usageobject, so those numbers were inflated ~2x. Everything below is deduplicated onrequestId. The numbers are lower than my original post and the trend still holds.Weighted per weekly reset window (Sat 22:00 ET),
in*1 + cache_write*1.25 + cache_read*0.1 + out*5:| week start | API requests | cache write | cache read | output | weighted |
|---|---|---|---|---|---|
| 2026-08-08 | 707 | 3.6M | 215.2M | 0.62M | 29.1M |
| 2026-08-22 | 3,459 | 18.8M |1136.3M | 3.46M | 154.5M |
| 2026-08-29 | 2,996 | 16.9M | 630.4M | 2.32M | 95.7M |
| 2026-09-05 | 1,936 | 7.8M | 307.0M | 1.37M | 47.3M |
| 2026-09-12 | 1,531 | 5.2M | 228.9M | 1.23M | 35.5M |
The discrepancy: the week of Aug 22 consumed 154.5M weighted tokens with no cap pressure. The current window hit 63% of the weekly limit at 35.5M — implying a budget of roughly 56M. That is ~2.8x tighter than August against a limit the in-product notice describes as only ~1.2x lower post-promotion (summer promo ended Sep 13; "your weekly limit is now 25% higher than it was before the promotion").
Requests are down 56% and weighted tokens are down 77% versus Aug 22, yet I now exhaust a week by Tuesday.
Additionally ruled out since the original report, all measured with
claude -p "hi" --model haiku --output-format jsonand diffing total context:--strict-mcp-config). Tool-schema deferral is working; only names load..claude/rules/auto-loading 212,929 chars (45,391 tokens) into every session baseline in one repo, and trimmed two oversizedCLAUDE.mdfiles. Combined that cut baselines 46,902→42,661 and 81,566→36,624. Real savings, but an order of magnitude too small to explain the gap above.Ask: please confirm whether rate-limit weighting for cache-read tokens, or the weekly allowance itself, changed between the Aug 22 window and now. If the change is intentional, the in-product "25% higher than before the promotion" notice does not match what my transcripts show. If it is not intentional, the per-week table above should be reproducible from server-side accounting for this account.
Happy to share the script that produces this table. Env: Claude Code 2.1.260, Windows 11,
model: opus,effortLevel: high.I'm seeing the same issue on Claude Code with Opus 5.
My version, model, workflow, and project are unchanged compared with last week.
Previously, I usually couldn't exhaust my 5-hour limit during normal work, and I practically never reached my weekly limit.
This week, the same workflow exhausts my 5-hour limit in roughly 2–2.5 hours.
My weekly limit reset yesterday at approximately 08:00, and only ~34 hours later about 43% of my weekly allowance has already been consumed, leaving 57% remaining.
This is a significant change from my normal usage pattern despite no meaningful change in my workflow or model.