[BUG] Fable 5.1 falsely gated behind usage credits when the 1M-context variant is pinned; request silently withheld

Preflight Checklist

• [x] I have searched existing issues
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Description

Claude Code refuses to send a request on Fable 5.1 and displays:

Fable 5.1 now uses usage credits · the prompt to confirm went unanswered · nothing was sent · answer it where this session is running, or /model to change

The subscription plan includes Fable 5.1 usage, so the premise of the notice is wrong. Nothing was sent, so the turn is silently lost rather than billed.

The distinguishing detail versus the existing reports: the configured model is the 1M-context variant, pinned in ~/.claude/settings.json:

"model": "claude-fable-5-1[1m]",

1M context is itself a credits-gated feature. This looks like the same plan-tier mapping defect already documented for the Sonnet 1M variant in #61692, except the user-facing string blames the model ("Fable 5.1 now uses usage credits") rather than the context window ("Usage credits required for 1M context"). If that is the same code path, the message is actively misleading: it tells the user their model entitlement is gone when the real gate is the [1m] suffix.

Steps to Reproduce

1. Set "model": "claude-fable-5-1[1m]" in ~/.claude/settings.json on a plan that includes Fable 5.1.
2. Start a session and send any prompt.
3. The confirmation notice appears and the request is not sent.

Expected Behavior

Either the request proceeds on the plan's included Fable 5.1 allowance, or the notice names the actual gate (1M context) rather than claiming the model now requires credits.

Actual Behavior

The request is withheld. The notice asserts a billing change that does not match the account's entitlement.

Evidence the account side is healthy

A direct Messages API call on the same machine returned HTTP 200 with normal usage accounting, so there is no credit exhaustion at the API account level. The block is client-side and decided before send.

I also searched the entire ~/.claude config tree for any cached credit or entitlement flag and found none, so this is evaluated per-request rather than read from stored state. There is nothing a user can clear locally.

Suggested workaround to confirm the cause

Per #61695, CLAUDE_CODE_DISABLE_1M_CONTEXT=1 forces standard 200K context and bypasses the 1M usage-credits check. If that clears this notice for Fable 5.1, the two bugs share a root cause and the message string is the only difference.

Related

• #61692 and PR #61695 — the same false positive on a 1M-context variant, with the CLAUDE_CODE_DISABLE_1M_CONTEXT workaround. PR is open and unmerged.
• #92576, #92577, #92578 — Fable 5.1 falsely blocked by usage credits on an included plan allowance. None mention the [1m] pin.
• #79412 — /model shows Fable as credits-only while /usage shows it covered by the plan.

What Should Happen?

Fable 5.1 should run on the plan allowance that includes it. If 1M context genuinely requires credits on this plan, the notice should say so and name the suffix, so the user can drop to standard context instead of concluding their model entitlement was revoked.

Environment

• Claude Code version: 2.1.269
• Platform: Linux (WSL2), kernel 6.18.33.2-microsoft-standard-WSL2
• Shell: zsh
• Auth: subscription
• Configured model: claude-fable-5-1[1m]