Max 20x: weekly limit exhausted in ~3h from a 0 start and capped BEFORE the 5-hour session limit; observed reset ≠ displayed reset — has behavior changed?

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?

On the Max 20x plan (highest tier), my weekly usage limit is being consumed far faster than before and — counterintuitively — it became the binding cap before my 5-hour session ("daily") limit did, with no warning.

The decisive detail: at my reset point (~16:50 local time, today) both meters read 0% — the 5-hour session limit and the weekly (all-models) limit started from zero together. After ~3 hours of a workflow I have run for weeks, /usage showed the session at 47% but the weekly (all models) at 85%. Because both started at 0 at the same moment, this is not prior accumulation — the same usage over the same window put the weekly at nearly double the session, i.e. the weekly Opus budget is being exhausted in well under a single 5-hour session window.

This is new behavior: I ran the exact same workflow at the same pace last week and sustained it across the entire week without exhausting the weekly. Additionally, the weekly reset date shown in /usage does not match the reset I actually observed (~16:50 today). This pattern — limits on a paid plan apparently changing mid-cycle, silently, with the displayed reset date not matching reality — is the core problem. It is hard to plan against and feels like a silent change to a product I have already paid for.

What Should Happen?

Transparency and consistency on a paid plan:

1. Usage limits on a paid plan must not change silently mid-cycle — notify customers in advance, and keep a dated public changelog of limit changes.
2. Publish the actual capacities (5-hour session vs weekly; Opus-only vs all-models) so paying users can see and plan against what they're entitled to, instead of inferring from percentages.
3. The weekly should not be exhaustible in ~3 hours on a 20x plan from a zero start, and it should not cap before the 5-hour session limit without any warning. If that is intended, surface it clearly.
4. The reset date/time shown in /usage should match the actual reset.

I am not asking for new features — only transparency about what I'm paying for and notice when it changes.

Error Messages/Logs

No error message (this is a limit/accounting/transparency issue, not a crash). /usage output at the time (location/timezone redacted, secrets removed):

Current session:            47% used   (resets later today)
Current week (all models):  85% used   (resets in several days)
Current week (Sonnet only):  0% used
Session totals: $345.89 ; predominantly Opus (claude-opus-4-8 + claude-opus-4-6)
Contributors (last 24h): 76% with 4+ parallel sessions; 53% >150k context;
                         31% subagent-heavy; 29% sessions active 8+ hours

Steps to Reproduce

1. On Max 20x, at a weekly reset point where both the 5-hour session and weekly meters read 0%.
2. Run a heavy, predominantly-Opus Claude Code workload (multi-agent: a dispatcher session plus worker subagents that each spawn reviewer subagents, partly across parallel sessions) for ~3 hours.
3. Open /usage.
4. Observe: session ~47%, weekly (all models) ~85% — i.e. the weekly is capped before the session despite both starting at 0, and the displayed weekly reset date does not match the reset observed at ~16:50 today.

Claude Model

Opus (claude-opus-4-8 and claude-opus-4-6)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Last week — the same workflow at the same pace sustained the full week without exhausting the weekly limit (exact version not recorded).

Claude Code Version

2.1.185 (Claude Code)

Platform

Claude subscription (Max 20x)

Operating System

macOS

Terminal/Shell

Terminal.app (macOS) / zsh

Additional Information

Key points: (1) both meters were at 0% at 16:50, so there is no prior-accumulation explanation; (2) week-over-week regression — identical pace ran fine all last week, exhausted ~85% of the weekly in ~3h this week; (3) the Help Center says weekly limits reset at a fixed account time, which conflicts with the reset I observed at 16:50 today and with the date /usage displays; (4) the request is transparency, not features. Personal details/timezone have been redacted.