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

[sruby]

Description
Running /model in Claude Code CLI and attempting to switch to Fable 5 fails with the message:

"You don't have usage credits yet. Set up usage credits on claude.ai to use this model."

However, /usage in the same session shows a "Current week (Fable)" quota bar at 0% used (i.e., the subscription includes a weekly Fable allotment that has not been consumed). This suggests the model is entitled to be used via subscription quota, not a separate pay-as-you-go usage-credits pool.

Additionally, Fable 5 is usable from claude.ai (web) and the Claude desktop app under the same account, with no usage-credits prompt.

Steps to reproduce

1. Have an active Claude subscription with a weekly Fable 5 quota (confirm via /usage → "Current week (Fable)" shows 0% used, i.e. available).
2. In Claude Code CLI, run /model and select Fable 5.
3. Observe the CLI blocks the switch, claiming no usage credits, and links to claude.ai/settings/usage to purchase credits.
4. Compare: the same account can use Fable 5 in claude.ai web / desktop app without issue.

Expected behavior
Claude Code CLI should recognize and use the subscription's included weekly Fable 5 quota (as shown in /usage), consistent with web/desktop behavior, rather than requiring a separately purchased usage-credits balance.

Actual behavior
CLI refuses to switch to Fable 5, citing missing usage credits, even though the account's weekly Fable quota is unused (0%).

Environment

• Claude Code CLI
• OS: Windows 11
• Model attempting to switch to: Fable 5 (from Sonnet 5)

[COOLak]

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.

[pgm095]

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.