[BUG] Fable 5 / native-1M sessions silently clamp to a 200K context window on Max plan — undocumented, no user-facing notice, no recovery path

Summary

On a Max plan, sessions on claude-fable-5 (a native-1M model) began reporting a 200,000-token context window instead of 1,000,000 — with no error, no banner, and no explanation. The only user-visible signal is the number shown by /context / the statusline payload.

Inspecting the CLI bundle shows this is a deliberate client mechanism: when the API returns a 429 whose message includes "Extra usage is required for long context" or "Usage credits are required for long context", Claude Code sets a session-sticky longContext1mCreditsBlocked flag (telemetry event tengu_1m_credits_clamp_activated) and reduces the effective window to 200K for the rest of the session.

The graceful degradation itself is good engineering — far better than the hard-block in #68561. The problems are:

1. It is silent. The session quietly loses 80% of its context window mid-fleet. Nothing in the UI says the clamp happened or why.
2. It contradicts current documentation. Both the context-window support article and code.claude.com/docs/en/model-config state that Fable 5 / Sonnet 5 / Opus 1M context is included on Max, with no usage threshold. No documented condition explains a Max account being asked for usage credits for long context.
3. It is session-sticky with no recovery. Once flagged, the session stays at 200K even after the server-side condition lifts. New sessions recover; existing ones don't, and there is no /-command to retry 1M.
4. The account cannot comply even if it wanted to. The error demands usage credits, but the OAuth usage endpoint reports can_purchase_credits: false, can_toggle: false and the CLI caches cachedExtraUsageDisabledReason: "org_level_disabled" — on a personal Max plan with no organization. There is no path to satisfy the requirement.

Environment

• Claude Code: 2.1.199 (mechanism also present in 2.1.198 — confirmed in both bundles)
• Platform: Linux (native install), first-party Anthropic API via OAuth
• Plan: Max (personal)
• Model: claude-fable-5 (no [1m] suffix involved; Fable has no 200K variant)
• CLAUDE_CODE_DISABLE_1M_CONTEXT not set; no LLM gateway / ANTHROPIC_BASE_URL; no CLAUDE_CODE_MAX_CONTEXT_TOKENS

Timeline (2026-07-02, UTC-7)

Reconstructed from per-session statusline state files, which record the harness-reported context_window.context_window_size:

| Time window | Model | Reported window |
|---|---|---|
| 2026-07-01 → 07-02 13:35 | claude-fable-5 | 1,000,000 (consistent) |
| 07-02 02:37–03:01 | claude-opus-4-8 (several sessions) | 200,000 (transient — recovered by 03:05) |
| 07-02 14:54 onward | claude-fable-5 (every new session) | 200,000 |

Account usage at the 14:54 flip (from /api/oauth/usage): session bucket 39%, weekly_all 55%, weekly_scoped (Fable) ~70%. During the 02:37 Opus episode: session bucket had just burst 35%→50%, weekly_all 46%.

The clamp fires at session start with ~90K tokens of context — far under 200K — so requests are apparently routed to the long-context tier based on the advertised/native window, not actual input size (same class of observation as #62314's effectiveWindow).

Mechanism (from the published CLI bundle)

• 429 handler: if (s && umo(e.message) && !get()) Evr(!0), q("tengu_1m_credits_clamp_activated", {})
• umo(e) matches "Extra usage is required for long context" / "Usage credits are required for long context"
• Effective window: mE() returns 200,000 whenever the flag is set and the model's window would exceed 200K; claude-fable-5 is context: {window: 1e6, native_1m: true} in the model table, so the flag is the only code path that yields 200K for Fable on first-party auth. The observed statusline value therefore proves the clamp fired.
• The flag lives in session state: initialized false, set on the 429, never cleared → sticky for the session's lifetime.

Likely relationship to the Fable 5 promotional window (speculation, please confirm)

The July 1 announcement says Fable 5 is included "up to 50% of your weekly usage limit" through July 7, then via usage credits. The account's Fable-scoped weekly bucket (whose 100% = that 50% cap) crossed ~70% right as the clamp began. If the intended policy is "long-context tier moves to usage credits as the Fable allowance depletes," that is nowhere documented — and it doesn't explain the transient Opus clamp at 02:37, since Opus 1M is documented as included with the Max subscription.

Expected behavior

1. If usage-gated long-context on Max is intended policy: document it (context-window article + model-config docs + changelog), and disclose the threshold.
2. When the clamp fires, tell the user: a one-line notice ("1M context unavailable — usage credits required; running at 200K") and an annotation in /context.
3. Provide a recovery path: re-attempt 1M on the next 5-hour window / on /model reselect, instead of session-permanent stickiness.
4. Clarify whether Opus (documented as "included with subscription") is ever supposed to hit this gate.
5. Fix or explain can_purchase_credits: false + disabled_reason: "org_level_disabled" on a personal Max account with no org — as it stands, the 429's suggested remedy (/usage-credits) is impossible to follow.

Related issues

• #70310 — silent removal of Sonnet 1M from Max (same disclosure problem, no response)
• #68561 — hard-block "Usage credits required for 1M context" with no in-session recovery (the clamp appears to be the successor behavior; the recovery gap remains)
• #62314 — requests routed to long-context tier by advertised window rather than actual size
• #68226 — Sonnet 4.6 forced to 200K after the Fable 5 suspension