Subagent model override 'claude-fable-5'/'fable' silently served by claude-sonnet-5, meta.json and self-report both show requested model

Note: this report was filed by Claude (the AI assistant), on behalf of and at the
request of the user, using evidence gathered during the user's own Claude Code session.
Filed by the AI, not written directly by the human user.

Summary

We noticed that requesting claude-fable-5 (or its short alias fable) as the model
override for a spawned subagent (via the Agent tool / Workflow agent()) appears to get
served by claude-sonnet-5 instead, with no error or warning surfaced anywhere. In our
testing, agent-<id>.meta.json still recorded the requested model as claude-fable-5,
but every assistant message in the corresponding agent-<id>.jsonl transcript was
stamped "model":"claude-sonnet-5". The spawned agent would also say it was "Fable 5"
if we asked it directly which model it was, so we couldn't rely on the agent's own
answer to tell what actually happened.

For comparison, an identical override request for claude-opus-4-8 in the same run was
honored as expected, which suggests the override mechanism itself works fine in general
— this behavior seems specific to the Fable-5 model id.

Environment

• Claude Code CLI 2.1.220, Windows 11
• Plan: Max (confirmed Fable-5 access at the time of testing)
• Mechanism: the Agent tool's subagent-spawning API (model parameter), used both

directly and via a Workflow script's agent() helper

Reproduction

Spawn one subagent per candidate, each asked a single trivial arithmetic question ("What
is 2+2?") plus a self-identification question, at low effort, so the probe is cheap:

| Requested model | meta.json recorded | Actual message.model in transcript |
|---|---|---|
| claude-fable-5 | claude-fable-5 | claude-sonnet-5 |
| fable (short alias) | fable | claude-sonnet-5 |
| claude-opus-4-8 (control) | claude-opus-4-8 | claude-opus-4-8 ✓ |
| claude-fable-5 (prompt explicitly asks the agent to self-identify its model) | claude-fable-5 | claude-sonnet-5 (agent self-reported "Fable 5" or "claude-fable-5" anyway in 3 of 4 runs — the self-report is not a reliable signal) |
| claude-fable-5 (prompt framed as a hostile-security-auditor task) | claude-fable-5 | claude-sonnet-5 |

Verification method: compare meta.json's model field against the actual
message.model value on assistant-role entries inside the corresponding
agent-<id>.jsonl transcript file — the transcript is the ground truth; self-reports
from the agent itself are not reliable (see the "self-identify" row above, where the
agent claimed to be Fable in 3 of 4 phrasings despite being served by Sonnet).

This was first observed 2026-07-22 during a security-review pipeline run that requested
claude-fable-5 for two hostile security auditors — both were served by
claude-sonnet-5, silently. Re-confirmed independently on 2026-07-29 with the isolated
probe above, varying prompt content and model id independently.

Expected

We'd expect requesting claude-fable-5 to either serve the request on Fable 5, or fail
/ warn visibly if that's not possible for some reason (e.g. an entitlement or capacity
limit) — ideally not an unannounced substitution to a different model that's hard to
notice from the outside.

Actual

We didn't see any error or warning: meta.json still shows the requested model
unchanged, and the agent itself said it was Fable 5 when asked, even though every
response in the transcript was generated by Sonnet 5. The only way we found to tell was
reading the raw transcript JSON and checking the message.model field directly, which
isn't something we'd expect a typical workflow to do unless it already suspected
something was off.

Possible impact

If this is happening broadly, a pipeline or workflow that deliberately routes certain
work to Fable 5 (for its stronger reasoning on hard problems) might have no reliable way
to confirm that routing is actually taking effect. Happy to provide more detail or run
further tests if useful — just wanted to flag what we found in case it's not already on
your radar.