[BUG] Fable 5 prompts 'usage credits required' on Max plan from 2026-07-20, the day it became standard on Max (saved model claude-fable-5[1m])

Reproducing this on a Max 5x plan today (2026-07-20), with server-side usage data that directly contradicts the client's claim.

Web usage page (authoritative, refreshed minutes before the prompt):

• Weekly Fable: 30% used (resets Mon 07:59)
• Weekly All models: 16% used
• Current 5h session: 50% used
• Usage credits: toggle off, never purchased

Claude Code CLI (v2.1.215), /model → Fable 5:

Switch to Fable 5?
Fable 5 runs on usage credits, purchased separately from your plan.
You don't have usage credits yet.
  1. Set up usage credits on claude.ai
  2. No, keep my current model

So the plan-included Fable allowance is at 30% of a 50% cap — well below the threshold the Help Center describes — yet the client insists Fable is credits-only and is not part of the plan. Repeated /model attempts give the identical prompt.

Two extra data points that may help narrow it down:

1. The session was already running Fable 5 when this started. It began on Fable and kept serving Fable; only switching to it afterwards is blocked. That is consistent with the entitlement being evaluated at switch time from stale/incorrect client-side state rather than the model being genuinely unavailable — and it also explains the non-zero 30% bar (that usage is real, and it was never billed to credits, because there are none).
2. Account entitlement cache (~/.claude.json → oauthAccount.profileFetchedAt) was refreshed 46 minutes before the prompt, so this is not an obviously stale-profile problem: hasExtraUsageEnabled: false, organizationRateLimitTier: default_claude_max_5x.

Also worth noting the promotional uplift currently shown on the same usage page (Claude Code weekly limits +50% until Aug 19) — per #74051 the credits gate appears to ignore active promotional allowance too.

The practical impact is that the only offered path is to purchase credits for capacity the plan already grants and the account has 70% of remaining.

same

One more data point that rules out the documented prerequisite: the Help Center article (Claude Fable 5 on your plan) states "In Claude Code, Fable 5 requires version 2.1.170 or later." The affected client here is 2.1.215, so the version requirement is met and cannot explain the credits prompt.

The same article also states the access rules are platform-independent — "This works the same way across Claude on the web, Claude Mobile, Claude Desktop, Claude Cowork, and Claude Code" — and that on Max plans "Fable 5 is included as a standard part of your plan. You can use up to 50% of your weekly usage limits on Fable 5 at no extra cost," effective July 20, 2026.

So on a Max plan sitting at 30% weekly Fable usage on a current client, every documented precondition for plan-included access is satisfied, yet the CLI still routes to the credits purchase flow.

It happened to me and I just started a new chat and resumed the conversation that was interrupted using Fable 5 and it worked.

Another data point on 2.1.215 / macOS 26.5.2 (arm64, native installer), Max plan, saved model claude-fable-5[1m] — same as the OP.

claude.ai itself now contradicts the CLI in writing. The usage page shows this notice:

ⓘ Fable 5 is still included with your Max plan. If you see a prompt to set up usage credits for it, restart Claude Code.

…while Claude Code simultaneously offers:

Switch to Fable 5? Fable 5 runs on usage credits — you have $0.00 in credits.

Limits at that moment were nowhere near exhausted:

| Limit | Used |
|---|---|
| Current session | 15% |
| Weekly — All models | 8% |
| Weekly — Fable | 4% |

So the account-side state is fine and the client-side selection-time check is the thing that is wrong. That matches nratzan's analysis in #74051: in-flight Fable sessions keep running and keep drawing on the allowance at $0.00 credits, so the server accepts the entitlement — it is only the client's pre-flight check that demands a nonzero credit balance.

The prescribed restart did not fix it here either (same as #79351).

The part that costs real work: this does not only appear at selection time. It fired mid-session, during a long autonomous run, and silently swapped the model:

Switched to Opus 4.8 (1M context) for this session · Fable 5 requires usage credits · /model to change

Losing the selected model partway through a long task is a materially worse failure than a prompt at startup — and since the documented remedy is "restart Claude Code", the only sanctioned fix for a mid-session swap is to throw away the session. Whatever the root cause, it would help a lot if a failed or stale entitlement check did not silently change the model of a session already in flight.

For anyone hitting this now, the two workarounds reported in this cluster (/login re-auth per #79341, or starting a new chat and resuming per this thread) both point at a stale cached entitlement rather than a real billing state.

Restarting my session didn't help with this, so here's my current workaround:

1. Put your active CC session on remote control: /rc
2. Open the session in Claude Desktop
3. Swap the model to Fable 5 inside Claude Desktop
4. Restart the terminal session in Claude Code
5. Resume with claude --resume
6. Message the agent from Claude Desktop in the same session

No idea how durable this is. Treat it as a temporary at best.

Same issue, cant use my 100$ credit for fable.

See https://github.com/anthropics/claude-code/issues/79345#issuecomment-5026325503.

Same issue, Max plan, no org, v2.1.204, 47% Fable usage, VS Code extension

Same issue here, but with an additional data point: it only happens with CLAUDE_CODE_OAUTH_TOKEN.

I'm on a Max plan with plenty of Fable headroom. Setup:

Claude Code updated to the latest version
Token freshly regenerated via claude setup-token after the July 20 plan change, so it's not a stale-token issue
No ANTHROPIC_API_KEY set in the environment

Result:

Interactive login (/login via browser OAuth) → Fable 5 works fine, no credits prompt
Same account, authenticated via CLAUDE_CODE_OAUTH_TOKEN from claude setup-token → immediately get the "usage credits are required for this model" prompt, and restarting doesn't help

So this looks like the setup-token auth path isn't picking up the post-July-20 Max plan Fable entitlement, while the interactive OAuth path resolves it correctly. Hope this helps narrow it down.

Same issue here! Claude Code v2.1.216. Max 5x plan.
Claude code is showing this when selecting Fable model:
3. Fable Fable 5 · Most capable for your hardest and longest-running tasks · Requires usage
credits
So for some reason it is saying that it requires usage credits although I am on Max plan.

Same issue . But fable working on claude web and desktop app. The main issue is terminal side. The issue still persists

Same issue . But fable working on claude web and desktop app. The main issue is terminal side. The issue still persists

same

Adding a data point confirming this reproduces beyond the claude-fable-5[1m] saved-model path:

• Plan: Max, well under weekly usage limits (fresh, ~0% consumed)
• Claude Code: 2.1.216 (one build newer than the 2.1.215 in the report; claude update reports it as latest — no fix shipped yet)
• Config: clean — ~/.claude/settings.json has "model": "opus", no [1m] alias anywhere
• Repro: interactive /model → "Switch to Fable 5?" shows "Fable 5 runs on usage credits, purchased separately from your plan. You don't have usage credits yet." and offers only (1) set up credits or (2) keep current model. No path to use the Max-included Fable 5 entitlement.

So the entitlement mismatch isn't limited to the [1m] alias in settings.json — it also fires on a plain interactive switch with a clean config. Points at the Max Fable 5 entitlement (effective 2026-07-20) not being recognized at all, rather than purely an alias-resolution defect.

Facing the same issue, can't find a work around. I have updated, restarted, even asked opus to find me a solution but to no avail.

same issue

same

same issue

/logout and /login worked for me.

I'm on pro plan and it worked, have you guys check the allowed usage limit and set it > 0?

Hitting this exact issue on a Max (5x) plan, confirmed 2026-07-21. Selecting Fable 5 in Claude Code prompts that usage credits are required, even though Settings → Usage explicitly says "Fable 5 is still included with your Max plan" and tells you to restart Claude Code as the fix. Fully quit and relaunched (Cmd+Q) and the prompt still appears. Weekly Fable usage in that same panel showed 86% used (resets Thursday) — so this isn't a real limit block, it's the false-credits-prompt bug.

Seeing this too, on Max (default_claude_max_20x, Stripe subscription), Claude Code VS Code extension 2.1.216 on Windows 10.

Selecting Fable in the model picker silently reverts to the default model (Opus, then Sonnet) instead of running Fable — no visible error, just a downgrade. Confirmed via my own session transcript (~/.claude/projects/.../*.jsonl): every turn after selecting Fable was served by claude-opus-4-8 or claude-sonnet-5, never claude-fable-5.

This isn't a usage-limit issue — my 5-hour utilization was 3%, weekly was 0%, nowhere near the 50% Fable threshold on Max.

This may contradict the [1m]-literal-string theory above. I tested both model strings directly via the CLI (claude -p "hi" --model claude-fable-5 and claude -p "hi" --model "claude-fable-5[1m]"), and both succeeded — both resolved to claude-fable-5 in the response's modelUsage field, exit 0, no credits error. So the bare API/CLI path accepts Fable fine; the failure seems specific to the in-app picker/UI path.

Two things that look suspicious on my account:

hasExtraUsageEnabled: false, with cachedExtraUsageDisabledReason: "org_level_disabled"
The picker's cached model option (additionalModelOptionsCache in ~/.claude.json) has only one Fable entry, labeled "Requires usage credits" — looks like a stale pre-July-20 label that the picker may still be gating on client-side.
Tried pinning "model": "claude-fable-5" and "switchModelsOnFlag": false in ~/.claude/settings.json — didn't resolve it after a full restart.

I just got this email from Anthropic, but honestly I don't trust it.

Hi Michael,I can confirm that on your Max plan, Fable 5 is included as a standard part of your subscription—you can use up to 50% of your weekly usage limits on Fable 5 at no extra cost.[1] The false prompt you're seeing won't result in any actual charges to your account while Fable 5 remains within your plan's included usage.This specific issue—where Claude Code incorrectly shows the "Fable 5 is now consuming usage credits" banner for Max plan users—was addressed in version 174 of Claude Code (released June 12, 2026).[2] If you're still seeing the prompt after restarting, you may need to update to the latest version of Claude Code to resolve it.Regarding the GitHub issue you mentioned: we review all product bug reports, and reporting it here is all that's needed. There's currently no way to track the status of a specific fix, but you can check back later to see if the issue has been resolved. Reaching out multiple times about the same issue won't expedite a fix.Please let me know if this helps or if you have any further questions. | Hi Michael,I can confirm that on your Max plan, Fable 5 is included as a standard part of your subscription—you can use up to 50% of your weekly usage limits on Fable 5 at no extra cost.[1] The false prompt you're seeing won't result in any actual charges to your account while Fable 5 remains within your plan's included usage.This specific issue—where Claude Code incorrectly shows the "Fable 5 is now consuming usage credits" banner for Max plan users—was addressed in version 174 of Claude Code (released June 12, 2026).[2] If you're still seeing the prompt after restarting, you may need to update to the latest version of Claude Code to resolve it.Regarding the GitHub issue you mentioned: we review all product bug reports, and reporting it here is all that's needed. There's currently no way to track the status of a specific fix, but you can check back later to see if the issue has been resolved. Reaching out multiple times about the same issue won't expedite a fix.Please let me know if this helps or if you have any further questions.
-- | --
Hi Michael,I can confirm that on your Max plan, Fable 5 is included as a standard part of your subscription—you can use up to 50% of your weekly usage limits on Fable 5 at no extra cost.[1] The false prompt you're seeing won't result in any actual charges to your account while Fable 5 remains within your plan's included usage.This specific issue—where Claude Code incorrectly shows the "Fable 5 is now consuming usage credits" banner for Max plan users—was addressed in version 174 of Claude Code (released June 12, 2026).[2] If you're still seeing the prompt after restarting, you may need to update to the latest version of Claude Code to resolve it.Regarding the GitHub issue you mentioned: we review all product bug reports, and reporting it here is all that's needed. There's currently no way to track the status of a specific fix, but you can check back later to see if the issue has been resolved. Reaching out multiple times about the same issue won't expedite a fix.Please let me know if this helps or if you have any further questions.

Hi Michael,

I can confirm that on your Max plan, Fable 5 is included as a standard part of your subscription—you can use up to 50% of your weekly usage limits on Fable 5 at no extra cost.[[1]](https://support.claude.com/en/articles/15424964-claude-fable-5-on-your-plan) The false prompt you're seeing won't result in any actual charges to your account while Fable 5 remains within your plan's included usage.

This specific issue—where Claude Code incorrectly shows the "Fable 5 is now consuming usage credits" banner for Max plan users—was addressed in version 174 of Claude Code (released June 12, 2026).[[2]](https://code.claude.com/docs/en/changelog) If you're still seeing the prompt after restarting, you may need to update to the latest version of Claude Code to resolve it.

Regarding the GitHub issue you mentioned: we review all product bug reports, and reporting it here is all that's needed. There's currently no way to track the status of a specific fix, but you can check back later to see if the issue has been resolved. Reaching out multiple times about the same issue won't expedite a fix.

Please let me know if this helps or if you have any further questions.

/login to prompt the login screen and then authorizing to the same account helped resolve this exact issue for me.

/login to prompt the login screen and then authorizing to the same account helped resolve this exact issue for me.

that worked for me thank you so much

/login to prompt the login screen and then authorizing to the same account helped resolve this exact issue for me.

Guess what? Logging out and logging back in worked perfectly for me. Thank you for posting this obvious answer. Meanwhile Anthropic support still can't figure out the solution.

I'm having this issue too. And logged out and logged back in and that worked for one terminal, but then I opened up another terminal and it redirected me to usage credits once again. Claude Code in zsh Mac, 20x Max plan, 2.1.217

Same issue here, also on Max plan (5x), confirmed via Settings -> Usage: only 3% of Fable weekly limit used ("All models" at 16%), so nowhere near the 50% threshold. The Usage panel itself shows the banner "Fable 5 is still included in your Max plan. If you see a message to set up usage credits, restart Claude Code" - which confirms this is a known client-side bug, not an entitlement change.

Environment:

• Claude Code, VS Code integrated terminal
• Plan: Max, weekly limits not exhausted (Fable at 3%)

Restarting Claude Code did not consistently resolve it for me. Adding my report as another data point for the [1m] alias-resolution hypothesis above.

I was having the same issue as everybody else but running /logout and then running Claude again and reauthenticating fixed it for me.

Adding another confirmed data point, Max plan (5x), macOS, Claude Code 2.1.217, standard interactive OAuth login (no setup-token, no ANTHROPIC_API_KEY set).

Symptom persists across all of the following, in this order:

1. Full quit + relaunch (multiple times, across separate terminal windows)
2. /logout then re-login (full re-auth flow, not just restart)
3. Manually clearing additionalModelOptionsCache and modelAccessCache in ~/.claude.json — this did NOT cause a fresh correct refetch; it just removed Fable from the /model picker entirely. Restoring the original (stale) cache entry brought the option back, with the same "Requires usage credits" block as before.
4. Launching interactively with claude --model claude-fable-5 directly (not via the /model picker) — same block.

Key finding: the backend/API entitlement is fine. Running headless bypasses the bug entirely:

claude -p "hi" --model claude-fable-5 --output-format json

returns a real Fable 5 response — is_error: false, modelUsage.claude-fable-5.contextWindow: 1000000, billed normally, no credits error.

So this confirms the bug is isolated to the interactive code path (both the /model picker and interactive launch with --model flag), not a real entitlement/billing state, and not fixable by clearing local cache. Relevant local state on this account:

oauthAccount.hasExtraUsageEnabled: false
cachedExtraUsageDisabledReason: "out_of_credits"
organizationRateLimitTier: default_claude_max_5x

This lines up with the hypothesis a few comments up: the interactive path appears to gate Fable behind the extra-usage/overage-credits check (hasExtraUsageEnabled) instead of checking the plan-included Fable allowance, while the headless path (and the underlying API) correctly checks the real entitlement.

Also affected on Max, Windows.

• Claude Code 2.1.217 (also latest as of today)
• Windows 11 Pro for Workstations 10.0.26200
• Node v24.18.0
• Plan: Max, well under weekly usage limits
• No ANTHROPIC_MODEL / CLAUDE_MODEL overrides

Selecting Fable 5 via /model still reports "Fable 5 requires usage credits" and routes to the credits top-up page, despite being nowhere near the 50% weekly threshold that Max is supposed to include Fable under (per the Help Center article, effective 2026-07-20). Same symptom as the original report; still present on 2.1.217, so the fix has not shipped yet.

+1 for the alias-resolution hypothesis — the entitlement check appearing to run against the literal [1m] string rather than resolving to claude-fable-5 + a context flag matches what's described here and in #74562 / #67650.

For the subset of reports here authenticating via CLAUDE_CODE_OAUTH_TOKEN / claude setup-token (e.g. @Williamleejx above — "only happens with CLAUDE_CODE_OAUTH_TOKEN"), the root cause is now pinned down in #79597 — with earlier dupes #73350 (the first report, 07-02, naming hasAvailableSubscription: false) and #79360:

The setup-token's server profile never populates subscriptionType (~/.claude.json → oauthAccount carries no tier; profileFetchedAt refreshes each launch but the tier stays absent). The interactive entitlement check therefore can't confirm plan coverage and fail-closes to the credits wall. It isn't a stale token — a freshly minted one behaves identically. The tell: headless claude -p --model claude-fable-5 works fine (it skips the client-side gate and the server authorizes against the real plan), while the interactive picker walls it.

Workaround for that subset: unset the token so a /login credential drives — env -u CLAUDE_CODE_OAUTH_TOKEN claude. On always-on / multi-instance hosts where a plain default-dir /login would rotate refresh tokens between concurrent sessions, put the /login in an isolated CLAUDE_CONFIG_DIR instead (full setup + --output-format json verification in #79597).

Note this only accounts for the token-auth cases — the pure-/login reports in this thread (e.g. @xli21-code, clean config, no token) look like a separate variant of the same wall and aren't explained by the setup-token profile gap.

Adding a clean data point for the pure-/login variant @AndrewLuebke carved out as separate from the setup-token gap (#79597) — this reproduces the credits wall with no token involved at all, on Max 20x.

Auth: /login only. CLAUDE_CODE_OAUTH_TOKEN is not set at any scope — verified process, User, and Machine (Windows). No env block in settings.json, no shell-profile injection. claude setup-token is not in the picture, so env -u CLAUDE_CODE_OAUTH_TOKEN does nothing here.

Plan (from ~/.claude.json → oauthAccount):

• organizationRateLimitTier: "default_claude_max_20x" — i.e. Max 20x, which includes Fable 5
• organizationType: "claude_max", organizationRole: "admin" (personal one-person org)
• billingType: "stripe_subscription", hasExtraUsageEnabled: true
• seatTier: null
• subscriptionType: undefined ← the field the interactive gate checks

A friend on the same Max 20x plan uses Fable 5 with no wall, so this isn't tier-gating — it's the missing subscriptionType.

Behavior:

• Interactive /model picker → Fable 5 walls to the usage-credits prompt.
• claude --model claude-fable-5 (launch flag) → session starts, but the first interactive prompt hits the same wall. So the gate fires at message-send in the interactive TUI regardless of how the model was selected — not just in the picker.
• Headless claude -p --model claude-fable-5 "…" → works, exit 0, on-plan, no wall.
• profileFetchedAt refreshes on every launch (confirmed updating to the current day), but subscriptionType stays absent on each re-fetch — not stale data, and re-auth doesn't repopulate it.

Version: 2.1.217 on the native installer, and claude update reports "up to date" (latest on the native channel; npm latest is also 2.1.217). So updating the client is not a fix for this variant — I'm already on the newest build and it still walls. (Updating did fix it for others who were on older builds.)

Matches the tell exactly: the server authorizes Fable 5 against the real Max plan headlessly, while the interactive session fail-closes on the missing subscriptionType. Same server-side symptom as the token subset, reached without any token — which is why the setup-token workaround doesn't help this group. Fix likely needs the profile fetch to populate subscriptionType for claude_max accounts (including org-routed / personal-org ones) regardless of auth method.

Additional data point from a Max 20x account, v2.1.217 on Windows 11 (CLI in VS Code terminal + desktop app) — including proof the gate is wrong about where billing actually goes:

Local state fully ruled out. Plain "model": "claude-fable-5" pin (no [1m]), no ANTHROPIC_API_KEY in any scope (Process/User/Machine), no apiKeyHelper, credentials show subscriptionType: max with standard Claude Code scopes. A fresh /login on the correct account minted a new token and did not clear the prompt — so the flag survives token refresh.

The gate contradicts actual billing. With usage credits enabled ($80.58 balance), I clicked "Continue with Fable 5" and ran a session. Result: the credits balance stayed exactly $80.58 and the claude.ai Usage page shows Fable ticking against the plan's weekly limit (13%). So Fable is billing the Max subscription correctly — the "runs on usage credits" dialog and the "Fable 5 · Claude API" header are misreporting the billing path.

Escalation: disabling usage credits hard-blocks Fable. After turning the usage-credits toggle OFF on claude.ai, the CLI went from mislabeling to refusing: "Usage credits are turned off. Re-enable to use Fable 5" with only "Set up usage credits" / "Switch to Sonnet 5" offered. Meanwhile the desktop app's own Usage page shows the banner "Fable 5 is still included with your Max plan. If you see a prompt to set up usage credits for it, restart Claude Code" — restarting does not fix it.

Workaround for others: re-enable the usage-credits toggle and pick "Continue with Fable 5" — verified it bills the subscription, not credits, at least while under the plan limits.

I'm a max20 user and I only used it as an extension for vscode and experienced the same phenomenon, installed claude in powershell and resolved

I use Claude CLI with my Max ($200/mo) subscription. I noticed the issue ("Fable runs on usage credits" message) on one machine but not the other, so in my case it was an auth token issue (using MacOS/bash).

Fix that worked for me:

1. Logout of Claude Code CLI (incl. all sessions you might have running).
2. Unset the CLAUDE_CODE_OAUTH_TOKEN and verify it is no longer set in the environment: unset CLAUDE_CODE_OAUTH_TOKEN.
3. Start a new terminal session, very uauth token is still cleared in env, then login. Specify /model fable, it should no longer mention anything about credit.
4. Exit the other terminal sessions before trying to start additional Claude sessions in terminal.

I'm currently on: 2.1.218 (Claude Code).

Confirming the same symptom on a Max plan, well under weekly limits.

• /model → Fable 5 shows the generic "Fable 5 requires usage credits" prompt and routes to the credits top-up page instead of switching.
• /usage at the time showed Current week (Fable): 50% used — halfway through the weekly Fable allowance, not close to any cap.
• Saved default in ~/.claude/settings.json was "model": "claude-fable-5[1m]" (the 1M-context alias), matching the repro here. Removing the [1m] suffix (plain "claude-fable-5") did not resolve it — /model still shows the same generic credits prompt when actively selecting Fable, so the entitlement check on the live /model picker path appears independent of the saved default in settings.json (that setting only affects session startup, not the runtime check triggered by picking a model mid-session).

Environment: macOS, Claude Code (Max plan).

+1, reproducing today (2026-07-23) on Max plan, Claude Code v2.1.215 (macOS, ~/.local/bin/claude).

/model claude-fable-5 returns:

Switch to Fable 5? Fable 5 runs on usage credits, purchased separately from your plan. You don't have usage credits yet. 1. Set up usage credits on claude.ai 2. No, keep my current model

Data point: rotating the OAuth token (claude setup-token → fresh token → replaced CLAUDE_CODE_OAUTH_TOKEN) did not resolve it. Freshly minted token, same error immediately. So this doesn't appear to be stale client-side entitlement — the newly issued token is being served the same (incorrect) plan entitlement for Fable.

Same account, web usage page shows Fable covered by the plan.

Happy to attach ~/.claude.json entitlement snippet if useful — reply here.

Root-cause data point that may help others here, from debugging the same "Fable 5 requires usage credits" gate on a Max plan.

**The deciding factor is the credential source, not the token or its scopes** (verified on Claude Code 2.1.218):

• Authenticating via the CLAUDE_CODE_OAUTH_TOKEN environment variable puts Claude Code in "Claude API" mode — /status shows an Auth token: row and no Login method / Organization / Email. In this mode Fable 5 is credit-gated ("Fable 5 runs on usage credits — you have $0.00 in credits") even on a Max plan that covers it.
• The same token read from ~/.claude/.credentials.json (env var unset, i.e. a normal /login) yields /status: Login method: Claude Max account, and Fable 5 works as plan-covered.

It is not about scopes: exporting a full-scope token (user:file_upload, user:inference, user:mcp_servers, user:profile, user:sessions:claude_code, subscriptionType: max) through CLAUDE_CODE_OAUTH_TOKEN still produced "Claude API" mode and still credit-gated Fable. Only the credentials file yields subscription mode.

Practical takeaway: if you're hitting this, check whether CLAUDE_CODE_OAUTH_TOKEN (or ANTHROPIC_API_KEY) is set — CI / automation / devcontainer setups that export it will land in API mode and hit the Fable credit gate regardless of plan. Unsetting it so Claude Code reads the /login credentials file restores plan coverage.

I found a potential workaround, see: https://github.com/anthropics/claude-code/issues/79341#issuecomment-5065127466

I'm having the same problem since yesterday using Claude Code CLI.
/login sends me into a infinite login loop [receive email -> click login -> agree to permissions -> new email sent -> repeat]

I don't think anyone linked it here yet: https://github.com/anthropics/claude-code/issues/79360 talks about the CLAUDE_CODE_OAUTH_TOKEN issue @slalter mentioned.

Confirming this on the CLI — and it reproduces with a clean settings.json
(no claude-fable-5[1m] saved model).

Environment

• Plan: Claude Max (subscription auth, not API key)
• Claude Code: 2.1.220 (claude --version) — also the latest published on npm
• OS: Linux (WSL2)

Symptom. /model fable refuses to switch and silently stays on Opus 4.8:

Switch to Fable 5? Fable 5 runs on usage credits, purchased separately from your plan. You don't have usage credits yet. 1. Set up usage credits on claude.ai ❯ 2. No, keep my current model

Re-running just prints Kept model as Opus 4.8.

Why this is the entitlement-probe bug, not a real limit:

1. /usage shows a dedicated "Current week (Fable): 11% used" bar — the Max Fable

allowance is present and 89% free, nowhere near exhausted.

1. /usage also shows Fable already ran this week:

claude-fable-5: 112 input, 18.6k output, 535.9k cache read (~$2.78 notional).
So the account demonstrably HAS the Fable entitlement, yet the switch is refused.

1. Usage credits are OFF, and per the "Claude Fable 5 on your plan" help article

they should not be required — Max includes up to 50% of weekly limits on Fable at
no extra cost.

1. My ~/.claude/settings.json has "model": "claude-opus-4-8" — there is no

claude-fable-5[1m] saved model. So this reproduces without the [1m]
saved-model config from the original report, which points at the faulty [1m]
quota probe firing even on a plain /model fable switch (cf. #67650).

Net: a Max user with a live Fable entitlement and 89% weekly allowance remaining is
told they "need usage credits." Happy to attach full /usage / /status output.

I use Claude CLI with my Max ($200/mo) subscription. I noticed the issue (_"Fable runs on usage credits"_ message) on one machine but not the other, so in my case it was an auth token issue (using MacOS/bash). Fix that worked for me: 1. Logout of Claude Code CLI (incl. all sessions you might have running). 2. Unset the CLAUDE_CODE_OAUTH_TOKEN and verify it is no longer set in the environment: unset CLAUDE_CODE_OAUTH_TOKEN. 3. Start a new terminal session, very uauth token is still cleared in env, then login. Specify /model fable, it should no longer mention anything about credit. 4. Exit the other terminal sessions before trying to start additional Claude sessions in terminal. I'm currently on: 2.1.218 (Claude Code).

This was the issue for me thanks so much for sharing your solution! Slight difference at my end though, unset wasn't enough and I had to remove export CLAUDE_CODE_OAUTH_TOKEN="<string>" from my ~/.bashrc. My version was 2.1.220 and I'm on Kubuntu 24.04. It's interesting you are using bash on MacOS, this points to bash shell as the issue, likely the environment is not cleaning itself up.

Reproducing on a Max plan (20x tier). Fable is unavailable/gated in /model on a fresh Claude Code session; doing a full /logout + /login makes it available again for that session, but the very next new session reverts back to unavailable.

Debug log (~/.claude/debug/<session>.txt) for an affected session shows the session's OAuth token is missing the user:profile scope:

[Claude in Chrome] Disabled: OAuth token has no scope accepted by /api/oauth/validate (needs user:profile, user:office, or user:ccr_inference; env-var and setup-token sessions default to user:inference only)
[claudeai-mcp] Missing user:mcp_servers scope (scopes=user:inference)
[Bootstrap] Skipped: 403 for OAuth token without profile scope

Credentials are stored in the macOS Keychain via the normal interactive login flow (no ANTHROPIC_API_KEY env var, no setup-token in use), so this isn't a case of intentionally using a reduced-scope credential — something is narrowing the token down to user:inference-only between sessions. Bootstrap is what appears to fetch the profile/entitlements data used to resolve model availability, so a 403 there due to the missing scope lines up with the client falling back to a stale or incomplete entitlement snapshot that omits Fable.

This matches the pattern others in this thread reported (/login re-auth as a temporary fix, reverting on the next session) and points at scope handling during token refresh/session bootstrap as a likely root cause, separate from any real billing/entitlement state server-side.

Follow-up to my earlier comment here, for the token-auth subset (CLAUDE_CODE_OAUTH_TOKEN / claude setup-token): there's now a fix that keeps the token, so you don't have to drop it and /login — which isn't viable on headless / CI / multi-instance hosts. Credit to @vzellmeister's teardown in #79597. Declare your tier via env var alongside the token:

export CLAUDE_CODE_SUBSCRIPTION_TYPE=max
export CLAUDE_CODE_RATE_LIMIT_TIER=default_claude_max_20x   # or default_claude_max_5x — your tier

Fresh session → /model fable selects cleanly, and the header shows "Claude Max" instead of "Claude API". Confirmed on Max 20x / 2.1.220 (Linux). SUBSCRIPTION_TYPE=max is the lever (the picker checks subscriptionType === "max"); full mechanism + a tier-detection gotcha are in #79597.

Note this only helps the token-auth group — the pure-/login variant (e.g. org-routed Max accounts with subscriptionType undefined) still needs the server-side fix.

Follow-up to my earlier comment here, for the token-auth subset (CLAUDE_CODE_OAUTH_TOKEN / claude setup-token): there's now a fix that keeps the token, so you don't have to drop it and /login — which isn't viable on headless / CI / multi-instance hosts. Credit to @vzellmeister's teardown in #79597. Declare your tier via env var alongside the token: export CLAUDE_CODE_SUBSCRIPTION_TYPE=max export CLAUDE_CODE_RATE_LIMIT_TIER=default_claude_max_20x # or default_claude_max_5x — your tier Fresh session → /model fable selects cleanly, and the header shows "Claude Max" instead of "Claude API". Confirmed on Max 20x / 2.1.220 (Linux). SUBSCRIPTION_TYPE=max is the lever (the picker checks subscriptionType === "max"); full mechanism + a tier-detection gotcha are in #79597. Note this only helps the token-auth group — the pure-/login variant (e.g. org-routed Max accounts with subscriptionType undefined) still needs the server-side fix.

Thank you very much; this is the only solution so far that has resolved my problem.😆

Confirming this pattern on my end (Max plan, macOS, VS Code extension v2.1.220, model saved as claude-fable-5[1m]).

Interactive picker (VS Code panel):

• /model claude-fable-5[1m] → silently accepts ("Set model to claude-fable-5"), but the panel later blocks the actual request with the "Fable 5 requires usage credits — You don't have usage credits yet." paywall dialog, even though Usage settings shows Fable at only 3% of weekly allowance used and explicitly states "Fable 5 is still included with your Max plan."
• Switching to plain claude-fable-5 (no [1m]) via /model claude-fable-5 gives a different message instead: "Fable 5 uses usage credits and needs a one-time consent · pick Fable from /model in an interactive session to set it up."
• Following that instruction — running /model with no args and selecting Fable 5 from the picker — does not surface any consent dialog at all. No UI appears, nothing to accept, and the model still doesn't work.
• Multiple full VS Code restarts (not just Reload Window) did not clear any of the above.

Headless mode works fine, isolating this to the interactive/consent UI path specifically (same shape as #79597, but triggered without setup-token auth):

echo hi | claude -p --model claude-fable-5 --output-format json
→ {"modelUsage":["claude-fable-5"],"is_error":false,"result":"..."}

No error, correct model used. So the account-side Max entitlement is clearly fine — this is purely a client-side interactive/consent flow defect in the VS Code extension.

Happy to provide more logs/repro details if useful.

Same issue... tried a restart, removed 1M in json no luck. Help!

I was able to solve the issue.

Confirmed root cause + working workaround

Environment: Claude Code extension v2.1.220 (VSCodium, Remote-WSL / Ubuntu on Windows 11), signed in via claude.ai OAuth, Stripe subscription upgraded Pro → Max ($100/mo).

Symptom: After upgrading to Max, the extension's Account & Usage panel kept showing
"Plan: Claude pro" and selecting Fable 5 showed the "Fable 5 requires usage credits" banner.
claude.ai in the browser correctly showed Max. Restarting VSCodium and rebooting the machine
did NOT fix it.

Root cause (verified on disk): the stale plan is cached inside the stored OAuth
credential, not in the profile:

• ~/.claude.json → oauthAccount.organizationType: "claude_max" ✅ (profile refresh had

picked up the upgrade)

• ~/.claude/.credentials.json → subscriptionType: "pro" ❌ (token minted before the

upgrade; this is what gates the plan display and Fable)

Restarts can never fix this because every restart reuses the stored token — the stale
subscriptionType claim survives until a new token is minted. Note the entitlement field is
in .credentials.json, not in ~/.claude.json's oauthAccount block (no subscriptionType
key exists there in 2.1.220).

Workaround that fixed it:

1. Re-authenticate to mint a fresh token. Signing in again was sufficient — the VSCodium

extension has no explicit sign-out, and none was needed. (CLI /login, or moving
~/.claude/.credentials.json aside and reopening, should work the same way.)

1. Verify the new credential (prints no secrets):

grep -o '"subscriptionType":"[^"]*"' ~/.claude/.credentials.json → now "max".

1. Restart each Claude Code session — each claude process reads the credential once at

its own startup, so any session started before the re-auth keeps the stale claim in
memory. Sessions are independent: restarting one is enough to test; others can follow later.

After this, the panel reads correctly and Fable 5 requests go through on the Max plan.
A subsequent automatic token refresh also returned "max", so the server side is consistent —
the bug is that the client never re-mints/re-reads the token on plan change, and the
Account & Usage panel renders the token's stale claim.

Suggested fix: on plan/entitlement mismatch between the profile fetch
(organizationType) and the token claim (subscriptionType), force a token refresh (or
prompt re-auth) instead of trusting the stored token for the session's lifetime.

Corroborating on Linux, Max 20x, v2.1.220 — but with evidence pointing upstream of the [1m] alias theory.

TL;DR: the client renders my plan as "Claude Pro" despite the account being Max 20x. Pro is the credits-only tier for Fable, so every symptom in this issue follows from that single misclassification. Disabling 1M context does not fix it.

The entitlement is real — proven with credits disabled

Usage credits are turned off on this account (hasExtraUsageEnabled: false; the dialog itself says "Usage credits are turned off"). Yet headless Fable calls succeed and bill to the plan:

$ claude -p "say ok" --model fable --output-format json
result: 'ok'   modelUsage: ['claude-fable-5']   is_error: false

If Fable genuinely required credits and credits were disabled, that call had to fail. It doesn't. The entitlement is present; only the interactive client disagrees.

[1m] does not appear to be the cause

Verified by driving the real TUI in a pty and capturing the rendered picker (not by reading the config cache):

• CLAUDE_CODE_DISABLE_1M_CONTEXT=1 → picker still shows Requires usage credits
• ANTHROPIC_DEFAULT_FABLE_MODEL=claude-fable-5 → no change
• both together → no change

The tier label

Launching interactively with --model claude-fable-5, the model line reads:

Fable 5 with medium effort · Claude Pro · ...

Claude Pro is emitted by the binary itself (12 occurrences in the executable), not by my custom statusline script — that script only prints user@host:cwd | [model] [bar] %. There is no cached pro value anywhere in ~/.claude.json. The account is organizationType: claude_max, organizationRateLimitTier: default_claude_max_20x.

The cached option is not locally correctable

claude-fable-5[1m] appears zero times in the binary — it is server-supplied. Writing claude-fable-5 into additionalModelOptionsCache in ~/.claude.json is overwritten back to claude-fable-5[1m] on the next session start. Also of note: modelAccessCache comes back as [] and additionalModelCostsCache as {}.

Affected paths

| path | result |
|---|---|
| /model picker | blocked, credits dialog |
| /model claude-fable-5 (explicit base id) | blocked, falls back to Opus 5 |
| claude --model claude-fable-5, interactive | blocked |
| claude -p --model fable, headless | works, bills to plan |

The headless path being the only one that works is consistent with the gate being purely client-side UI — the API accepts Fable on this account without credits.

Env: Linux 7.0.0-28-generic, Claude Code 2.1.220 (native installer), Max 20x.

Confirming this is still present on 2.1.220 (current latest), Max plan, macOS.

Same symptom: selecting the Fable row in the /model picker shows the consent dialog "Fable 5 runs on usage credits, purchased separately from your plan. You don't have usage credits yet.", even though Fable is included on Max at up to 50% of limits. The only Fable row my picker offers has the value claude-fable-5[1m] (visible in additionalModelOptionsCache in ~/.claude.json).

I can confirm the alias-resolution hypothesis from the original report. Tested headless on the same account, same machine, minutes apart:

| Selection | Result |
| --- | --- |
| claude -p "..." --model claude-fable-5 | runs normally, no credits prompt |
| claude -p "..." --model fable | runs normally, no credits prompt |
| claude-fable-5[1m] via the /model picker | credits dialog, session does not start on Fable |

So the account entitlement is fine. Only the [1m]-suffixed id fails the entitlement check, which is consistent with the literal string being passed through instead of resolving to claude-fable-5 plus a 1M context flag.

Workaround for anyone hitting this: type /model fable instead of selecting Fable from the picker. Typing the alias makes Claude Code check availability with the server directly. Per the model-config docs, Fable 5 always runs with the 1M context window on the Anthropic API, so the [1m] suffix is redundant on this model and nothing is lost by avoiding that row.

One note on the 2.1.210 changelog entry, "Fixed the Fable model row showing 'Requires usage credits' for plans that include it, when a stale cache had baked the label in": that fix does not cover this case. My profile was fetched roughly two hours before the repro, modelAccessCache is empty, and additionalModelCostsCache is {}, so there is no stale label involved. The failure is at selection time, not a cached row label.

Workaround for anyone hitting this: type /model fable instead of selecting Fable from the picker.

This didn't work for me. Same version 2.1.220. I switched to Claude GUI Mac app and have no issues accessing Fable there.

Reproducing this on a premium Team seat, not Max, and with a data point that
rules out the [1m] alias-resolution hypothesis for at least some accounts.

Claude Code 2.1.220 (native install, installed 25 July 2026), Windows 11 Home
10.0.26200, VS Code integrated terminal, OAuth subscription auth, no
ANTHROPIC_API_KEY. Seat tier team_bendep_nonprofit_premium, organizationType
claude_team, organizationRateLimitTier default_raven, userRateLimitTier
default_claude_max_5x.

The gate fires on the canonical id, not just [1m]

My session transcript records the fallback as a system event:

{
  "type": "system",
  "subtype": "model_consent_fallback",
  "content": "Switched to Opus 5 (1M context) for this session · Fable 5 requires usage credits · /model to change",
  "level": "warning",
  "choice": "cancelled",
  "originalModel": "claude-fable-5",
  "fallbackModel": "claude-opus-5[1m]",
  "persistedAsDefault": false,
  "timestamp": "2026-08-02T16:07:05.357Z",
  "version": "2.1.220"
}

originalModel is claude-fable-5, with no [1m] suffix. I reached that state by
launching with claude --model claude-fable-5, which is the workaround suggested
earlier in this thread. So a fix scoped to resolving claude-fable-5[1m] to
claude-fable-5 plus a 1M flag would not fix this account.

This also matches @vhscom's report above that /model fable did not help on 2.1.220.

Model selection succeeds; the consent gate is what fails

Worth separating the two, because they behave differently:

• claude --model claude-fable-5 starts the session with the header

"Fable 5 with high effort · Claude Team", so selection itself resolved fine.

• The gate fires on the first prompt, before the turn runs, and dismissing it

does not leave the session on Fable. It falls back to Opus 5.

The server-side entitlement is intact

Headless mode never reaches the interactive consent gate, and there Fable works.
Same machine, same account, minutes apart from the failure above:

claude -p "Reply with exactly: OK" --model 'claude-fable-5[1m]' --output-format json

Runs normally, no dialog, no fallback. The returned modelUsage confirms Fable
actually served it, at the full 1M context window:

"claude-fable-5": {
  "inputTokens": 2, "outputTokens": 13,
  "cacheReadInputTokens": 21040, "cacheCreationInputTokens": 19161,
  "contextWindow": 1000000, "maxOutputTokens": 64000,
  "canonicalModel": "claude-fable-5", "provider": "firstParty"
}

Same result with --model claude-fable-5 and --model fable. Note that the
headless path accepts the [1m]-suffixed id too, which is further evidence that the
suffix is not what the gate is choking on.

Anthropic Support confirmed on 2 August 2026 that this seat tier does include Fable 5
up to 50% of weekly limits, that the server recognises the entitlement, and that the
fault is in the CLI's interactive consent gate. They directed me to file here.

Ruled out

The stale-OAuth-token cause from #79412 does not apply here.
~/.claude/.credentials.json has subscriptionType: "team" and
rateLimitTier: "default_claude_max_5x", matching organizationType: "claude_team"
in ~/.claude.json, so /logout + /login would not change the tier. Also tried:
updating to 2.1.220, full restart, fresh sessions in different projects. The gate
returns every time.

Possibly relevant client state

In ~/.claude.json the caches the gate would consult are empty, and the picker
offers only the [1m] variant with no plain Fable row:

"modelAccessCache": [],
"additionalModelCostsCache": {},
"additionalModelOptionsCache": [
  { "value": "claude-fable-5[1m]", "label": "Fable", "description": "Fable 5 - Most capable for your hardest and longest-running tasks" }
]

Cached feature flags that contradict the gate

Two more things from ~/.claude.json that look relevant, since the gate has to be
reading its credits-only decision from somewhere:

"tengu_saffron_credits_only_tiers": ["enterprise"],
"tengu_usage_overage_included_models": ["Fable", "Fable 5"],
"tengu-fable-off-switch": { "activated": false },
"tengu_velvet_mallet_fable_5": false,
"tengu_velvet_hammer_fable_5": false

My seat tier is not enterprise, so by the first flag this account should not be on
the credits-only path at all, yet it is. I do not know what the two
*_fable_5 booleans control, but if either is the plan-inclusion rollout gate, an
account that is entitled server-side while both flags are false client-side would
produce exactly this behaviour. Worth checking whether the flag rollout for Fable 5
inclusion reached premium Team seats, or only Max.

A second organization on the same login

This account has both a personal org and the Team org under one login. Both appear in
overageCreditGrantCache, timestamped eight minutes apart on 6 May 2026, the day a
personal Max subscription was cancelled and this seat was upgraded to the Team plan.

I do not think this is the direct cause, because the active session resolves to the
correct Team org, the OAuth token is minted with subscriptionType: "team", and the
headless test succeeds on that same token. But if the consent gate resolves the
billing context independently of oauthAccount.organizationUuid, a login carrying a
personal org alongside a Team membership is a plausible way to land on the wrong
entitlement, and it would explain why this reproduces for some premium Team seats and
not others. Cheap to rule out.

Scope note

This thread is titled for Max plans, and the related status incident
(tnypgb2jbqnq) was titled "Fable 5 requiring usage credits on Max plans" and
marked resolved on 20 July. It is still live on a premium Team seat on 2 August,
on a CLI version installed after that resolution date. If the July fix was scoped to
Max entitlements, Team premium may need to be handled separately.

I keep getting the error that Fable isn't included in my max plan on 2.1.220 (Claude Code) inside VSCode.

claude -p "Reply with exactly: OK" --model 'claude-fable-5[1m]' --output-format json
{"is_error":false,"duration_api_ms":5326,"num_turns":1,"stop_reason":"end_turn","session_id":"36cda797-6d4f-44d8-85de-4072719af3a8","total_cost_usd":0.132224,"usage":{"input_tokens":2,"cache_creation_input_tokens":6161,"cache_read_input_tokens":7353,"output_tokens":21,"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":6161,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":21,"cache_read_input_tokens":7353,"cache_creation_input_tokens":6161,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":6161},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":521,"outputTokens":12,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.000581,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty"},"claude-fable-5":{"inputTokens":2,"outputTokens":21,"cacheReadInputTokens":7353,"cacheCreationInputTokens":6161,"webSearchRequests":0,"costUSD":0.131643,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-fable-5","provider":"firstParty"}},"permission_denials":[],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"sdk_opt_in_required","subtype":"success","api_error_status":null,"result":"OK","ttft_ms":3252,"ttft_stream_ms":2217,"time_to_request_ms":18,"type":"result","duration_ms":3777,"uuid":"942e4ddd-c2a4-43b4-acbf-53690c1dc86a"}

Met this issue in cc cli after updating to the latest 2.1.220 version, I'm in the max plan.

Is this issue different from https://github.com/anthropics/claude-code/issues/79360? I was having this problem (Claude telling me I needed usage credits despite having a Max plan) but it was due to the setup-token issue from that issue. The fix in that issue worked for me. (Mostly just posting this on the off chance that this whole issue is a red-herring?)

@gigamonkey Partly, but not entirely — it's worth pulling the two apart, because treating this as a straight dup of #79360 will send the wrong fix to half the people here.

**The setup-token subset of this thread is #79360.** If you authenticate via CLAUDE_CODE_OAUTH_TOKEN / claude setup-token, the CLAUDE_CODE_SUBSCRIPTION_TYPE=max fix there resolves it (glad it worked for you — it's the clean path for that group).

But #79337 is broader than that. The reports from @Tevinhead (Linux, Max 20x) and @matanhakim (a Team seat, not Max) show the client misclassifying the plan as "Claude Pro" on plain /login, no token involved at all. Pro is the credits-only tier for Fable, so every symptom follows from that single misclassification — Tevinhead even proved it with usage credits disabled (hasExtraUsageEnabled: false), so it isn't a real entitlement problem. Same failing gate as #79360 (subscriptionType !== "max"), different cause for why it isn't populated: stale plan cache (see @thapar's Stripe Pro→Max upgrade), org-routing, Team seats, Google Play billing, etc.

**Crucially, the #79360 env-var fix does not help that group.** In the credential resolver, CLAUDE_CODE_SUBSCRIPTION_TYPE is only read when CLAUDE_CODE_OAUTH_TOKEN is set — it short-circuits on the token. Pure-/login users have no token env var, so the resolver reads subscriptionType from the credentials store instead, and the env var is simply inert for them.

So the taxonomy:

• Setup-token / env-token delivery → #79360's CLAUDE_CODE_SUBSCRIPTION_TYPE=max.
• Plan misclassified as Pro on /login (stale cache, org-routed, Team, Play billing) → env var won't help; /logout+/login refreshes it for some (re-walls on a second concurrent terminal), but the real fix is server-side.

Not a red-herring — just two failure modes funneling into one symptom. Both end at the same subscriptionType !== "max" gate, which is probably where a single upstream fix should land.

I hit this on Windows (CLI 2.1.221, Max 20x) — the credits dialog reappeared in every new terminal while my Mac on the same account never showed it — and traced the root cause. Sharing since it explains the July 20 start date and the flakiness across machines/restarts.

Root cause: stale server-side feature-flag evaluations

The consent dialog is gated on the GrowthBook flag tengu_saffron_lattice, fetched at session start via api.anthropic.com (/api/eval-authed/… — verified with a local proxy sniff; cdn.growthbook.io is never contacted).

The server returns inconsistent evaluations per request. Diffing ~/.claude.json → cachedGrowthBookFeatures after each session, the same account + same machine + same attributes got, minutes apart:

• stale: "tengu_saffron_lattice": {"enabled": true, "planLimitsEndDate": "2026-07-20T07:00:00Z"}
• fresh: "tengu_saffron_lattice": {"enabled": false}

The client treats planLimitsEndDate in the past as "promo over → Fable requires credits", so every session that draws the stale evaluation shows the dialog (or silently downgrades). That's why:

• it started exactly on 2026-07-20 (the baked-in end date passed);
• logout/login seems to fix it (next fetch often draws fresh) but it comes back;
• some machines "never" see it (they consistently draw fresh — likely a healthy edge/replica) while others see it constantly.

Not a client parsing bug per se — the client faithfully renders a two-week-old flag payload that the server should no longer be serving. Things that do not help, tested: clearing modelAccessCache/clientDataCacheSlots, rotating anonymousId, re-login (temporary), pinning "model": "claude-fable-5[1m]" (the mid-session dialog variant still fires on first message).

Workaround

DISABLE_GROWTHBOOK=1 (e.g. in settings.json → env) makes the flag reader fall back to built-in defaults, which evaluate to "no gate". Verified: interactive session starts on Fable 5 (1M), first message sends with no dialog. Side effect: all remote flags/experiments are frozen to defaults, so treat it as temporary until the server-side evaluations are fixed/purged.

@FZ1010 found the "why" behind the flakiness — worth surfacing, because it completes the picture.

Their analysis above traces the cross-machine / every-new-terminal variance to a stale server-side GrowthBook evaluation: the consent dialog is gated on tengu_saffron_lattice, fetched per session from api.anthropic.com, and the server returns inconsistent evals — {enabled: true, planLimitsEndDate: "2026-07-20"} (stale) vs {enabled: false} (fresh) minutes apart on the same account. The client reads a past planLimitsEndDate as "promo over → Fable needs credits," so any session that happens to draw the stale payload shows the wall. That explains the exact 2026-07-20 start date, why /logout+/login only temporarily helps (the next fetch often draws fresh), and why some machines "never" see it while others see it constantly.

Put together with the earlier findings, the gate behaves like an AND of two conditions:

wall = (tengu_saffron_lattice says promo-over) AND (subscriptionType ≠ "max")

which gives two independent client-side levers, each already A/B-verified in this cluster — clear either condition and the wall goes away:

1. Make subscriptionType = "max" — the CLAUDE_CODE_SUBSCRIPTION_TYPE=max fix (#79360). Clears the second condition. Works for setup-token auth, and for Team seats via the literal "max" (see @ripperhe's clean A/B on #79597).
2. DISABLE_GROWTHBOOK=1 (in settings.json → env) — @FZ1010's fix. Clears the first condition by falling back to built-in flag defaults. Works regardless of subscriptionType, so it's the lever for the pure-/login group whose plan is rendered as "Pro" (the cases I earlier flagged as needing a server-side fix — turns out there's a client-side stopgap after all). Caveat from @FZ1010: it freezes all remote flags/experiments to defaults, so treat it as temporary.

(The AND model is an inference from combining the two A/Bs — @ripperhe isolated lever 1, @FZ1010 isolated lever 2 — not something either stated outright, but both independently clearing the wall is exactly what an AND gate predicts.)

Net for anyone still stuck: setup-token / Team → lever 1; plain /login with the plan shown as "Pro" → lever 2. Both are stopgaps — the real fix is server-side: stop serving the two-week-stale tengu_saffron_lattice payload, and give the Fable entitlement check a proper server fallback (the same one /upgrade already uses).

So annoying this is still an issue and knowing Anthropic it was probably intentional for revenue-maxing. Just like how they disabled /queue while Codex and Hermes naturally have it.

For me it is working now

for Claude Code v2.1.222

Fixed in 2.1.222, and the fix is not in the changelog.

I hit this on a Max 20x plan and can confirm upgrading 2.1.221 → 2.1.222 resolves it. More usefully, I captured the entitlement state on both sides, which shows this was client-side, not an account or billing problem.

The evidence. ~/.claude.json holds the server-supplied entitlement. Every field is byte-identical before and after the fix:

| field | 2.1.221 (Fable refused) | 2.1.222 (Fable works) |
|---|---|---|
| additionalModelOptionsCache | [{value: "claude-fable-5[1m]", label: "Fable"}] | identical |
| modelAccessCache | [] | identical |
| additionalModelCostsCache | {} | identical |
| orgModelDefaultCache | null | identical |
| cachedExtraUsageDisabledReason | org_level_disabled | identical |
| oauthAccount.hasExtraUsageEnabled | false | identical |
| oauthAccount.profileFetchedAt | 2026-08-05T08:58:19Z | unchanged |

profileFetchedAt not moving is the important part: the client never re-consulted the server after the update. Same cached entitlement data in, different behavior out, only the binary changed. So the server was always sending a correct Max entitlement and 2.1.221 was misreading it.

This supports the alias-resolution hypothesis in this issue. Note the option string is still claude-fable-5[1m] after the fix. Only the code reading it changed.

Things that did NOT fix it, so others can skip them:

• Enabling usage credits. Not needed, and not the cause: cachedExtraUsageDisabledReason: org_level_disabled and hasExtraUsageEnabled: false are still set right now, with Fable working fine. Do not buy credits for this.
• claude auth logout + claude auth login. Forced a genuine profile refetch (profileFetchedAt advanced) and the entitlement came back identical, still gated.
• Selecting the unsuffixed id. /model claude-fable-5 on 2.1.221 hit the same credits prompt as claude-fable-5[1m].
• Restarting Claude Code, which is the remedy the July 20 status incident advised. Insufficient here.

Useful diagnostic while you are still on a broken build: run /usage. If it shows a plan-covered Fable meter (mine read Current week (Fable) 0% used) while /model says credits-only, the entitlement exists and the picker is misclassifying it. That is #79412 in one command.

If claude update fails for you too: on a slow or proxied link the built-in updater cannot finish the ~266 MB non-resumable download (socket hang up / stream has been aborted). Resumable path:

curl -s https://downloads.claude.ai/claude-code-releases/latest          # version
curl -s https://downloads.claude.ai/claude-code-releases/<VER>/manifest.json   # sha256 per platform
curl -L -C - --retry 20 --retry-delay 5 --retry-all-errors \
  -o claude-<VER>.exe \
  https://downloads.claude.ai/claude-code-releases/<VER>/win32-x64/claude.exe

Re-run the curl verbatim after any drop; -C - resumes. Verify sha256 against the manifest. On Windows you can then swap it in while Claude Code is running, since Windows allows renaming a running executable: Move-Item claude.exe claude-<old>.exe.bak then Move-Item claude-<VER>.exe claude.exe. Restart the session for it to take effect.

Adding a Linux / Max 20x data point confirming this was still firing on 2.1.221 as of today (2026-08-05), plus a recurrence record from session logs that corroborates the flaky server-side flag evaluation traced by @FZ1010.

Environment

• Claude Code CLI 2.1.221 (native install, Ubuntu Linux), auto-updated to 2.1.222 later today
• Plan: Max 20x (organizationRateLimitTier: default_claude_max_20x, organizationType: claude_max)
• Auth: interactive /login OAuth only — no CLAUDE_CODE_OAUTH_TOKEN, no ANTHROPIC_API_KEY, no apiKeyHelper (so not the setup-token subset from #79597/#79360)
• Usage credits disabled entirely at org level (hasExtraUsageEnabled: false, cachedExtraUsageDisabledReason: "org_level_disabled", spend.can_purchase_credits: false) — yet the dialog says "Set up usage credits on claude.ai"

Recurrence record (from ~/.claude/projects/*/*.jsonl): five out of five fresh CLI sessions between 2026-07-23 and 2026-08-05 fired this at session start:

type: system, subtype: model_consent_fallback,
content: "Switched to <Sonnet 5|Opus> — now your default model · Fable 5 requires usage credits",
originalModel: "claude-fable-5", persistedAsDefault: true

Today's instance: 2026-08-05T11:37:18Z on version: 2.1.221. Note persistedAsDefault: true — each occurrence silently overwrites the saved default model in ~/.claude/settings.json, so the downgrade sticks for future sessions even if the flag evaluation later comes back correct. This persistence is what makes the flaky-eval root cause so annoying in practice: one bad eval poisons the default until the user notices.

Fable weekly quota was at ~7% used when it fired — nowhere near the 50% Max threshold. Manual /model → Fable on 2.1.221 hit the hard "Switch to Fable 5? … You don't have usage credits yet" dialog with no proceed option.

Resolution + attribution caveat: /logout + /login cleared it (third time since July that re-auth was the fix on this machine). However, the binary auto-updated 2.1.221 → 2.1.222 in the same window, so I can't cleanly attribute today's recovery between the re-auth and the fix reported by @wenqifu / @vondrasoft above. Will report back if it recurs on 2.1.222.

Still reproducing on 2.1.223 — i.e. after the 2.1.222 fix — on Max 20x with plain OAuth. Adding it because this combination isn't yet in the thread, and because a passing headless call against a failing picker localises the defect more precisely than the reports so far.

The discriminator: headless works, picker doesn't

Same account, same binary, minutes apart.

--model flag via -p — succeeds:

$ claude -p "Reply with exactly: OK" --model 'claude-fable-5[1m]' --output-format json
{
  "is_error": false,
  "stop_reason": "end_turn",
  "result": "OK",
  "modelUsage": {
    "claude-fable-5": {
      "canonicalModel": "claude-fable-5",
      "contextWindow": 1000000,
      "maxOutputTokens": 64000,
      "provider": "firstParty",
      "inputTokens": 2, "outputTokens": 35,
      "cacheReadInputTokens": 15272, "cacheCreationInputTokens": 26272
    }
  },
  "api_error_status": null
}

Interactive /model in the same session — refused, with the usage-credits message and a downgrade to Opus.

So the account is entitled and the API serves Fable. The gate is client-side and specific to the interactive selection path.

This corroborates @lsmith77's 2026-08-03 result (headless claude -p --model 'claude-fable-5[1m]' returning is_error: false while the picker refused), and shows that split survived the 2.1.222 fix rather than being resolved by it.

Two incidental findings from the same output:

• canonicalModel: "claude-fable-5" with contextWindow: 1000000 — the [1m] suffix resolves cleanly to the canonical id, and Fable's 1M window is native rather than a separate SKU. That argues against the 1M-entitlement reading in the original post, at least on this account.
• The refusal is not a quota condition: the request was served on first attempt with no retry and no api_error_status.

Flag state is the fixed state, and it still fires

Per @FZ1010's tengu_saffron_lattice analysis, this is the healthy payload — no stale planLimitsEndDate anywhere in ~/.claude.json, and Max is absent from the credits-only tier list:

"tengu_saffron_lattice":            { "enabled": false },
"tengu_saffron_credits_only_tiers": ["enterprise"],
"tengu-fable-off-switch":           { "activated": false },
"tengu_velvet_hammer_fable_5":      false,
"tengu_velvet_mallet_fable_5":      false

"additionalModelOptionsCache": [
  { "value": "claude-fable-5[1m]", "label": "Fable",
    "description": "Fable 5 · Most capable for your hardest and longest-running tasks" }
],
"modelAccessCache":            [],
"additionalModelCostsCache":   {}

modelAccessCache: [] and additionalModelCostsCache: {} match the values @wenqifu recorded on both sides of the 2.1.222 fix, so they aren't the discriminator here either.

Profile was refetched at 10:54 local, ~5.5h after the 2.1.223 install at 05:19, so this is not a stale-cache session.

Entitlement

"organizationType":            "claude_max",
"organizationRateLimitTier":   "default_claude_max_20x",
"billingType":                 "stripe_subscription",
"organizationRole":            "admin",
"hasExtraUsageEnabled":        true,
"seatTier":                    null,
"userRateLimitTier":           null

Well under weekly limits; the failing session had just started.

Environment

• Claude Code 2.1.223 (native install, latest channel), installed 2026-08-06 05:19 local
• macOS 26.5.2, arm64, VS Code integrated terminal (TERM_PROGRAM=vscode)
• Node v22.14.0
• Auth: interactive /login OAuth only — no CLAUDE_CODE_OAUTH_TOKEN, no claude setup-token, no ANTHROPIC_API_KEY, no ANTHROPIC_AUTH_TOKEN, no ANTHROPIC_BASE_URL, no apiKeyHelper. So not the #79360 / #79597 subset.
• ~/.claude/settings.json: "model": "opus" — not claude-fable-5[1m]. The refusal happens on interactive selection, so the saved-model repro in the original post isn't required to trigger it.
• No project-level model setting; no managed-policy settings file present.

Why this may be worth separating from the resolved cases

The reports marked fixed by 2.1.222 (@wenqifu, @vondrasoft) and the stale-flag mechanism (@FZ1010) both explain a client that believes the plan lacks entitlement. Neither explains this: the flags say entitled, the version carries the fix, and the API demonstrably serves Fable to this account — yet the picker still refuses.

That points at the picker's own entitlement check reading a different source than the one the --model path consults, rather than at flag staleness. If it would help, I can capture the picker's decision inputs from a debug run — happy to run whatever instrumentation is useful.

This shit is pissing me off. I paid for 20x claude, and I cannot use Fable 5. It tells me to add credits to my balance. I'm on the 20x plan, and its supposed to be included.

Still reproducing on 2.1.224 — one version past @alex-greenbull's 2.1.223 report — and with an entitlement state that's the inverse of every data point in this thread so far, which I think narrows the defect usefully.

The new bit: out_of_credits, not org_level_disabled

Prior reports (@wenqifu, @bbszabi) all had usage credits disabled at org level and the flag off. Mine is the opposite and still fails:

| field | @wenqifu / @bbszabi | this report |
|---|---|---|
| oauthAccount.hasExtraUsageEnabled | false | true |
| cachedExtraUsageDisabledReason | org_level_disabled | out_of_credits |
| additionalModelOptionsCache | [{value: "claude-fable-5[1m]", label: "Fable"}] | identical |
| modelAccessCache | [] | identical |
| additionalModelCostsCache | {} | identical |
| orgModelDefaultCache | null | identical |
| organizationRateLimitTier | — | default_claude_max_20x |
| organizationType | — | claude_max |

Same symptom from opposite sides of the credits flag. That points at the picker gating on the credit balance itself rather than on hasExtraUsageEnabled — i.e. Fable is being routed through the extra-usage path unconditionally, instead of the plan-included path that Max is entitled to.

Weekly usage at the time: "Current week (Fable)" at 25%, session at 2%, all-models week at 16%. Nowhere near any limit.

Headless works, picker refuses — confirmed on 2.1.224

Corroborating @alex-greenbull's discriminator, one version later. Same account, same binary, minutes apart. Both aliases succeed:

$ claude -p "Reply with exactly: OK" --model 'claude-fable-5[1m]' --output-format json
is_error: False   result: OK   served: claude-fable-5 | contextWindow 1000000

$ claude -p "Reply with exactly: OK" --model 'claude-fable-5' --output-format json
is_error: False   result: OK   served: claude-fable-5 | contextWindow 1000000

Note the plain alias also resolves to a 1M context window, so the [1m] suffix isn't the discriminator here — which rules out the "1M is a separate entitlement" hypothesis raised in the original post, at least for this account.

Why this proves the refusal is spurious

The account is out of credits (cachedExtraUsageDisabledReason: "out_of_credits", zero balance). The two Fable calls above therefore cannot have been funded from credits. They must have drawn on the plan-included Fable allowance — the very allowance the picker claims doesn't exist when it says "Fable 5 requires usage credits".

So the server-side plan-included path is working correctly and the client is refusing to use it. Consistent with @wenqifu's finding that this is client-side, but from a different angle: not just identical entitlement fields across the fix, but a positive demonstration that the plan path serves requests while the picker is denying it.

Environment

• Claude Code 2.1.224
• macOS 26.5.2 (darwin 25.5.0, arm64), zsh
• Plan: Max 20x, OAuth via /login only — no ANTHROPIC_API_KEY, no CLAUDE_CODE_OAUTH_TOKEN, no apiKeyHelper
• ~/.claude/settings.json: "model": "claude-fable-5[1m]"
• Session start silently downgrades to Opus 5 (1M context); /model then reports "Kept model as Opus 5 (1M context)"

A tell worth noting: with the saved default at claude-fable-5[1m], the downgraded session's own context still described itself as Fable 5 while /usage attributed 100% of consumption to claude-opus-5. So the session is built against the requested model and then served by the fallback, which makes the downgrade easy to miss.

Suggested fix

Gate Fable on plan entitlement first, and only fall through to the credits path when the plan genuinely doesn't include it (Pro / Team Standard, per the Help Center article). On Max, an empty credit balance should be irrelevant to Fable selection while the weekly Fable allowance has headroom.

Still reproducible on v2.1.224 — Max 20x, CLI on WSL2 Ubuntu.

Today at 17:49 UTC, a new session with saved default model claude-fable-5 showed the "Fable 5 requires usage credits" consent prompt. I declined and the session fell back to Opus 5. The transcript recorded:

{"type":"system","subtype":"model_consent_fallback",
 "content":"Switched to Opus 5 (1M context) for this session · Fable 5 requires usage credits · /model to change",
 "level":"warning","choice":"cancelled",
 "originalModel":"claude-fable-5","fallbackModel":"claude-opus-5[1m]",
 "persistedAsDefault":false,"entrypoint":"cli",
 "timestamp":"2026-08-07T17:49:35.502Z","version":"2.1.224"}

A new session on the same machine 3 minutes later (17:52 UTC) started on claude-fable-5 with no prompt, running on plan limits. So the prompt came from stale entitlement state, not from the 50% weekly Fable cap. A real cap does not clear in 3 minutes.

Note: this happened on 2.1.224, so the 2.1.219 fix ("Fixed the Fable model row showing 'Requires usage credits' for plans that include it, when a stale cache had baked the label in") does not cover this path.

Correction to my comment above: the "Fixed in 2.1.222" claim was wrong. Please disregard it.

I upgraded 2.1.221 → 2.1.222, Fable worked, and I reported it fixed. It broke again the next day. The same "upgrade fixes it" pattern then repeated with 2.1.223 and also failed to hold. Full log, Max 20x, plain /login, Windows:

| when | client | Fable |
|---|---|---|
| Aug 5 | 2.1.221 | refused |
| Aug 5 | 2.1.222 (just swapped) | worked |
| Aug 6 | 2.1.222 | refused |
| Aug 6 | 2.1.223 (just swapped) | worked |
| Aug 8 | 2.1.223 | refused |
| Aug 8 | 2.1.223, nothing changed | worked again |

The last row is the one that matters: it recovered with no version change, no re-auth, and no entitlement change. oauthAccount.profileFetchedAt did not move and every entitlement field was byte-identical to the refusing state. So the version correlation in my earlier comment was coincidence. Each apparent "fix" was really just a restart, and a restart is what re-rolls the outcome.

That is what @FZ1010's tengu_saffron_lattice analysis predicts: the flag is evaluated per session and the server returns it inconsistently, so every new session is a fresh draw. It accounts for the intermittency, for why upgrading appears to work (you restart), for why re-auth works for some people, and for why it always comes back.

Constant across every refusal and every success on this account:

"cedar_lagoon":                 {"claude-fable": true, "claude-mythos": true}
"tengu-fable-off-switch":       {"activated": false}
"tengu_velvet_hammer_fable_5":  false
"tengu_velvet_mallet_fable_5":  false
"modelAccessCache":             []
"cachedExtraUsageDisabledReason": "org_level_disabled"
"hasExtraUsageEnabled":         false

The entitlement never wavered. Confirming @MarkNJennings and @alex-greenbull on the cap too: one refusal happened at 81% of the weekly Fable allowance and another at 0%, so consumption is not the discriminator either.

Things that did not durably fix it here: upgrading (three times), claude auth logout + login, selecting the unsuffixed claude-fable-5, and clearing modelAccessCache / clientDataCacheSlots / cachedGrowthBookFeatures. One warning on that last one: deleting additionalModelOptionsCache removes Fable from the /model picker entirely until the next profile fetch repopulates it, which made things worse rather than better.

Now running DISABLE_GROWTHBOOK=1 per @FZ1010. I will report back on whether it holds beyond a single day, which is the bar my earlier comment failed to clear.

Apologies to anyone who upgraded on the strength of that comment.

Confirming this on a similar setup — settings.json fix worked for me.

Environment:

Claude Code 2.1.225
Windows 11
Plan: Max 20x, weekly limits not exhausted

Symptom: Same as reported — session downgraded to Opus with "Fable 5 requires usage credits," despite being well under my weekly limit.

Fix: Changed "model": "claude-fable-5[1m]" to "model": "claude-fable-5" (dropped the [1m] suffix) in ~/.claude/settings.json, restarted the session, and Fable 5 loaded normally without the credits prompt.

This supports the alias-resolution hypothesis — the entitlement check seems to choke specifically on the literal [1m] suffix rather than resolving it to the base model + context flag. Would be great to get a fix (or at least a clearer error message pointing users toward this workaround) since it's not obvious that dropping [1m] restores standard access.

Can confirm, with a version bisection: works on 2.1.212, fails on 2.1.220 and 2.1.223 — same account, same day.

Setup: Max plan, weekly limits not exhausted (Fable usage well under 50%), macOS (darwin-arm64), npm install, "model": "claude-fable-5[1m]" in ~/.claude/settings.json. Reproduced across two machines on the same account.

On 2.1.220 and 2.1.223: exact symptom described in this issue — session silently switches to Opus 4.8 with "Fable 5 requires usage credits," and /model routes to the credits page.

On 2.1.212 (pinned via npm): claude-fable-5[1m] works with no credits prompt. /status shows Model: claude-fable-5[1m] (claude-fable-5), and /context reports the 1M window applied (231.7k/1m tokens). Note the model picker does not list a Fable 1M variant on either version — the string must be entered manually.

This brackets the regression to somewhere in 2.1.213–2.1.220. It also seems to weigh against the "1M is a separate entitlement" theory, since 2.1.212 serves Fable at 1M within Max inclusion against the same post-July-20 backend — consistent with the alias-resolution hypothesis in the OP (entitlement check running against the literal [1m] string in newer versions).

I am past 200K and still going:

/context
⎿ Context Usage
⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ Fable 5
⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ claude-fable-5
⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ 231.7k/1m tokens (23%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ Estimated usage by category
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ System prompt: 4.2k tokens (0.4%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ System tools: 16.2k tokens (1.6%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Memory files: 13.8k tokens (1.4%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Skills: 3.7k tokens (0.4%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Messages: 194.5k tokens (19.4%)
⛶ Free space: 767.5k (76.8%)

Same on Max x20, Claude Code 2.1.220, macOS 27.0.

Slightly different trigger than the OP, which may narrow it down: mine isn't a settings-pinned Fable model. My ~/.claude/settings.json has "model": "opus[1m]"; Fable 5 was selected in-session and running fine.

Sequence: run /login → browser auth completes → back in the terminal, the session is booted down to Opus with

Fable 5 now uses usage credits

Max x20 includes Fable 5 at 50% of weekly limits, and my live utilization at the time was 4% on the 5-hour window and 1% on the 7-day (read live, not from a cache), so "you don't have usage credits yet" is factually wrong for this account.

So the entitlement check appears to re-run on re-auth and fail there, even when Fable was never set in settings — which suggests whatever is broken sits in the post-login model-resolution path, not only in reading a claude-fable-5[1m] value out of config. If the alias-resolution hypothesis in the OP is right, note that my default is also a [1m] alias (opus[1m]), so a suffix-handling defect would be consistent with both reports.

Additional repro details: entitlement is lost specifically on the token refresh path (Windows only)

I can reproduce this consistently on Windows and have narrowed down the trigger. Fable 5 works fine immediately after a fresh login, but breaks after the OAuth access token expires during a long-idle session.

Environment

Claude Code 2.1.227 (terminal), Windows 11 Pro 10.0.26200
Claude Max (20x) subscription, OAuth login (no ANTHROPIC_API_KEY, no apiKeyHelper)
Same account works fine on macOS and Linux — this only happens on Windows
Timeline (local time, UTC+9)

Aug 10, 15:56 — Ran /logout → /login. Fresh token written to ~/.claude/.credentials.json (subscriptionType: max, rateLimitTier: default_claude_max_20x). Fable 5 immediately selectable and working.
Aug 10, 19:04 — Last successful claude-fable-5 response in the session (confirmed from the session transcript).
Aug 10, 23:56 — Access token expired (expiresAt was exactly 12h after issuance). Session left idle overnight, connection kept open.
Aug 11, 14:33 — Sent a new prompt in the same session. The prompt was logged in the transcript but no assistant message followed — instead the "usage credits required" gate appeared, before any API call was made.
Key observations

.credentials.json was never rewritten after the fresh login (mtime still Aug 10 15:56 when I inspected it on Aug 11). Whatever refresh happened on the first request after expiry either failed to persist, or produced a token that doesn't carry the Max/Fable entitlement.
Running /logout → /login again immediately restores Fable access, so the entitlement itself is fine on the account — it's only the refresh path that loses it.
Reproduces reliably: leave a session idle past the 12h token lifetime, then send any prompt.

Thanks for the unusually thorough report. Triaged on Linux against the released 2.1.233 build.

What I tried: dropped in your exact ~/.claude/settings.json ("model": "claude-fable-5[1m]", "switchModelsOnFlag": false) and started a session. It ran on Fable 5 at a 1M context window — no credits prompt, no downgrade. I couldn't match step 1 (a Max plan), so I can't drive the plan-entitlement path itself from here.

On the hypothesis: [1m] normalization for Fable was fixed back in 2.1.173, before your 2.1.215, and my run confirms the suffix resolves correctly. So alias resolution isn't what's failing here — the credits decision is made from your account's plan entitlement, not from the model string.

What does match your symptom are two fixes released after 2.1.215:

• 2.1.227 — fixed feature flags being evaluated without your subscription tier when a session started with an expired login token, which could wrongly prompt Max plan users to enable usage credits for Fable.
• 2.1.219 — fixed the Fable row showing "Requires usage credits" for plans that include it, when a stale cache had baked the label in.

Changelog — please update to 2.1.233 or later and sign out/in once so a fresh token is used.

On the label difference: Fable 5 includes 1M context by default, so it has no separate "(1M context)" variant to label, while Opus ships both. Closing — reply and we'll reopen if it still happens on 2.1.233+.

🤖 Generated with Claude Code

**Still reproducing on 2.1.237 — and it is specifically the in-session switch path, not Fable access itself.**

Max 5x, clean env, fresh login. On the same binary and the same account, within the same hour:

| Path | Result |
| --- | --- |
| claude --model claude-fable-5 (launch) | ✅ Fable 5 with high effort · Claude Max |
| /model fable (in-session switch) | ❌ Fable 5 runs on usage credits — you have $0.00 in credits |
| /model claude-fable-5 (in-session, explicit base id) | ❌ same dialog |
| claude -p --model fable (headless) | ✅ runs, bills to plan |
| claude -p --model 'claude-fable-5[1m]' (headless) | ✅ runs, bills to plan |

Launch-time and headless resolve the entitlement correctly on this account; only the in-session switch check fails. Interactive launch was verified by driving the real TUI in a pty, not inferred from config.

This also means the workaround given in #82722 ("typing /model claude-fable-5 manually works fine") does not hold on 2.1.237 — retested, still gated.

The server disagrees with the client at the same moment. GET /api/oauth/profile, using the client's own access token:

account.has_claude_max            = True
organization.organization_type    = claude_max
organization.rate_limit_tier      = default_claude_max_5x
organization.subscription_status  = active

~/.claude.json, written by the client right after its own profile fetch:

hasAvailableSubscription    = false
hasOpusPlanDefault          = false
modelAccessCache            = []
additionalModelCostsCache   = {}
additionalModelOptionsCache = [{"value":"claude-fable-5[1m]","label":"Fable", ...}]

Ruled out, so this is not a duplicate of the usual suspects:

• Not #83639 — env | grep -iE 'claude|anthropic' is clean. No CLAUDE_CODE_OAUTH_TOKEN, no ANTHROPIC_API_KEY, no apiKeyHelper, no env block in any settings.json.
• Not #76237 — the server returns has_claude_max: True for this exact token, so the account-side entitlement is present.
• Not a stale label cache — reproduced identically on 2.1.219 and on a clean 2.1.237 native install, across logout/login cycles. Upgrading did not flip hasAvailableSubscription, yet Fable runs anyway at launch — so that flag appears to be a red herring rather than the gate's input.
• Not exhausted limits — GET /api/oauth/usage: 5h 4%, weekly-all 9%, and a weekly_scoped bucket with scope.model.display_name = "Fable" at 0%.

Two observations from /api/oauth/usage that may be the actual lead:

1. That Fable bucket has scope.model.display_name = "Fable" but scope.model.id = null. If the switch-path check matches the target model id against the scoped-limit model id, a null id could never match and would fall through to "credits required" — which would explain why launch-time, which presumably doesn't run that comparison, succeeds. Speculative: I haven't seen the client code.
2. spend.can_purchase_credits = false on this account. So the dialog's only actionable option, "Manage usage credits on claude.ai", is a dead end here. Whatever the gate's cause, it is offering a remedy the account cannot perform.

Practical impact: on Max, changing models mid-session is impossible — the session has to be discarded and relaunched with --model claude-fable-5.

Env: macOS 26 (darwin 25.3.0, arm64), Claude Code 2.1.237 native install, Max 5x (default_claude_max_5x), OAuth login, no API key, no gateway.

Happy to provide account identifiers privately.