[BUG] Fable 5 blocked with 'usage credits' prompt on Team Premium seat; modelAccessCache stays empty after fresh login

Status Open

Reported on v2.1.218

Maintainer reply None cached

Activity 4 comments · opened Jul 24, 2026

What's Wrong?

Claude Code blocks Fable 5 with the usage-credits dialog on a Team Premium seat, even though Fable 5 has been a standard part of Team Premium plans since 2026-07-20 (per Help Center article 15424964, up to 50% of weekly usage limits at no extra cost).

Selecting the model shows:

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

Meanwhile, Fable 5 works normally in the Claude desktop app on the same account at the same time — no credits prompt. So the entitlement exists server-side; Claude Code fails to resolve it.

This looks like the Team-plan counterpart of #79337 / #79441 (both Max). A Team Premium repro suggests the defect is in plan-entitlement resolution generally (possibly seat-type resolution for Team plans), not Max-specific.

Environment

Claude Code 2.1.218, macOS
Auth method: Claude AI (Team plan, Premium seat)
Started occurring with the 2026-07-20 promo-to-plan transition

Steps to Reproduce

Be on a Team plan with a Premium seat (Fable 5 included per plan since 2026-07-20)
Start a fresh Claude Code session
Run /model claude-fable-5 (or select Fable via the /model menu)
Credits dialog appears; Fable cannot be selected

What I've Ruled Out

[1m] alias hypothesis (#79337): settings.json originally had "model": "claude-fable-5[1m]". Changed to plain claude-fable-5 — no effect. Suffix resolution is not (the only) root cause.
Stale login/entitlements: /logout + /login — no effect.
Stale session state: fresh sessions (no --resume/--continue) — no effect.
Version: updated to 2.1.218 — no effect.
Plan limits: account nowhere near weekly limits.

Diagnostic Detail

modelAccessCache in ~/.claude.json is [] and remains empty even after a fresh /logout + /login. The entitlement fetch appears to return nothing for this seat type (rather than the cache merely being stale), after which the client falls back to the credits gate.

~/.claude.json also still contains stale Fable-era state, e.g. lastShownEmergencyTip: "Claude Fable 5 is currently unavailable..." from the June availability window.

Expected Behavior

On a Team Premium seat below the 50% Fable threshold, /model claude-fable-5 should switch to Fable 5 with no credits prompt — matching claude.ai and the desktop app on the same account.

#79337 (Max: credits prompt from 2026-07-20)
#79441 (Max, VS Code extension: blocked with allowance remaining; stale entitlement data)
#74051 (CLI ignores promotional allowance)

View original on GitHub ↗

4 Comments

wolframst · 1 month ago

Additional data point: the downgrade is silent to the model too, not just the user

In a fresh Claude Code CLI session on this same Team Premium seat, the assistant's own system prompt asserted: "You are powered by the model named Fable 5. The exact model ID is claude-fable-5." I asked it to critically verify that claim rather than take it at face value.

Checking the session transcript directly (~/.claude/projects/<project>/<session-id>.jsonl) shows every one of 22 assistant turns, from the very first, logged as:

"model": "claude-sonnet-5"

Not one turn is claude-fable-5. This isn't a mid-session downgrade — the session ran on Sonnet 5 from turn one, while the injected system prompt simultaneously told the model it was Fable 5.

~/.claude.json has both of these present at the same time:

"model": "claude-fable-5"   // configured/preferred model
"model": "claude-sonnet-5"  // apparently the resolved runtime model for this session

Hypothesis: the "which model are you" text injected into the system prompt is built from the configured/preferred model field, not from the model actually resolved for the session's API calls. That would explain why the model can't self-report the downgrade even when directly asked to verify it — its own context asserts the wrong thing, and there's no user-facing signal inside the conversation itself (only the CLI's status line shows the true model).

Session ID: a2b0d5af-0227-43e2-aba5-600f0dd01541, Claude Code 2.1.218, same account/environment as the original report.

COOLak · 1 month ago

Adding a related public signal from the manual/prepaid credits side: this Team Premium report looks like the same cross-system owner boundary as the Max-plan Fable reports, but with seat-type resolution in the mix. A plan-included model is routed toward usage-credit setup while another Claude surface recognizes the entitlement.

Public, non-sensitive reference for the billing-credit side of the pattern: https://coolak.github.io/anthropic-claude-billing-incident/

Specific reconciliation matrix: https://coolak.github.io/anthropic-claude-billing-incident/reconciliation-matrix.html

I am intentionally omitting private payment details, support-thread bodies, invoice/receipt identifiers, and account-specific IDs here. The useful escalation path is for Billing Platform / payment operations plus model-entitlement owners to inspect the whole route together: plan entitlement -> Team seat type -> modelAccessCache / entitlement fetch -> Claude Code account binding -> runtime billing-mode decision -> spend/extra-usage controls -> purchase/commit state -> credit-ledger provisioning.

j0-Da · 13 days ago

Its only happening if i set the the ENV Var CLAUDE_CODE_OAUTH_TOKEN. As soon as i remove it and login in my session i can use the fable models.

If i set the same Token in the ENV Var its asking for usage tokens again.

MattMinerQuotable · 13 days ago

Same thing on a Team Premium seat. @j0-Da has it — the trigger is CLAUDE_CODE_OAUTH_TOKEN.

I had it exported in ~/.zshenv, so every session inherited it, and Fable refused with "requires usage credits." Same machine, same account: env -u CLAUDE_CODE_OAUTH_TOKEN claude and Fable works instantly, no login prompt. The on-disk creds were valid all along, just unused while the var was set. Deleted the line, fixed for good.

2.1.233 (so after the 2.1.219 and 2.1.227 fixes from #79337), macOS, zsh. seatTier: team_tier_1, userRateLimitTier: default_claude_max_5x. modelAccessCache is [], same as OP. This account has run Fable in this CLI before, so the entitlement is there.

Warning for anyone else debugging this: I also had cachedExtraUsageDisabledReason: "org_level_disabled" and hasExtraUsageEnabled: false. Both true, both about spillover credits, neither has anything to do with the in-plan Fable allowance — but sitting next to a credits_required 429 they look like a real billing block. Cost me hours. Re-logging in and refetching the profile returns the same values, so that's a dead end too.

The message is also just wrong. "Fable 5 requires usage credits" for what's actually a failed entitlement lookup sends people to a billing page. If you're the org owner, it sends you straight at enabling pay-as-you-go you don't need.