Weekly limit depletes disproportionately to 5h-session limit on Max 20x — quantified telemetry shows ~5x drift vs historical baseline
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Weekly usage limit on Max 20x is depleting 2-5x faster relative to actual token consumption than my historical baseline, even after extensive client-side mitigation. The 5h-session and weekly buckets appear miscalibrated relative to each other since the May 6 5h-doubling rollout.
Quantified observations:
- Statusline drift (real-time): I run a custom statusline tracking delta-to-linear-consumption-curve for both buckets. At a single moment: 5h window shows -43% (well below expected linear burn), weekly shows +21% (well above expected linear burn).
- Drift accumulates with usage, not time: Within the same 5h window, 13 minutes apart, a 1pp 5h-burn produced a 1pp weekly-drift increase. The weekly bucket should mathematically be ~33x larger than a single 5h slot, so 1pp 5h ≈ 0.03pp weekly would be expected. Observed ratio is roughly 33x off.
- Day-to-day token comparison via ccusage:
April 24, 2026 (pre 5h-doubling, 5 parallel projects, intensive terminal switching):
- Cost: $242.30
- Total tokens: 322,501,893
- Cache creates: 10,887,933
- Cache reads: 310,808,556
- Output: 802,419
May 9, 2026 (post 5h-doubling, 1 project, 1 session, subjectively less intensive):
- Cost: $627.52
- Total tokens: 1,042,274,342
- Cache creates: 10,763,960
- Cache reads: 1,029,659,911
- Output: 1,844,324
Cache-create counts are nearly identical (10.9M vs 10.8M), implying comparable distinct-context volume. But cache-reads are 3.3x higher and total cost 2.6x higher despite a less intensive workload. The shape of consumption changed, not the workload.
- Historical baseline: Peak week pre-May 6 consumed ~$3,800 in API-equivalent cost = ~70% weekly limit. May 9 alone consumed ~$627 = ~25% weekly limit in 13h. Per-dollar weekly burn rate is roughly 5x the historical rate.
What Should Happen?
Weekly limit consumption should remain proportional to actual token throughput, with the weekly bucket sized to accommodate many full 5h sessions — not roughly two, which is what the current 1pp:1pp drift ratio implies.
After the May 6 5h-limit doubling, either the weekly limit should have been doubled commensurately, or the per-token weekly cost should be unchanged. Currently neither appears to hold: the same workload pattern that previously consumed ~$3,800 for 70% weekly should not now consume ~25% weekly in a single day for ~$627.
Error Messages/Logs
No CLI errors. The issue is silent — visible only in usage telemetry, not in error logs.
ccusage outputs are included in the "What's Wrong?" section above.
Statusline screenshots showing the -43% / +21% drift at two timestamps 13 minutes apart in the same 5h window are available on request (cannot embed in this form). Happy to share via DM or attached comment.Steps to Reproduce
This is a usage-pattern observation, not a deterministic CLI failure. To reproduce or verify the discrepancy:
- Use Claude Code on a Max 20x plan with substantial Opus consumption (multiple sessions per day, 100M+ tokens per day).
- Pull daily totals from ccusage for a pre-May-6 day and a post-May-6 day with comparable workload character.
- Compare per-dollar and per-token consumption against weekly-limit progress in /usage.
- Observe that the same per-token cost generates more weekly-bucket consumption than before May 6.
Configuration during my observations:
- CLI: 2.1.138 (latest)
- Models: Opus 4.6 (manually pinned to avoid Opus 4.7 tokenizer + 1M-context default)
- Auto Mode: off
- /compact: triggered manually at 40% context
- DISABLE_TELEMETRY: not set (cache-TTL fallback bug from earlier versions does not apply)
- Cache hit ratio: ~96:1 read-to-write (healthy, no client-side caching pathology)
Despite all of the above mitigations, the +21% weekly drift persists in real-time.
Hypothesis space:
- Weekly-limit calibration was implicitly reduced relative to the 5h limit during the May 6 rollout, but not communicated.
- Cache-reads are now weighted differently in weekly-limit accounting than in pre-May-6 behavior or in API-credit accounting.
- Server-side tracking discrepancy similar to the prompt-caching bug that triggered the Feb 27, 2026 fleet-wide weekly reset.
Related: #57632
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
2.1.123
Claude Code Version
2.1.138
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
<img width="514" height="106" alt="Image" src="https://github.com/user-attachments/assets/617fdc0d-fdb2-4d4e-aa27-52779b6eeb27" />
<img width="462" height="78" alt="Image" src="https://github.com/user-attachments/assets/35dc45d5-de7d-4013-ad31-3cf609b99337" />
Values calculated by this formula:
five_h=$(echo "$input" | jq -r '.rate_limits.five_hour.used_percentage // empty')
five_h_resets=$(echo "$input" | jq -r '.rate_limits.five_hour.resets_at // empty')
seven_d=$(echo "$input" | jq -r '.rate_limits.seven_day.used_percentage // empty')
seven_d_resets=$(echo "$input" | jq -r '.rate_limits.seven_day.resets_at // empty')
# 5h + 7d delta
if [ -n "$five_h" ]; then
five_h_int=$(printf '%.0f' "$five_h")
c=$(color_for "$five_h_int")
five_seg="5h ${c}$(bar "$five_h_int") ${five_h_int}%${reset}"
# 5h: Restzeit vor Label, Abweichung dahinter
if [ -n "$five_h_resets" ]; then
now_ts=$(date +%s)
window5=$((5*3600))
remain5=$(( five_h_resets - now_ts ))
[ "$remain5" -lt 0 ] && remain5=0
elapsed5=$(( window5 - remain5 ))
[ "$elapsed5" -lt 0 ] && elapsed5=0
[ "$elapsed5" -gt "$window5" ] && elapsed5=$window5
target5=$(awk -v e="$elapsed5" -v w="$window5" 'BEGIN { printf "%.1f", e/w*100 }')
delta5=$(awk -v u="$five_h" -v t="$target5" 'BEGIN { printf "%.0f", u-t }')
if [ "$delta5" -gt 3 ]; then dc5="$red"
elif [ "$delta5" -lt -3 ]; then dc5="$green"
else dc5="$yellow"
fi
if [ "$delta5" -ge 0 ]; then sign5="+"; else sign5=""; fi
rh=$(( remain5 / 3600 ))
rm=$(( (remain5 % 3600) / 60 ))
remain5_str=$(printf '%d:%02d' "$rh" "$rm")
five_seg="${gray}${remain5_str}${reset} ${five_seg} ${dc5}${sign5}${delta5}%${reset}"
fi
if [ -n "$seven_d" ] && [ -n "$seven_d_resets" ]; then
now_ts=$(date +%s)
window=$((7*86400))
elapsed=$(( window - (seven_d_resets - now_ts) ))
[ "$elapsed" -lt 0 ] && elapsed=0
[ "$elapsed" -gt "$window" ] && elapsed=$window
target_pct=$(awk -v e="$elapsed" -v w="$window" 'BEGIN { printf "%.1f", e/w*100 }')
delta=$(awk -v u="$seven_d" -v t="$target_pct" 'BEGIN { printf "%.0f", u-t }')
if [ "$delta" -gt 3 ]; then
dc="$red"
elif [ "$delta" -lt -3 ]; then
dc="$green"
else
dc="$yellow"
fi
if [ "$delta" -ge 0 ]; then sign="+"; else sign=""; fi
five_seg="$five_seg ${dc}${sign}${delta}%${reset}"
fi
out="$out | $five_seg"
fi
15 Comments
https://usage.report — look at the data table. the system prompt size DOUBLED after .119
this is the local-log vs server-truth gap. ccusage reads transcripts and computes API-equivalent cost; /usage reads a separate accounting plane the server uses for actual enforcement. the two were never identical, May 6 just amplified the spread. hypothesis #2 (cache-reads weighted differently in the weekly bucket vs API-credit accounting) is the likely culprit given your 96:1 read:write plus 3.3x cache-read inflation with cache-creates flat. only /usage telemetry pulled from the same endpoint settings renders can falsify it; transcript replay can't see what the server is counting.
its not using /usage — its consistent half on .119 against .121+
Quick correction on "transcript replay can't see what the server is counting": every API response includes the server's own usage counts per token category, which the CLI persists into the transcript. Example from one of my response objects:
ccusage reads these server-reported counts directly, it doesn't tokenize the transcript itself. So token-counts per category are not in dispute — those numbers come from the server. The only plane not visible from the transcript is the weekly-bucket-percentage accounting, which is exactly what's drifting against everything else.
That doesn't change the hypothesis, just removes the local-vs-server-counts framing as a possible explanation.
Attached chart shows the resulting drift in real time: 102 minutes of continuous /usage logging (643 datapoints, Opus 4.6, includes a 5h-reset around 00:10 UTC). 5h-burn to weekly-burn ratio across the window ≈ 3:1, with persistent sign-divergence between the two delta lines — 5h-delta down to -74pp while weekly-delta sits at +21 to +24pp at the same moments.
<img width="1934" height="1332" alt="Image" src="https://github.com/user-attachments/assets/60227413-c212-4970-8bba-af7b4938f20f" />
Cross-cutover ccusage analysis — sharpening the hypothesis:
Looking at the token structure across 38 real work days spanning the May 6 cutover (32 pre, 6 post), the per-token structural metrics are stable:
The API-credit accounting plane shows no structural change. ccusage reads server-reported token counts and applies the deterministic pricing table, both unchanged.
At the same time, my observed $-to-weekly conversion has degraded by a factor of roughly 2×: same kind of work produces noticeably more weekly-bucket consumption per API-equivalent dollar than it did pre-cutover, despite identical token structure.
Refined hypothesis:
The weekly-bucket accounting plane and the API-credit accounting plane apply different per-token-type weights. Specifically: cache-reads are weighted at the documented 10% discount in API-credit accounting ($1.50/M vs $15/M base for Opus), but appear to be weighted closer to full input rate in the weekly-bucket plane.
With my observed 96% cache-read share of total tokens, if cache-reads are weighted at full input rate in the weekly bucket instead of 10%, that produces approximately a 10× inflation of weekly consumption relative to what the $-cost suggests. The 2× observed degradation relative to my historical baseline is consistent with a partial shift in this direction (e.g. cache-read weight moved from 10% to ~20-30% of full input rate, not necessarily all the way to 100%).
Why this hypothesis fits the observed signals:
Falsification path (internal to Anthropic):
Compare the per-token-type weights used in weekly-bucket accounting against the API-credit pricing table, pre and post May 6. If the cache-read weight in the weekly bucket changed at the cutover — or was never aligned with the API-credit discount in the first place — that is the mechanism.
Raw ccusage data, /usage telemetry log, and statusline CSV available on request.
you guys need top stop having claude write your comments here lol
@k33bs haha. You're right. However it's way more structured and understandable, when claude writes my comments 😆
Seeing the same pattern — the 2-5x faster depletion lines up with sessions carrying accumulated bloat that gets re-sent on every turn. Once you're on 1M context, the problem compounds because Claude Code sends more per request than it did on 200K.
I built a tool that addresses this at the source — it monitors your session continuously and prunes the dead weight (old tool results, stale file reads, thinking blocks, metadata) before each API call. The guard daemon runs in the background and keeps the actual payload lean regardless of how long the session runs.
pip install cozempic— auto-configures on first run. Interested to hear if it reduces your weekly burn rate since you've been tracking it closely. https://github.com/Ruya-AI/cozempicConfirming this issue persists after the June 1 fix — cancelled $200/mo subscription as a result.
Plan: Max 20x ($200/month)
Interface: Claude.ai web
Primary stack: Next.js (App Router) + TypeScript + Tailwind
Before vs. After Opus 4.8:
| Period | Daily usage | Weekly limit reached |
|---|---|---|
| Opus 4.7 | ~15–16%/day | ~70% by end of week (never hit 100%) |
| Opus 4.8 | ~40%+/day | 99% within 2–2.5 days |
This is a ~3x increase in consumption for identical workflows. I did not change how I use Claude.
Timeline this week:
This bug directly forced me to cancel my Max 20x subscription and migrate to a competitor. I was an active daily user working primarily on Next.js projects. The large project context (app router, components, TypeScript types) may be a contributing factor — this issue could be hitting Next.js / large-context users harder than others.
Questions:
Happy to provide screenshots of the 99% usage bar if helpful.
on what effort level? what mcps/skills/plugins/memory.md size? did you check /context?
I do not see the same level of depletion.
Are you working on a Next.js project? I use Next.js (App Router) + TypeScript + Tailwind, and my weekly limit depletes in 2 days. A colleague on the same stack using ChatGPT works the full week without any limits. Same workflow, same intensity — different tool, different result.
I asked three questions, that's not an answer to either lol
"I use Claude in VS Code (not web). Effort level: Max on Sonnet, High on Opus. No MCPs or plugins configured. I haven't checked /context specifically, but my primary work is on a large Next.js (App Router) + TypeScript + Tailwind monorepo. Before Opus 4.8, same setup used ~70% weekly. Now depletes in 2 days."
Thank you for documenting the data behind this "bug". My 20x plan was working fine with Fable the night before, with weekly limit going up about 4 to 6% with 1 5-hour window consumed. The following evening, my weekly session limits went up from 45% to 75% in a single 5-hour session. The next session jumped it another 10% to 85%. This is not acceptable. I will be cancelling my plan if Anthropic doesn't address this in the next week.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.