[BUG] Weekly Limit Jumped From ~50% to 100% in less than an hour of usage on Max20x Plan

Same here. From ~20% to 40%.

I just encountered the same bug: my weekly limit usage jumped from 50% to 80% (at max x20) within a 30-to-90-minute window. I just returned to my PC after being AFK and saw a ~30% limit drop in a single hour. For context, my usual daily usage is only 20-30% across a 10+ hour workday. There were no extra heavy tasks running, and checking 'ccusage' via Claude confirmed that everything is normal with no unusual activity.

Same thing here - Max 5x, I closed my macbook and left home (no running sessions) at 60% weekly usage just to come back 3hrs later and see my weekly usage at 95%.... That's literally impossible as a single 100% usage of 5hr session with Opus 4.8 accounts for about 8% of my weekly

Same here

Solved here!

Two distinct things are getting blended in this thread, and separating them is the fastest way to a diagnosis — they have different causes and different fixes.
Signal A — live multiplicative burn (the OP's repro). opus-4-8 + /effort max + a subagent-driven whole-codebase audit (/superpowers) is close to the worst-case token multiplier that exists right now:

• effort=max on Opus 4.8 has been reported to produce far more output/thinking tokens than 4.6/4.7 on the same task — routine turns hitting 40–50k where they used to be 2–3k (the #64153 effort-budget cluster).
• A subagent fan-out then multiplies that: each child runs its own turns, and if each child is also at max effort, you're paying (per-turn effort blowup) × (number of children) × (turns per child). A whole-codebase audit spawns a lot of children.

So the same audit that "barely ticks" at default effort can legitimately consume 50% in 30 minutes at max + fan-out. Fastest test: rerun the identical audit at /effort medium (or default) and/or --model claude-opus-4-7, and watch the /cost delta. If it drops back to "a few percent", that's your cause, and dropping max-effort for broad audits is the fix — reserve max for single hard problems, not fan-out sweeps.
Signal B — usage climbing while AFK / no running session (@Daredevll, @nikitkazhopik: closed the laptop, came back hours later to a big jump). That is not the same bug — nothing should accrue with no active session. That points at either (a) a background/detached process still running (check for stray claude processes, any claude -p/cron/automation, or a plugin keeping a session alive), or (b) usage accounting lag — tokens from the earlier burst being attributed to the wall-clock window when they settle, not when they ran. To tell them apart: look at ccusage (or your session logs) timestamps — if the token spend is stamped during your active session and only the % display moved later, it's accounting lag (cosmetic-ish, your real spend was earlier). If there's token activity stamped while you were genuinely AFK, hunt the background process.
@schalatap — you said "Solved here!" — what fixed it for you? That'd help triage which of A/B everyone else is hitting.
The single most useful evidence for maintainers here is a ccusage export showing token spend vs timestamp across the window, plus whether /effort was max. That distinguishes "expected cost of max-effort fan-out" from "accounting/attribution bug" immediately — and they need separate fixes.
(Reasoning from the repro + the comments here, not your individual sessions — but A vs B is the split worth nailing down before this gets triaged as one bug.)

Same on Max 5x — Opus 4.8 orchestrator + Sonnet subagents, weekly limit draining abnormally fast

Subscription: Max 5x ($100/month). Started June 29, 2026, renewed July 29. First billing month was completely normal with the identical setup.

Starting ~July 26-27 (about a week after the July 29 renewal), consumption spiked with no change in workflow:

• Weekly limit exhausted in 3 days instead of the full week
• 5-hour session limit now hits in under 3 hours
• Right after weekly reset: 18% of weekly gone in a single normal session
• Setup matches this issue exactly: Opus 4.8 as main orchestrator, Sonnet as subagent (agentic/audit-style tasks). This is the same subagent-driven pattern described in the repro here.
• Working nighttime hours (KST, off-peak) — not peak-hour throttling
• Affects both Claude Code CLI and claude.ai web

The subagent spawning during Opus-orchestrated tasks appears to be the accelerant, consistent with this report. First month was fine with the same effort/model config, so this looks like a server-side regression rather than my usage. Requesting investigation + limit reset. Can attach Settings > Usage screenshots on request.