[Bug] Claude Max session quota drains abnormally fast across Opus, Sonnet, and Fable

<img width="2312" height="2130" alt="Image" src="https://github.com/user-attachments/assets/a8e04b2b-bf05-430d-8c6d-88fdce65f6fa" />

Additional evidence — session usage reached 80%

The abnormal drain has continued.

Updated timeline:

• 9:47 pm — 10% used
• 10:09 pm — 21% used
• 11:02 pm — 56% used
• 11:32 pm — 80% used

That is an increase of 70 percentage points in approximately 1 hour 45 minutes.

More specifically, usage increased from 56% to 80% in only 30 minutes while continuing the same Claude Code project. I was using Sonnet 5 during this latest period and did not run another Claude project or parallel session.

The Claude Code usage panel also reports:

• Session usage: 80%
• Weekly usage: 79%
• Weekly Fable usage: 5%
• 100% of usage was at greater than 150k context

I understand that a context above 150k is more expensive. However, the same project architecture and large protocol context worked normally for approximately two weeks before this sudden regression began around July 31.

The current behaviour is therefore a major change from the established baseline, not simply the existence of a large context.

Screenshot attached showing the 80% usage reading at approximately 11:32 pm on August 1, 2026.

Angel here, founder of Runa. A 70-point quota jump in 105 minutes on the same project is not normal workload variance; it is spend without control. At https://runacode.io, we measured ~46% lower token cost on real runs. New users get $50 of machine usage, and Claude Code signs in with an existing Claude subscription. Want to try the same workflow?

Same pattern here, still ongoing in August. Adding hard numbers from a heavy daily-driver setup, plus a second effect that makes it worse.

Environment: Claude Code 2.1.232, WSL2 (Linux 6.18, x86_64), Max 20x plan, four concurrent sessions on one machine.

Weekly limit burn (from my own logs):

| date | weekly usage |
|---|---|
| Jul 28 | 62% |
| Aug 4 | 62% → 70% (one day) |
| Aug 5 | → 73% |
| Aug 7 | 54% → 69% (one day) |
| Aug 10 | 78% |
| Aug 11 | 91% |
| Aug 12 | 91%, hard-throttled for the rest of the week |

The weekly quota is effectively gone in ~5 days of ordinary work, and I am not running anything exotic: no fan-outs, no long-running loops, most execution delegated to Sonnet subagents specifically because they are cheap. A cost breakdown of my own week: Sonnet ≈$37 vs Fable ≈$296 for comparable volumes of work. Even after moving the main loop to Opus and cutting every avoidable call, we do not fit inside the weekly limit.

The part that makes it worse — forced model switching burns quota for nothing.

Fable 5 has become effectively unusable directly: the built-in safeguard keeps switching the session to Opus 4.8 on ordinary engineering tasks. I switch back with /model, it switches away again, I switch back — over and over. Every one of those round trips costs tokens (context re-read, agents re-spawned) and produces zero work. On Aug 14 alone these switch/return cycles burned ~4% of the weekly limit with nothing to show for it, and it is genuinely maddening to work against.

Related, and this is not a separate annoyance but a direct contributor to the quota problem in this issue: #86100 (safeguard switch is sticky, session never returns to the selected model) and #78688 (post-switch model re-spawns duplicate agents → double token burn).

I reported a related squeeze back in April (#55053) — that one was about the 5-hour window; this is the weekly limit, and it has been recurring every week since late July.