[BUG] claude-fable-5-1 metered at ~200K on Claude Code 2.1.252 (model marked disabled but still served; docs list three different minimum versions)

Hi! First — congratulations on the Fable 5.1 launch, and thank you for the pace you've all been keeping lately. 💛 I hit this a few hours after release and thought the measurements might be useful while it's fresh. Nothing here is urgent for me; I have a workaround.

Summary

On Claude Code 2.1.252, sessions running claude-fable-5-1 are held to a ~200K context window and auto-compact early. On the same machine, same plan, same hour, claude-fable-5, claude-opus-5 and claude-sonnet-5 all run past 800K with zero compactions.

The client marks the model unsupported at this version — the picker carries:

{"value": "cc-update-required-1",
 "label": "Fable 5.1 (disabled)",
 "description": "Update to 2.1.255+ to use Fable 5.1"}

Yet ~300 assistant turns still ran on claude-fable-5-1, the model ID arriving out-of-band rather than through the picker. Once running, nothing in the session indicates it is operating at roughly one fifth of the model's documented window.

Compounding it, three official surfaces give three different minimum versions:

| Source | Minimum version |
|---|---|
| Help Center, "Claude Fable models on your plan" | 2.1.250 or later |
| The model picker in the client | 2.1.255+ |
| CHANGELOG | Added in 2.1.257 |

I was on 2.1.252, which satisfies the Help Center's stated requirement.

Environment

Claude Code 2.1.252 (native install) · macOS 25.3.0 · Claude Max

Mechanism

The string claude-fable-5-1 does not appear anywhere in the installed 2.1.252 binary. The baked-in model catalog contains claude-fable-5 but no -1 variant, and the 1M-eligibility lookup appears to fall back to a hardcoded 200000 default when it misses.

Measurement

Live context size per assistant turn, read from native session JSONL as input_tokens + cache_read_input_tokens + cache_creation_input_tokens. 36 transcripts, ~11,600 assistant turns, last 3 days:

| Model | Turns | Compactions | Max context reached |
|---|---|---|---|
| claude-fable-5 | 6,049 | 0 | 821,098 |
| claude-opus-5 | 3,284 | 0 | 814,645 |
| claude-sonnet-5 | 1,213 | 0 | 787,812 |
| claude-fable-5-1 | 311 | 10 | 178,333 |

Fable 5.1 accounts for 10 of the 11 compactions in the corpus and never crossed 200K. Compactions clustered tightly at 160,265 / 165,184 / 166,193 / 178,333.

The clearest evidence is two within-session A/B cases. Both sessions carried large contexts comfortably on claude-opus-5, then compacted repeatedly on switching model — same conversation, same machine, same binary, model string the only variable:

Session A:  3h09m on opus-5 → 414,009 tokens, 0 compactions
            → switched to claude-fable-5-1
            → 4 compactions in 76 minutes, at 165K–178K

Session B: 11h38m on opus-5 → 699,314 tokens, 0 compactions
            → switched to claude-fable-5-1
            → 3 compactions in 92 minutes, at 160K–166K

Measured twice, independently, minutes apart. Every structural finding was identical across both runs.

Ruled out

CLAUDE_CODE_DISABLE_1M_CONTEXT, CLAUDE_CODE_MAX_CONTEXT_TOKENS and ANTHROPIC_DEFAULT_FABLE_MODEL are unset — verified in shell, all shell profiles, and launchd. Docs state Fable 5.1 is 1M with no beta header and no tier gate, and the Help Center states Fable 5 and Fable 5.1 behave identically on Max.

Prior art

This is the same defect class recurring across model launches:

• #77125 — "/context uses 200k window for claude-fable-5, which has a 1M context window" (2026-07-13, closed). Identical symptom, previous Fable model.
• #76751 — "Statusline payload reports context_window_size: 200000 on 1M-context session (claude-fable-5)" (2026-07-11, open). Same 200K fallback surfacing through the statusline payload.
• #76522 — "Fable 5 asserts false ~15M context window (actual 1M) and declines compaction on loaded sessions" (2026-07-10, open). Inverse direction, same underlying uncertainty about what window a Fable session is actually on.
• #46372 — "MAX 5x subscriber stuck at 200K context window instead of 1M" (2026-04-10, closed). Earlier instance on a subscription plan.
• #91326 — "Agent list labels the 1M context window inconsistently between model families (Fable vs Opus)" (2026-09-01, open). Filed the same day as this one, also Fable 5.1, also 1M-window handling — different surface, likely the same seam.

Also from the CHANGELOG: "Fixed Opus 4.7 sessions showing inflated /context percentages and autocompacting too early — Claude Code was computing against a 200K context window instead of Opus 4.7's native 1M" — and "Fixed Fable 5 model names with a [1m] suffix not being normalized."

Each fix looks keyed to a specific model string, so each new 1M model appears to reintroduce it at launch. That pattern, rather than this single instance, is the thing I'd gently flag as worth fixing once.

Suggested

1. Align the three version numbers — that alone would have prevented this for me.
2. A model the running build has marked unsupported shouldn't be selectable out-of-band — and if it is served anyway, the session should say so rather than quietly using a fallback window.
3. Longer term: resolve the context window per-model at runtime rather than from a client-side catalog, so the next 1M model doesn't need a fix at all.

Happy to run anything else that would help. I'll update once I'm on 2.1.257 to confirm it resolves. Thanks for everything you build 🎾