[BUG] Max 20x: one full 5-hour session consumes ~20% of the weekly limit — about 5 sessions per week

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?

I searched before filing and found related reports (listed at the bottom). The closest one, #52135, describes the same shape on the same plan and was closed as not planned without a data response. This report is not a repeat of it: it adds the one measurement those threads are missing — the session-to-weekly ratio captured from a clean weekly reset, with both endpoints read off the app's own usage panel.

What happened

My weekly limit reset about three hours ago. What follows is the first 5-hour session window after that reset — no prior consumption in the week, nothing to disentangle.

That single window is now at almost 100%, and it moved the weekly bar to 20%.

So one fully used 5-hour session costs roughly a fifth of the entire week. On Max 20x that means about five full 5-hour sessions per week. I would like to know whether that ratio is intended.

This was one interactive Claude Code session (with subagents) — no parallel accounts, no automated jobs, no batch work.

Measurements

Both readings come from the same uninterrupted session, inside the same weekly window, immediately after the weekly reset:

| Session window | Weekly bar |
|---|---|
| 57% used | 12% used |
| ~100% used | ~20% used |

Two points that make this worse than the raw numbers suggest:

1. The +50% weekly limit promotion was still active during this window (it runs through Aug 31). Once it ends, the same work consumes ~30% of a standard week — roughly three full sessions per week.
2. I am on the latest extension build, 2.1.251, so this is not the version-specific cache inflation reported in #46917 — that explanation is already ruled out.

Why this matters

I cannot work two days a week and then wait five days for a reset. I genuinely love Claude Code and I need it for real work.

I really don't want to switch to Codex, but what am I supposed to do??? :((

Is this expected behaviour, a regression, or something specific to my account?

Possibly related

• #52135 — same plan, same disproportion; closed as not planned
• #88736 — weekly bar exhausted in August on 30–45% lower measured token consumption than June (Max 20x)
• #88352 — measured shrinkage of the weekly quota pool across consecutive windows (Max 20x)
• #89845 — subagent cost invisible and uncapped; a weekly allowance consumed in 90 minutes
• #38335 / #16157 — long-running reports of Max session limits exhausting abnormally fast

What Should Happen?

Either the accounting is wrong, or it is working as designed and the design is undocumented. Both cases need an answer, and the second one needs it in writing.

Concretely:

1. State the intended ratio. If one fully consumed 5-hour window is supposed to cost ~20% of the weekly pool on Max 20x — meaning roughly five such sessions per week, and roughly three once the promotion ends — say so in the plan documentation. Subscribers cannot plan a work week against a number that is only discoverable by hitting it.

1. If it is not intended, treat it as an accounting defect. #52135, #88736 and #88352 all report the weekly pool draining faster than measured consumption justifies. Those were closed or left unanswered; the pattern deserves a look rather than another closure.

1. Make the cost visible before it is spent, not after. The usage panel shows two bars and no attribution: I cannot see what a session cost me in weekly terms until the week is gone, and subagent spend is invisible entirely (#89845). At minimum: per-session cost expressed as a share of the weekly pool, a breakdown by model, and subagent spend attributed to the task that started it.

1. Warn before a single window consumes a fifth of the week. A threshold notice would let me stop, compact, or switch models while the choice still exists.

A full 5-hour session should not silently cost a fifth of the weekly allowance on the highest consumer tier — and if it must, that should be a documented, predictable number rather than something each subscriber rediscovers on their own.

Error Messages/Logs

No errors and no crash. This is quota accounting: the session completed normally, the numbers below come from the app's own usage panel (Settings → Usage), not from logs or third-party token counting.

Steps to Reproduce

No special code or file is needed — any sufficiently heavy session reproduces it. The point is the ratio between the two bars, both read off the app's own usage panel.

1. Plan: Max (20x). Note the weekly reset time shown in Settings → Usage.
2. Immediately after the weekly window resets, open Settings → Usage and confirm the starting state: weekly bar near 0%, session bar near 0%.
3. Start one interactive Claude Code session (VS Code extension 2.1.251, Windows 11, model Opus 5) and work normally — long-context editing with subagents. No parallel sessions, no second client, no background jobs.
4. At an arbitrary midpoint, open Settings → Usage and record both bars.

Observed here: session 57%, weekly 12%.

1. Continue the same session until the 5-hour bar approaches 100%. Record both bars again.

Observed here: session ~100%, weekly ~20%.

1. Compare the two readings. A single fully consumed 5-hour window has moved the weekly bar by ~20%, i.e. the weekly pool holds roughly five such windows.

Both readings are inside the same weekly window and the same uninterrupted session, so nothing from earlier in the week is mixed in. The +50% weekly promotion was active throughout, which makes the standard-limit ratio worse, not better.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.251 (Claude Code for VS Code extension)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

<img width="3840" height="2064" alt="Image" src="https://github.com/user-attachments/assets/6cd1003e-be2e-4e4c-8bba-296936811255" />