[BUG] /model picker does not offer Fable 5.1 to an account that is entitled to it (2.1.259, setup-token auth)

Status Open
Reported on v2.1.259
Maintainer reply None cached
Activity 3 comments · opened Sep 3, 2026

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 the claude-fable-5-1[1m] variant.
  • /model claude-fable-5-1[1m] is accepted and reports "Set model to Fable 5.1 and saved as your default for new sessions".
  • The fable-5-1-launch startup announcement, which is gated on requiresModel: claude-fable-5-1 and says "Switch anytime with /model", has been shown five times on this install (announcementImpressions.fable-5-1-launch = 5 in ~/.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

  1. Authenticate on a Claude Max account with a long-lived token: claude setup-token on a machine with a browser, then export it as CLAUDE_CODE_OAUTH_TOKEN on the target host (no browser /login there).
  2. Start claude and run /model — the list shows Fable (5) but no Fable 5.1.
  3. In a shell: claude --model claude-fable-5-1 -p "Reply with exactly: OK" — succeeds.
  4. Back in the session: /model claude-fable-5-1[1m] — accepted, "Set model to Fable 5.1".
  5. Inspect ~/.claude.json: additionalModelOptionsCache contains only the Fable 5 entry; announcementImpressions.fable-5-1-launch is 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), no ANTHROPIC_MODEL, no managed settings, no DISABLE_* env vars.
  • Possible cause: additionalModelOptionsCache looks 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 /feedback first. 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.

View original on GitHub ↗

3 Comments

tbvl · 1 month ago

Still reproduces on 2.1.260

adriangalilea · 1 month ago

This is so annoying... can't believe not more people reporting this.

Just like fallback to 4.8 instead of 5.

bumbuboon · 27 days ago

I reproduced the headless/interactive discrepancy on Claude Code 2.1.276 with OAuth-token authentication.

Observed:

  • claude auth status --json reports loggedIn: true, authMethod: oauth_token, and apiProvider: firstParty.
  • Running claude --model claude-fable-5-1 -p "Reply with exactly: OK" --output-format json succeeds.
  • modelUsage contains claude-fable-5-1 with canonicalModel: "claude-fable-5-1", provider: "firstParty", and a 1,000,000-token context window.
  • The same invocation also records claude-haiku-4-5-20251001; no Opus model is recorded.
  • The local configuration has subscriptionType: null and modelAccessCache: [].
  • --bare is 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?