[BUG] --model claude-fable-5 / claude-fable-5-1 silently served claude-opus-5

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?

This is a re-file of #74691, which reported this exact behavior and was closed as completed on 2026-08-25. It still reproduces on 2.1.259, so I am reporting it as a recurrence rather than as new. (#85971, #85438 and #83481 are open and describe Fable being inaccessible or failing unclearly; they may share a root cause with this.)

Requesting Fable with --model returns a response attributed to Opus instead. Both claude-fable-5 and claude-fable-5-1 behave this way. The request exits 0 and prints a normal answer, and no warning is emitted.

The only surfaces I found that record which model actually ran are modelUsage in the --output-format json envelope, and .message.model in the session transcript. Neither appears during normal interactive use, so in ordinary usage there is nothing to notice.

I am describing the observable fact. That the request was routed to Opus is my inference from modelUsage; I cannot see the routing itself.

What Should Happen?

Either of these would resolve it:

1. Serve the model that was requested, or
2. Fail with an explicit error, for example "model not available for this account".

The absence of any human-visible signal is the part that matters. A long-running session can proceed on a model the user did not select, and nothing in normal output indicates it.

Error Messages/Logs

# There is no error. The full modelUsage object from the request below:
$ claude -p "Reply with only: OK" --model claude-fable-5-1 --output-format json

{
  "modelUsage": {
    "claude-opus-5": {
      "inputTokens": 2,
      "outputTokens": 5,
      "cacheReadInputTokens": 20018,
      "cacheCreationInputTokens": 224295,
      "webSearchRequests": 0,
      "costUSD": 1.41198775,
      "contextWindow": 1000000,
      "maxOutputTokens": 64000,
      "thinkingTokens": 0,
      "canonicalModel": "claude-opus-5",
      "provider": "firstParty",
      "costBasis": "list"
    }
  }
}

Steps to Reproduce

1. Run a request naming a Fable model explicitly, with a deliberately neutral prompt so that prompt content is a less likely explanation:

``
claude -p "Reply with only: OK" --model claude-fable-5-1 --output-format json
``

1. Inspect the whole modelUsage object in the returned envelope.
2. It reports claude-opus-5, and only that model is billed. The requested model does not appear. The command exits 0 and prints a normal answer.
3. Repeat step 1 for each model below and observe which are honored. Each was run once, in the same window, from the same machine and install:

| Requested | Reported in modelUsage |
|---|---|
| claude-fable-5 | claude-opus-5 (not the requested model) |
| claude-fable-5-1 | claude-opus-5 (not the requested model) |
| claude-opus-5 | claude-opus-5 (honored) |
| claude-sonnet-5 | claude-sonnet-5 (honored) |
| claude-haiku-4-5-20251001 | claude-haiku-4-5-20251001 (honored) |
| (no --model flag) | claude-opus-5 (honored) |

The three comparison models I tested were each honored. Only the two Fable identifiers were not.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Claude Code Version

2.1.259 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

On the regression field. I left "Last Working Version" blank deliberately. I have a recorded measurement from 2026-07-25, on 2.1.220, of a request for claude-fable-5 being served claude-fable-5. That is the most recent version for which I have such a record, but I have not bisected the intervening releases, and claude-fable-5-1 did not exist then, so it speaks only to claude-fable-5. Model routing appears to be server side, so a client version number may be the wrong axis entirely: I cannot distinguish a client regression from a dated server-side change, and I would rather not send anyone hunting through client diffs on my say-so.

On entitlement. I reproduced this on multiple accounts from the same machine, with the same result each time. That rules out state specific to a single account. It does not rule out a plan-level entitlement gate, since those accounts may share a plan class, and #85971 reports precisely that for Pro Max users. I mention it because it is a live alternative explanation, not because I have excluded it.

On prompt content. #74691 discusses a content flag as a possible trigger. For triage, that explanation does not fit this reproduction: the prompt is the literal string "Reply with only: OK", and the comparison models are honored on that same prompt. I would not claim content filtering is impossible, only that prompt content is a less likely explanation here.

Version note. npm latest is 2.1.259, which is what I am on. npm stable is 2.1.236.