[Bug] Weekly usage limit consumption rate increased ~3.6x after September 25 reset

Same here, and the timing matches. I upgraded Max 5x -> Max 20x on Sep 25, 2026 (prorated charge paid, Settings shows "Max plan - 20x more usage than Pro"). Within about one day of Claude Code use, "Weekly - all models" is at 97% (5-hour window 20%, Fable weekly 10%). The drain looks like the 5x rate, not 20x, with a similar workload (Claude Code desktop, Opus, several parallel sessions). Windows 11. Possibly also related to #79773 (weekly counter not recalculated after a mid-cycle 5x -> 20x upgrade). Support ticket opened and escalated; no answer yet.

Same here, with a clean baseline: I exhausted the previous week exactly, so its volume ≈ 100% of the meter.

Setup: Max 20x, Claude Code 2.1.283, macOS. Weekly reset Sep 25 7pm (Asia/Almaty), next Oct 2 7pm.
Previous week ended with "You've hit your weekly limit" on Sep 25 at 6:38pm, 22 minutes before the reset.

Numbers from local transcripts, deduplicated per API response (message id), main sessions + subagents:

| | This week, first 51h | Previous week, same 51h | Previous week, full (≈100%) |
|---|---|---|---|
| Meter ("Current week, all models") | 50% | — | 100% |
| Responses | 18,911 | 23,708 | 55,868 |
| Cache read | 5.08B | 5.07B | 13.27B |
| Cache write | 64M | 76M | 162M |
| Output | 10.2M | 26.5M | 50.1M |
| At API list prices | $1,656 | $3,576 | $7,658 |
| Main model | Opus 5.5 (88%) | Opus 5 (84%) | Opus 5 (73%) |

By every measure this week is 20–40% of last week's volume (responses 34%, cache read 38%, cache write 40%, output 20%, API-price equivalent 22%), yet the meter reads 50%. So the meter now moves 1.3–2.5× faster per unit of work than the week before. At the same point last week I had used as much or more on every row.

This is the opposite of the launch announcement ("It's priced lower than Opus 5, so your 5-hour and weekly limits go 25% further"). If limits track price, this week should read ~22%, not 50%.

Same effort level on both models (xhigh, per transcripts), same subagent-heavy long sessions (/usage shows the same profile for 24h and 7d). The main difference between the weeks is Opus 5 → Opus 5.5.

The numbers cover all my usage: I use only the Claude Code CLI, on this one machine — no claude.ai, no Desktop, no other devices.

At this rate I hit 100% around Sep 29, ~2.5 days before the reset. Could you confirm whether Opus 5.5 is weighted differently from Opus 5 in subscription limits, or whether this is a metering bug? If it's a bug, will affected weeks be compensated?

---

Update: the limit also misbehaved around the reset itself. From the same transcripts (times Asia/Almaty, my reset is 7pm):

• 6:38pm: one session gets "You've hit your weekly limit · resets 3pm (Asia/Almaty)". The stated reset time is wrong: earlier limit messages (e.g. Sep 11) said "resets 7pm", and /usage now says Oct 2 7pm. 3pm had already passed.
• 6:41–7:05pm: other sessions keep getting normal Opus 5.5 responses, while that session stays blocked (same error again at 6:39pm and 6:55pm).
• 7:25pm and 7:26pm, 25 minutes after the reset: the blocked session still gets "You've hit your weekly limit · resets 3pm". The next request at 7:26:30pm goes through.

So around the Sep 25 reset the limit was enforced inconsistently between sessions, lingered ~25 minutes past the reset, and reported a wrong reset time. The ~20 minutes of work the other sessions did before the reset slightly inflate the previous week's 100% baseline; against a full week that doesn't change the ratios above materially.

Same pattern here, with numbers from local transcripts.

Setup: Max 20×, macOS. Claude Code CLI 2.1.282 plus the desktop app (Code tab). Mostly Opus 5.5 at high/xhigh, auto mode, many subagents. claude auth status confirms the CLI and the app use the same org. Fast mode was not used.

This week (reset Sep 26 14:00 UTC, measured Sep 28 01:42 UTC): weekly limit at 93%.
One contributor worth ruling out on your side: the official security-guidance plugin (claude-plugins-official). It auto-updated to 2.0.8 on Sep 25, the same day the faster burn started for me.

What 2.0.8 changed (upstream Sep 9):

• It registers SubagentStop, so its end-of-turn review now also fires every time a subagent finishes.
• It adds commit/push matchers for git -C <dir> commit|push, the form worktree agents typically use.

Both default to Opus 4.7, and the commit review is an agentic run of up to 18 turns.

My numbers (macOS, Max 20×, heavy subagent/worktree use):

• Commit reviews, counted as "entrypoint":"sdk-py" transcripts under ~/.claude/projects: 20–60/day in early September, then 60, 115 and 108/day on Sep 24–26 after the update.
• This week: 118 reviews, ~1,500 Opus 4.7 calls, about $100 of API-equivalent usage, roughly 10% of my week, with zero findings.
• The end-of-turn diff review fired 361 times in 10.7 h (98 Stop + 867 SubagentStop events, per ~/.claude/security/log.txt). Those calls go straight to /v1/messages and leave no transcript, so their cost is invisible locally. Their 1–2 s durations suggest many may not reach the model on a subscription sign-in (see #96860), so I can't size them.

For me this explains ~10%, not 3.6×, but it scales with subagent count, so heavier agent users may see more. Related: #85421 (commit review is default-on, unbudgeted, usage discarded).