Max 20x plan drained in ~22 hours after Fable 5.1; 5.1 emits 2x the output per turn of Fable 5

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?

What happened

Two years of daily Claude Code use on this machine, running the same production workload throughout: same automated fleet, same repos, same working pattern. On 2026-09-02 my Max 20x plan went from a zeroed counter to 88% of the weekly limit in about 22 hours. I have never had a plan drain in a day.

Data

Three live reads of GET /api/oauth/usage (anthropic-beta: oauth-2025-04-20), one account, same afternoon:

| time (UTC) | weekly | Fable bucket |
|---|---|---|
| 16:22 | 79% | 99% |
| 16:45 | 81% | 100% |
| 18:31 | 88% | 100% |
aprox 30 min later 100% | 100% |

4 to 5 percentage points per hour. A second account used on this machine reads Fable 100% at 57% weekly.

What changed

Fable 5.1 emits about twice the output per turn that Fable 5 did. In the five long-running sessions that ran both models:

| model | turns | output tokens / turn |
|---|---|---|
| claude-fable-5 | 6,613 | 783 |
| claude-fable-5-1 | 1,222 | 1,596 |

2.04x. Across every session on this machine, 2.07x. Opus 5 averages 637.

Turn volume did not rise. 2026-09-02 ran 10,633 turns against 2026-08-14's 10,093: 5% more turns, 88% more output tokens.

Method: every assistant turn in ~/.claude/projects/**/*.jsonl, read from message.usage, deduplicated on (sessionId, message.id). Within a session the two models run sequentially, so this controls for project and working style, not for individual task.

The client auto-updated to 2.1.257 at 2026-09-01T20:39Z. Sessions pinned to the fable alias moved from Fable 5 to 5.1 with no /model command and no notice.

Ask

Was Fable 5.1's higher output per turn expected, and were plan Fable allowances re-tuned for it?

What Should Happen?

A weekly allowance should not go from zero to 88% in about 22 hours on an unchanged workload.

A model update delivered through an existing alias should not double output tokens per turn against a capped bucket, and if it does, the plan allowance for that bucket should be re-tuned to match, or the change should be announced.

Error Messages/Logs

Fable bucket exhausted, then the 5-hour window closing across five worktrees within 35 seconds:

2026-09-02T16:45Z  You've reached your Fable limit. Run /usage-credits to continue or switch models with /model.
2026-09-02T17:54Z  You've reached your Fable limit. Run /usage-credits to continue or switch models with /model.
2026-09-02T18:33Z  You've reached your Fable limit. Run /usage-credits to continue or switch models with /model.
2026-09-02T18:53:43Z  You've hit your session limit - resets 10pm (Europe/Lisbon)
2026-09-02T18:53:51Z  You've hit your session limit - resets 10pm (Europe/Lisbon)
2026-09-02T18:53:57Z  You've hit your session limit - resets 10pm (Europe/Lisbon)
2026-09-02T18:53:58Z  You've hit your session limit - resets 10pm (Europe/Lisbon)
2026-09-02T18:54:18Z  You've hit your session limit - resets 10pm (Europe/Lisbon)

No "weekly limit" message was emitted on this account today; the weekly meter was last read at 88%.

Steps to Reproduce

1. Use Claude Code across the Fable 5 to 5.1 boundary (client auto-updated to 2.1.257 on 2026-09-01T20:39Z), with sessions pinned to the fable model alias so they follow the alias onto 5.1.
2. For sessions that span the boundary, read every assistant turn from ~/.claude/projects/**/*.jsonl, deduplicate on (sessionId, message.id), and group message.usage.output_tokens by message.model.
3. Compare mean output tokens per turn for claude-fable-5 against claude-fable-5-1 within those same sessions. Here it is 783 against 1,596.
4. Watch the plan meter with GET /api/oauth/usage (header anthropic-beta: oauth-2025-04-20). The response carries five_hour, seven_day, and a limits[] array whose weekly_scoped row is the Fable bucket.

Claude Model

Other

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.252

Claude Code Version

2.1.258 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

Possibly the same class as #74972, which GitHub flagged as a potential duplicate while I was filing this. That report describes weekly usage metered roughly 4 to 8x too fast immediately after a weekly reset, with the Fable bucket disproportionately ahead of the overall weekly meter (Fable 81% at weekly 51%), and says /logout followed by re-login restored the normal rate. It was auto-closed for inactivity on 2026-08-31, not resolved.

Two details here line up with it. Anthropic zeroed usage counters at the Fable 5.1 release on 2026-09-01, so this account's fast burn also began immediately after a reset. And a second account on this machine currently reads Fable 100% at weekly 62%, the same disproportion that report describes.

I have not yet tried the /logout workaround, so I cannot say whether it applies. If it does, the output-per-turn measurement above is a separate and additive finding rather than the cause.

Scope of my measurements. More than one account has been used on this machine and a session records its owner when the session is created, so work continued after a re-login is misattributed. I have therefore not published any per-account token attribution. The output-per-turn figures need no attribution, and the meter readings are exact per account.

What I am not claiming. I first suspected 5.1 of causing repeated 5-hour session-limit hits. My own logs refute that: earlier Fable 5 days hit that window just as often. Those track workload, not model version.

Related, same window and consistent but unmeasured: #91289, #91486, #91487, #91494. Ruled out here: #91331 (200K context window, needs a client older than 2.1.255) and #91514 (prompt-cache re-write; this machine holds a steady 98% cache hit rate).