C:/Program Files/Git/model fails to switch to Fable 5 with "no usage credits" despite weekly Fable quota showing 0% used

Adding a related billing/entitlement-routing signal from a separate unresolved Claude billing case, kept public-safe.

This issue is a clean example of the same reconciliation boundary: the account-visible quota says Fable 5 is included and unused, web/desktop can use Fable 5, but Claude Code routes the CLI model switch to a separate usage-credit purchase path.

That matters for the related billing case because Anthropic's manual prepaid / discounted usage-credit purchase path fails or fails at confirmation, while automatic reload billing can still charge from saved payment methods. If Claude Code incorrectly asks a paid subscriber to buy usage credits for included Fable quota, the customer may be pushed into a purchase path that is itself failing or unreconciled.

The shared failure class is not "user needs to buy credits." It is a mismatch between plan entitlement, model-access gating, usage-credit pool state, payment-method state, support-visible account state, and billing-ledger state.

Actionable owner request: please have Anthropic correlate /usage Fable quota, web/desktop model entitlement, Claude Code model picker/session routing, separate usage-credit pool state, credit-purchase prompts, payment events, and support routing before sending paid users to generic credit-purchase or billing-support loops.

Sanitized public incident packet for the related cluster:
https://coolak.github.io/anthropic-claude-billing-incident/

Reconciliation matrix / owner map:
https://coolak.github.io/anthropic-claude-billing-incident/reconciliation-matrix.html

I am intentionally not posting card details, bank names, private payment IDs, exact balances from someone else's account, raw logs, screenshots, support-thread bodies, token values, or private identifiers here.

Same symptom here on Max, with a couple of data points I haven't seen posted yet — in particular, one that rules out the [1m] alias explanation proposed in #79337.

Env: Claude Code 2.1.220, Linux, native install, claude_max / default_claude_max_5x, org admin (personal single-seat org).

The gate is interactive-only

Headless works. Interactive does not, on the same account, same binary, same minute.

Running claude -p --model claude-fable-5 '...' succeeds. The client-written model field on every assistant message in the resulting transcripts is claude-fable-5, and there is no model_consent_fallback event anywhere in them. Seven consecutive runs, all clean. So the entitlement genuinely resolves and the request is served on plan.

In the TUI, the session starts on Fable, and the fallback fires when the first message is sent:

{"type": "system", "subtype": "model_consent_fallback",
 "content": "Switched to Sonnet 5 for this session · Fable 5 requires usage credits · /model to change",
 "level": "warning", "choice": "cancelled",
 "originalModel": "claude-fable-5",
 "fallbackModel": "claude-sonnet-5",
 "persistedAsDefault": false,
 "entrypoint": "cli", "version": "2.1.220"}

originalModel has no [1m] suffix

#79337 attributes this to the entitlement check running against the literal claude-fable-5[1m] instead of resolving it to claude-fable-5 plus a separate context flag. That can't be the whole story: above, originalModel is the clean claude-fable-5 and it still routes to the credits path.

Worth noting the picker only ever offers the [1m] variant — additionalModelOptionsCache in ~/.claude.json contains exactly one Fable entry, {"value": "claude-fable-5[1m]", "label": "Fable"} — so users who reach this via /model will naturally report the suffixed string. Setting "model": "claude-fable-5" in settings.json to sidestep that reproduces the failure anyway.

Quota is not the trigger

From the same session's utilization payload:

• session (5h): 0%
• weekly_all: 21%
• weekly_scoped, scope.model.display_name = "Fable": 5%, is_active: false, severity: normal

That third entry is the plan's own Fable allowance, and it's nearly untouched. Meanwhile:

• spend.enabled: false, spend.can_purchase_credits: false, spend.can_toggle: false
• extra_usage.is_enabled: false, credits_ever_enabled: false
• cachedExtraUsageDisabledReason: "org_level_disabled"

Which is consistent with the consent gate keying off extra-usage/credits state rather than the plan's Fable allowance. Per the Help Center, Max includes Fable up to 50% of weekly limits at no extra cost, and the weekly_scoped counter above shows the backend already accounts for it that way — it's the interactive client that disagrees.

No client-side escape

For anyone landing here looking for a workaround: there isn't one for interactive sessions. There's no setting or env var that suppresses the consent prompt (CLAUDE_CODE_NO_MODEL_FALLBACK does the opposite — it errors instead of substituting). Headless -p and the web/desktop apps are the only paths that currently work.

The awkward part of the fallback is that it's silent about the downgrade's cost: a user who pins Fable ends up on Sonnet 5, which may be below the model they'd have gotten by leaving the default alone. Falling back to the configured default rather than a fixed tier, or surfacing the plan's Fable allowance in the prompt instead of a credits pitch, would both be improvements independent of the entitlement fix.

Still reproduces on 2.1.246 (macOS, Team plan with a Premium seat — so Fable 5 should be included at 50% of weekly limits, no usage credits required).

Symptom: selecting Fable 5 via /model always shows:

Switch to Fable 5? Fable 5 runs on usage credits, purchased separately from your plan. You don't have usage credits yet. 1. Request usage credits from your admin

Evidence the entitlement itself is fine — only the picker's check is wrong:

• Same account runs Fable 5 without issue in claude.ai and the Claude Code desktop app.
• Headless CLI works on the same machine/login:

claude -p 'Reply ok.' --model claude-fable-5 --output-format json
returns is_error: false and modelUsage shows claude-fable-5 actually served the request.

• Pinning "model": "claude-fable-5" in ~/.claude/settings.json also works — interactive sessions launch and run on Fable 5.

So the model is served and billed correctly through every path except the /model switcher, which appears to check only the prepaid usage-credit pool and never the subscription-included Fable 5 quota.

Side effect worth flagging: the dialog's "Request usage credits from your admin" flow is actively misleading on Premium seats — in our org it resulted in the admin performing a seat upgrade ("more Claude usage"), which of course changed nothing.

Ruled out locally: no managed-settings.json, no ANTHROPIC_API_KEY set, fresh sessions after restart, claude update (already current).