[BUG] /model picker does not offer Fable 5.1 to an account that is entitled to it (2.1.259, setup-token auth)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
The /model picker offers "Fable" = claude-fable-5[1m] only. Fable 5.1 is not listed, although the account is entitled to it:
claude --model claude-fable-5-1 -p "Reply with exactly: OK"succeeds, as does theclaude-fable-5-1[1m]variant./model claude-fable-5-1[1m]is accepted and reports "Set model toFable 5.1and saved as your default for new sessions".- The
fable-5-1-launchstartup announcement, which is gated onrequiresModel: claude-fable-5-1and says "Switch anytime with/model", has been shown five times on this install (announcementImpressions.fable-5-1-launch = 5in~/.claude.json).
So the model is usable; only the picker is wrong. ~/.claude.json has additionalModelOptionsCache with a single entry — {"value": "claude-fable-5[1m]", "label": "Fable", "description": "Fable 5 · Most capable for your hardest and longest-running tasks"} — and modelAccessCache: []. Other server caches on the install do refresh (cachedGrowthBookFeaturesAt was updated the same day), and restarting the CLI does not change the picker.
What Should Happen?
The /model picker lists Fable 5.1 for an account that is entitled to it, as the launch announcement promises.
Error Messages/Logs
# no error — the picker simply omits the entry
$ claude --version
2.1.259 (Claude Code)
$ claude --model claude-fable-5-1 -p "Reply with exactly: OK"
OK
$ claude --model 'claude-fable-5-1[1m]' -p "Reply with exactly: OK"
OK
Steps to Reproduce
- Authenticate on a Claude Max account with a long-lived token:
claude setup-tokenon a machine with a browser, then export it asCLAUDE_CODE_OAUTH_TOKENon the target host (no browser/loginthere). - Start
claudeand run/model— the list shows Fable (5) but no Fable 5.1. - In a shell:
claude --model claude-fable-5-1 -p "Reply with exactly: OK"— succeeds. - Back in the session:
/model claude-fable-5-1[1m]— accepted, "Set model toFable 5.1". - Inspect
~/.claude.json:additionalModelOptionsCachecontains only the Fable 5 entry;announcementImpressions.fable-5-1-launchis non-zero.
Claude Model
Other
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.259 (Claude Code)
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Other
Additional Information
- Native install (
~/.local/share/claude/versions/2.1.259), noANTHROPIC_MODEL, no managed settings, noDISABLE_*env vars. - Possible cause:
additionalModelOptionsCachelooks like a server-supplied per-account list that was never updated with the 5.1 entry, or its refresh is skipped under token-env auth. I could not tell which from the client side. - I tried to send this through
/feedbackfirst. Under setup-token auth it fails with "Couldn't send feedback (server returned 403). The draft is still queued. Try again later." — consistent with long-lived tokens being inference-only, in which case "try again later" is misleading.
3 Comments
Still reproduces on 2.1.260
This is so annoying... can't believe not more people reporting this.
Just like fallback to 4.8 instead of 5.
I reproduced the headless/interactive discrepancy on Claude Code 2.1.276 with OAuth-token authentication.
Observed:
claude auth status --jsonreportsloggedIn: true,authMethod: oauth_token, andapiProvider: firstParty.claude --model claude-fable-5-1 -p "Reply with exactly: OK" --output-format jsonsucceeds.modelUsagecontainsclaude-fable-5-1withcanonicalModel: "claude-fable-5-1",provider: "firstParty", and a 1,000,000-token context window.claude-haiku-4-5-20251001; no Opus model is recorded.subscriptionType: nullandmodelAccessCache: [].--bareis not usable for this OAuth-token test because it skips OAuth and keychain reads; without--bare, Fable 5.1 is actually reached.This appears to confirm that Fable 5.1 is available to the inference path while the interactive entitlement/model-picker path remains inconsistent. Could you clarify whether the additional Haiku usage is expected internal processing, and whether the interactive entitlement gate is a known issue?