[BUG] Max (20x) weekly limit depletes disproportionately — 51% mid-week, ~17% within minutes of session reset

Update — burn rate in the last ~9 minutes

Between my original report and right now, literally 9 minutes passed (session countdown went from 4h 45min → 4h 36min). During those 9 minutes I was not actively coding — a handful of messages, nothing heavy.

Fresh numbers:

| Metric | Then | Now | Delta |
|---|---|---|---|
| Current session | 14% | 21% | +7 pp in 9 min |
| Weekly (all models) | 51% | 52% | +1 pp |
| Weekly (Sonnet only) | 10% | 10% | 0 |

At +7 pp in 9 min the current session would be exhausted in ~2 hours, not the 5-hour window the session bar is supposed to represent. The weekly cap is already gone before the week is half over.

This is not a "heavy workflow" case

This is not subagent-heavy (no subagents). This is not 4+ parallel sessions (one session). This is not an 8+ hour background loop (a short foreground session). This is exactly the use case the Max (20x) tier is marketed for — single developer, Opus, normal back-and-forth — and the quota evaporates on contact.

$200/month

I pay $200/month for Max (20x) — the flagship tier, explicitly sold as 4× the budget of Max (5x). What I am getting behaves closer to Max (5x), or worse. The "20x" positioning is either broken in the accounting or quietly no longer true since the 4.7 rollout. Right now there is zero transparency about which it is, and zero way for me to self-throttle.

I am cancelling

If this is not acknowledged, investigated, and either fixed or honestly re-communicated in pricing — I will be cancelling my Max (20x) subscription. I am extremely unhappy. At this burn rate the subscription is not worth $200/month; it is not worth $50. Given the volume of near-identical complaints from other Max (20x) users in the issue tracker (#50742, #47587, #51219, #51715, #41174, #44125, #45859, #50838), I am almost certainly not the only one walking.

Please escalate internally. The product is not delivering what the tier promises.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/43274
2. https://github.com/anthropics/claude-code/issues/45756
3. https://github.com/anthropics/claude-code/issues/41930

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

Update #2 — another 10 minutes later

Third data point. Session countdown went 4h 36min → 4h 26min (another ~10 minutes). Again: not writing code, not launching background processes, nothing heavy. A handful of conversational messages in a single Claude Code CLI session.

| Metric | t=0 | t=+9min | t=+19min | Total delta |
|---|---|---|---|---|
| Current session | 14% | 21% | 25% | +11 pp in 19 min |
| Weekly (all models) | 51% | 52% | 53% | +2 pp in 19 min |
| Weekly (Sonnet only) | 10% | 10% | 10% | 0 |

Projection

At the observed burn rate, the current session will hit 100% in roughly 1h 25min, not the 5-hour window the session bar is supposed to represent. That means the session length is effectively a quarter of what is advertised.

To be specific about the "workload"

• One Claude Code CLI instance, foreground
• A handful of interactive messages
• No code generation in this session
• No Task() / subagent spawns
• No parallel sessions
• No long-running loops
• Opus 4.7 (1M-context variant)

If the 1M-context variant of Opus 4.7 is disproportionately expensive against the Max (20x) quota — say so publicly and add a user-facing toggle to switch to the 200k-context variant. If it's an accounting bug — fix it. What is not acceptable on the $200/month flagship tier is a quota bar that silently empties at several times the documented rate with zero visibility into why.

I will not be posting minute-by-minute updates after this — that would be noise. Three data points are enough to show the trend. Either this gets acknowledged by an Anthropic engineer, or I cancel.

@ Anthropic — please escalate.

This is honestly very bad, our entire team has problems now, and there's 0% transparency about what is going on?

+1 with hard numbers — Max 20x weekly meter consuming at ~10x rate (asymmetric vs 5h)

Adding a fresh, fully-instrumented data point to this issue.

Setup

• Plan: Claude Max — upgraded 10x → 20x on 2026-05-01 15:00 JST
• Verified: 2026-05-09 ~13:00 JST (~8 days into 20x)
• Claude Code: v2.1.105 (VSCode extension on macOS arm64)
• Auth method: Claude AI (OAuth)

/usage snapshot

| Meter | Value | Status |
|---|---|---|
| Session (5hr) | 22% (resets in 13m) | ✅ Healthy — 4x scaling clearly applied |
| Weekly (7 day) | 88% (resets in 1d) | ❌ Near depletion — 4x NOT applied |
| Weekly Sonnet | 0% | Unused |

The /usage UI shows my plan as just "Claude max" — there's no 10x/20x distinction visible to the user. The decisive observation here is the asymmetry between the 5-hour and weekly meters within the same account. A 4x scaling that "works on the 5h window but not on the weekly window" is not explainable by usage patterns — it has to be a backend configuration issue.

Local ccusage measurement (rules out "you just used more")

I parsed local JSONL session logs with npx ccusage@latest to measure actual token consumption around the upgrade:

| Period | Days | Avg tokens/day |
|---|---|---|
| 10x final 5 days (Apr 26–30) | 5 | 344M tokens/day |
| 20x first 8 days (May 01 15:00 → May 09) | ~8 | 375M tokens/day (+9%) |

→ Actual consumption only increased by +9% after the upgrade. With a properly-applied 4x denominator, my Weekly should be ~22% right now, not 88%. The math closes only if the weekly denominator is still set to the 10x value.

Total API-equivalent cost over the verification period (Apr 15 → May 9, 25 days): $4,722.38 — about 23.6× the $200/mo Max 20x subscription price. I'm a heavy but legitimate user, well within Acceptable Use.

Hypothesis

The cleanest explanation that fits both the asymmetric /usage display and the +9% consumption growth is:

The weekly quota denominator was not migrated from 10x to 20x at the database level when the subscription tier was upgraded. The 5-hour window was migrated correctly; the weekly window was not.

This would also explain why the bug is so persistent across reports — it's a one-shot migration bug that doesn't trigger any retry path on Anthropic's side, and only manifests for users who upgraded.

What I'm doing about it

• Filed a direct support ticket via the in-app Help → Fin chatbot. Escalated to human Product Support on 2026-05-09 ~13:40 JST. Anthropic Conversation ID: 215474234242958 (will share progress once a human agent responds).
• Adding this comment to keep #52135 alive and provide engineers with a clean reproduction profile (clean upgrade, single account, single machine, instrumented before/after).

Anyone else affected — please add

To help Anthropic engineers triangulate, please reply with:

1. Your /usage snapshot (5h % vs weekly %)
2. Your upgrade timing (10x → 20x)
3. ccusage avg tokens/day before vs after the upgrade

If multiple reporters show the same asymmetric pattern + flat consumption, this stops being deniable as "user behavior."

---
Cross-reference: Same pattern reported on #43274 (OPEN), #51715 (OPEN), #51219 (OPEN). Locked/closed precedents on #43118, #41930, #50742, #8449.

Exactly the same behavior. Max rate (20x). A new daily session burned 2% of the weekly limit for 5% usage.

this is the gap between local-log accounting (ccusage and Claude-Code-Usage-Monitor) and Anthropic's server-side quota. they measure totally different things. ccusage will happily say 5% used while the server says rate-limited, because the server tracks something the client never sees, including whatever weight Opus 4.7 1M actually carries vs 200k. until Anthropic ships the per-model breakdown you're asking for, the only honest signal is the same internal endpoint https://claude-meter.com/r/evdd4mx2 renders. anything that doesn't read that is guessing.

Update — Day 9-10 progression: Weekly meter hit 100% but requests are NOT being blocked

Following up on my earlier comment with a decisive new observation.

Timeline

| Time | Weekly meter | Notes |
|---|---|---|
| 2026-05-09 morning | 80% | (initial datapoint) |
| 2026-05-09 12:38 JST | 88% | |
| 2026-05-09 14:00 JST | 91% | (+11pp in ~14h on Day 9 alone) |
| 2026-05-10 21:53 JST | 100% (resets in 7h) | Cap hit, but… |

The decisive observation

The Weekly meter has reached 100%, yet my API requests continue to be served without any blocking, throttling, or "limit reached" error.

I'm typing this comment via Claude Code right now. My Session (5hr) meter is at 4% (healthy). On 2026-05-10 alone, 139M tokens of consumption have been recorded by ccusage — happening after the Weekly meter already showed 100%.

What this proves (this is no longer speculation)

Three independent surfaces on my account are now visibly disagreeing on the denominator:

1. Session (5hr) meter — scaled to 20x (4x of 10x) ✅ correct
2. Weekly (7day) meter display — scaled to 10x ❌ wrong (which is why it hit 100% prematurely)
3. Weekly (7day) enforcement — scaled to 20x ✅ correct (which is why no requests are being blocked)

Surfaces 2 and 3 should be reading from the same denominator. They are not. One was migrated to 20x at the tier upgrade, the other was not. Plan recognition itself is correctly 20x (surface 1 confirms this).

This is the cleanest possible reproduction of a partial database migration — the Weekly meter display record is stuck at the 10x value while the Weekly enforcement record was migrated to 20x.

ccusage data (raw token consumption)

| Date | Total tokens | API-equiv cost |
|---|---|---|
| 2026-05-09 | 216.5M | $185.77 |
| 2026-05-10 (through 21:53 JST) | 139.2M | $100.86 |
| Day 9-10 combined | 355.7M | $286.63 |

These are normal, non-runaway usage volumes from my standard parallel-agent workflow (multiple concurrent Claude Code sessions, all routine work).

Cross-references

• Anthropic Conversation ID: 215474234242958 (escalated to human Product Support on 2026-05-09 ~13:40 JST; awaiting human-agent reply)
• This supplements my earlier comment in this thread.

Call for repro

If any other Max 20x subscriber can reproduce the "Weekly meter at 100% but requests still being served" state, please post — that's the unambiguous smoking gun the Anthropic engineering team needs to localize the partial-migration bug.

Correction to my Day 9-10 comment

I need to retract part of my previous comment.

What I got wrong: I claimed that the Weekly meter display and the Weekly enforcement were running on different denominators (10x display / 20x enforcement). After continuing to observe, the meter hit 100% and within roughly an hour my requests were blocked. The "100% but still being served" state I reported was just a short grace period or aggregation lag — not evidence of a separate enforcement codepath. My fault for over-reading a short-time observation.

The core hypothesis is unchanged — and arguably stronger because it's simpler:

The Weekly quota denominator on my account does NOT appear to have been scaled by 4× when I upgraded from 10x to 20x. The 5-hour denominator was scaled correctly. The Weekly denominator was not (or only partially).

Two-line evidence

| | Pre-upgrade 10x (final 5 days) | Post-upgrade 20x (first 10 days) |
|---|---|---|
| Real consumption (ccusage avg tokens/day) | 344M tokens/day | 334M tokens/day (essentially flat) |
| Days to fully deplete Weekly meter | ~6 days (historical 10x behavior) | ~10 days (observed on 20x) |

If the 4× scaling were correctly applied to the Weekly denominator, time-to-depletion should be ~24 days. Observed is ~10 days = roughly 2.4× the 10x baseline, far below the 4× the plan promises. Actual token consumption per day is flat (~−3%) between the two periods, so this is not a usage-pattern change.

What I'm dropping

I'm no longer claiming "meter at 10x / enforcement at 20x" — that was a misread of a short grace window after 100%. The cleaner statement is simply:

The Weekly quota denominator was not scaled by 4× at the tier upgrade. The 5-hour denominator was.

That single asymmetry is the bug worth fixing.

Status

• Anthropic Conversation ID: 215474234242958 (escalated 2026-05-09; still awaiting human-agent reply)
• Weekly meter just reset (2026-05-11 ~04:53 JST). Will track the next cycle's depletion rate as additional data.

Same issue here. Max 20x, using Opus 4.6 (not 4.7), Claude APP

My weekly limit reset today (May 15). After about 4 hours of normal single-session dev work I'm already at ~10% weekly usage. No parallel sessions, no subagent workflows, nothing unusual.

More importantly: the 50% weekly limit increase announced by @ClaudeDevs on May 13 does not appear to be reflected on my account at all. The burn rate is identical to what I was seeing before the announcement.

I reached out to support through the Fin chatbot and got generic responses with no ability to escalate to a human. The bot couldn't even confirm whether the 50% increase was applied to my account.

At $200/mo on the highest consumer tier, we need actual transparency on what's being counted against the weekly cap. A percentage bar with no breakdown is not enough to diagnose whether this is a metering bug or an accounting issue.

Would love to see Anthropic acknowledge this and provide per-session token breakdowns so we can verify the math ourselves.

I'm experiencing the same issue on Max 20x with Opus 4.6 (not 4.7). My data suggests cache_read_input_tokens are being counted at full rate against weekly quota instead of the documented reduced rate.

Data from my sessions (2026-05-17):

Three sessions with minimal actual work but high cache_read:

| Session | Cache Read / Request | Requests | Total Cache Read | Cache Hit Ratio |
|---------|---------------------|----------|------------------|----------------|
| A | ~600k | 7 | 4,207,945 | 99.97% |
| B | ~100k | 19 | 2,072,200 | 99.89% |
| C | ~105k | 7 | 737,857 | 99.81% |

Cache hit verification:

cache_read_input_tokens: 602,082
cache_creation_input_tokens: 162
input_tokens: 3
output_tokens: 6
hit ratio ≈ 99.97%

Weekly quota anomaly:

• 08:38:39: Claude 7d = 13%
• 09:08:41: Claude 7d = 14% (+1%)
• Between: 1 request with 105,851 cache_read tokens
• If cache_read at reduced rate (1/10): ~10,709 equivalent tokens
• Problem: +1% weekly quota cannot be explained by ~10k equivalent tokens on Max 20x

This matches the pattern in #45756 (Opus 4.6 cache_read full rate) and suggests the weekly quota accounting plane applies different weighting than documented for subscription plans.

I've filed a separate issue (#59872) with more detailed data focusing specifically on the cache_read accounting issue with Opus 4.6.

@cyh7789's cache_read_input_tokens-at-full-rate hypothesis is the most actionable specific claim in this thread, and it lines up with what would mechanically explain why the meter feels disproportionate even on workloads that the docs say should be cheap.

Three independent observations from running tier-routed multi-process workflows on Max (20x) for the last several weeks:

1. Cache-read accounting and conversation depth. Long, structured conversations (the kind multi-agent orchestration produces by design — repeated reads of the same skill/spec files, sub-agent dispatch context replayed each turn) skew an account's cache_read share upward relative to the average single-shot user. If cache_read_input_tokens is being counted at the documented reduced rate in some code paths and full rate in others, then accounts whose usage shape is cache-read-heavy will hit the weekly cap earlier even with identical "logical" workload. That fits the gap @homura-tsurugi documented (their correction explicitly retracted the 10x/20x denominator-mismatch theory but left the per-token-type accounting open).

2. The "17% within minutes of reset" data point in the OP is the most diagnostically useful number. A fresh session, no parallel work, no subagent-heavy workflow, burning ~17% of session budget in a short burst is consistent with either (a) the session-budget meter being denominated against a smaller-than-advertised slice for Opus-1M plus (b) cache-read tokens leaking into a higher-rate bucket on session warmup specifically. The session-warmup burst is when caches are built, not read — so even if cache-read accounting were perfect, the build-phase tokens would skew the early-session burn. A breakdown of {input, cache_create, cache_read, output} on /usage would let users self-diagnose which of these is the actual culprit.

3. Cross-correlation with the "20x vs 5x" framing. The two cleanest external explanations — (a) Opus 4.7 with 1M context is accounted more aggressively than communicated, or (b) the "20x" multiplier quietly shrank after the 4.7 rollout — collapse into the same observable on the UI side (a creeping bar without per-bucket attribution). The OP's third option ("there is a measurement / accounting bug") is the one this thread can actually advance, because it's testable from instrumentation Anthropic already has server-side.

For triage, the highest-leverage single thing this issue is asking for is: expose the per-token-type breakdown on /usage (input / cache_create / cache_read / output), separately for "this session" and "this week". That single artifact would:

• let @cyh7789's cache_read_input_tokens hypothesis be falsified or confirmed in one screenshot;
• distinguish a measurement bug from a positioning gap (which require very different fixes);
• give users a self-throttle signal that doesn't depend on Anthropic shipping a fix first.

The transparency ask in the OP's "What Should Happen" #2 ("UI should show what is being counted, not just a creeping bar") is the right anchor — without that breakdown, every reproducer in this thread (and every future one) will be a guess.

@cyh7789 this matches my experience exactly. Max 20x, Opus 4.6, normal single-session dev work through the Claude app. 4 hours in and already at ~10% weekly after a fresh reset. No parallel sessions, nothing unusual.

The cache_read_input_tokens being counted at full rate instead of reduced rate would explain everything. Claude Code rereads project files constantly so if those cached reads are hitting the quota at 10x what they should, it makes total sense that the weekly limit drains this fast regardless of the 50% increase.

I tried getting answers through Anthropic support (Fin chatbot, conversation ID 215474318691212) but couldn't reach a human or get any confirmation on whether the May 13 increase was even applied.

Following #59872 for the detailed cache_read accounting data. Completely agree with @kcarriedo that exposing per-token-type breakdown on /usage (input / cache_create / cache_read / output) is the single most useful thing Anthropic could do here. Without that we're all guessing.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.