[Bug] Fable 5.1 incorrectly blocked by usage credits despite included Max plan allowance

Same thing here on Max 20x, macOS, native install, Claude account login, usage credits off. Mine happened mid-session rather than at the picker, and a fresh session on the same machine got Fable while the stuck one was still refusing it.

What the transcript shows

The session ran on 2.1.277 with claude-fable-5-1 at 1M context, about 565k tokens in the window. Fable had served it since the previous evening. It then sat idle for 10 hours overnight. The first turn of the morning came back from Fable as normal (07:46 to 07:48 UTC). Two minutes later, on the second turn, the transcript has this (ids and paths removed):

{
  "type": "system",
  "subtype": "model_consent_fallback",
  "level": "warning",
  "content": "Switched to Opus 5 (1M context) for this session · Fable 5.1 requires usage credits · /model to change",
  "choice": "switch_default",
  "originalModel": "claude-fable-5-1",
  "fallbackModel": "claude-opus-5[1m]",
  "persistedAsDefault": false,
  "timestamp": "2026-09-21T07:50:39.637Z",
  "version": "2.1.277"
}

That line is the only trace. The transcript holds no API error entry anywhere.

Usage 47 seconds later

From cachedUsageUtilization in ~/.claude.json, as_of 2026-09-21T07:51:26Z, trimmed:

"limits": [
  { "kind": "session",       "percent": 7 },
  { "kind": "weekly_all",    "percent": 5 },
  { "kind": "weekly_scoped", "percent": 6, "scope": { "model": { "display_name": "Fable" } } }
],
"extra_usage": { "is_enabled": false, "user_disabled": true, "spend_limit_reached": false, "credits_ever_enabled": true }

cachedExtraUsageDisabledReason is "org_level_disabled" and spend.can_purchase_credits is false. That is the same value @mills-nick reported on #79412. The weekly window had reset the afternoon before, so the account sat at 6% of its Fable allowance when the client said Fable needed credits.

Stuck session and fresh session, 28 seconds apart

• 08:03:22 UTC, stuck session, /model then Fable. "Switch to Fable 5.1? Fable 5.1 runs on usage credits, purchased separately from your plan. You don't have usage credits yet." Result was Kept model as Opus 5 (1M context).
• Just before 08:04 UTC, a new session on the same machine and account. /model then Fable gave Set model to Fable 5.1 and saved as your default for new sessions, with no dialog. ~/.claude/settings.json now holds "model": "claude-fable-5-1[1m]".
• 08:06:19 UTC, the new session's first reply came from claude-fable-5-1. Credits were still off.
• 08:06:47 UTC, stuck session, /model again. Same credits dialog, same result.

Both sessions read the same ~/.claude.json, the same settings and the same login. There is one confound. The stuck process is 2.1.277 and the new one is 2.1.278. The 2.1.278 notes say nothing about this check, so I doubt the version explains it, but I can't rule it out from here.

So the account has the entitlement and the server honours it. The refusal lives in the running process, and it was still there 16 minutes after it first fired. The idle-then-fail timing resembles the token refresh path @taehan described on #79337, with two differences. This is macOS, and the first request after the idle succeeded before the second one failed.

I haven't restarted the stuck session yet, so I can't say whether claude --resume <id> --model 'fable[1m]' brings Fable back.

Follow-up. The stuck session recovered by itself, with no restart and no re-login.

At 08:43:29 UTC I ran /model and picked Fable again in the same process, through the same picker path that had refused at 08:03:22 and 08:06:47. This time it answered Set model to Fable 5.1 and saved as your default for new sessions. Replies have come from claude-fable-5-1 since 08:44:59 UTC, 18 of them by 08:59 with no second fallback. Every transcript line through the recovery carries "version": "2.1.277", so the process never restarted, and nobody ran /logout or /login in between.

That puts the refusal at somewhere between 16 and 53 minutes long. It fired at 07:50:39, was last seen refusing at 08:06:47, and allowed the switch at 08:43:29.

cachedExtraUsageDisabledReason in ~/.claude.json read "org_level_disabled" while the picker refused and still reads that now. extra_usage is unchanged too, with credits off. So that cached value can't decide the gate on its own. Whatever flipped sits in the running process and can flip back without a restart or a re-login.

One thing on disk did change in that window, and I don't know whether it is related. Around 08:05 UTC the Fable entry in additionalModelOptionsCache had the description Fable 5.1 · Most capable for your hardest and longest-running tasks. After the recovery (additionalModelOptionsAnsweredAt 08:44:49 UTC) it reads the same plus · $10/$50 per Mtok. Two client versions share that file here, 2.1.277 and 2.1.278, so the difference may only be which one wrote it last.

Same issue here, still reproducing on 2.1.283 (newer than the 2.1.263 in this report).

• Windows 11 Enterprise 10.0.26100, VS Code extension, Max 5x, interactive /login (no CLAUDE_CODE_OAUTH_TOKEN)
• Weekly usage ~8%, usage credits OFF

Additional observations:

• With claude-fable-5-1[1m] there is no prompt. The session silently switches to Opus 5.5, sometimes in the middle of a single reply.
• With claude-fable-5-1, /model says: "Fable 5.1 uses usage credits and needs a one-time consent · pick Fable from /model in an interactive session to set it up". ~/.claude.json already has fableOverageConsentV2: true for the org.
• After /logout + /login, profileFetchedAt is updated but oauthAccount still has no subscriptionType, while organizationType is claude_max. This looks like the same missing-subscriptionType cause reported in #79337.