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

Preflight Checklist

• [x] I have searched existing issues
• [x] This is a single bug report
• [x] I am using the latest version (2.1.117)

What's Wrong?

On the Max (20x) plan — the top subscription tier — the weekly quota depletes far faster than the "20x" positioning implies. Two concrete data points from a single machine, single active session at a time, no parallel sessions, no subagent-heavy workflows:

Earlier today (before the most recent session reset):

• Current session: 14% used (session had just started, resets in 4h 45min)
• Weekly (all models): 51% used, resets Mon 9 PM
• Weekly (Sonnet only): 10%
• Claude Design: 0%

Right after the session limit reset (just now, single short burst of work):

• Current session already at ~17% used

At this burn rate on Opus 4.7 (1M context), the weekly cap will be exhausted well before Monday — on the tier that is explicitly sold as 4× the budget of Max (5x).

One of:

1. Opus 4.7 with 1M context is accounted far more aggressively than is communicated,
2. there is a measurement / accounting bug,
3. the "20x" multiplier quietly shrank after the 4.7 rollout.

Either way this needs investigation and transparency.

What Should Happen?

1. The weekly cap on Max (20x) should actually reflect the "20x" positioning. A user doing normal single-session Opus work should not burn 50%+ in 2–3 days.
2. The UI should show what is being counted, not just a creeping bar. Users need a breakdown to self-throttle:

• per-model % (Opus vs Sonnet vs Haiku)
• per-session cost in % of weekly
• whether the 1M-context mode is priced differently from 200k
• cache-hit vs cache-miss ratio

1. Ideally, an on-demand /usage --detailed or plan-page breakdown that shows the last N sessions and what each cost against the quota.

Right now the only signal is "% used" with no explanation, so the limit feels arbitrary and there's no way to budget ahead.

Steps to Reproduce

1. Subscribe to Max (20x)
2. Use Claude Code CLI primarily with Opus 4.7 (1M-context variant) for a few hours/day, single session at a time (no parallel sessions, no subagent spam)
3. After 2–3 days, check the plan page — weekly "all models" is already ~50%
4. Observe that even a single short burst of work right after the session reset pushes the current-session bar to ~17% almost immediately

Error Messages / Logs

None — this is not a crash, it is unexpectedly rapid quota depletion.

Claude Model

Opus 4.7 (1M-context variant, claude-opus-4-7[1m])

Is this a regression?

I don't know (no pre-4.7 baseline on this plan to compare against). Community signal (see related issues below) suggests it worsened after the 4.7 / 1M-context rollout.

Claude Code Version

2.1.117 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux (Debian 13)

Terminal / Shell

Other (Linux interactive shell, bash)

Additional Information

Several open reports appear to describe the same root cause:

• #50742 — "Investigate usage limits on Max 20x subscriptions"
• #47587 — "Usage limits gone crazy"
• #51715 — "Usage limit reached - while session reset"
• #51219 — "Usage limit reached despite UI showing low consumption percentages"
• #41174 — "Usage limit reached in 10 minutes"

The volume of complaints from Max (20x) users specifically is a signal that either the accounting is broken or the tier's economics have quietly changed since the 4.7 release. Please either fix / clarify the accounting or expose an itemized breakdown so users can self-manage.

Screenshot of the plan page will be attached via the web UI after creation (the gh CLI cannot upload user-attachments).