Default model in settings.json ("claude-fable-5[1m]") is not honored at session start; /model does not reliably switch either

Corroborating with a second variant, plus what looks like the root cause and a regeneration loop. CC 2.1.220, macOS.

Same config value, different silent landing model. With "model": "claude-fable-5[1m]" in ~/.claude/settings.json, every interactive session launched as claude-opus-5 — verified from the "model" field in ~30 session transcript .jsonl files (transcripts, not flags, are the reliable check). The only surface that reveals it is the /model banner fine print: "settings.json pins Opus 5 (1M context)". So the same value lands on Sonnet 5 for you and Opus 5 (1M) for us — presumably whatever the resolver falls back to.

The value itself appears to be the root cause: claude-fable-5 is natively 1M context (the maximum is the default), so a [1m] variant of Fable doesn't exist — the suffixed id is invalid and gets silently resolved to a different model family instead of being rejected.

The value regenerates: after we deleted the key, a later /model "save as default" rewrote claude-fable-5[1m] into settings.json — the picker itself writes the invalid id, so users may never have hand-typed it, and manual correction doesn't stick. Setting the bare id "claude-fable-5" behaves correctly.

Expected: persist/resolve the bare claude-fable-5, reject the [1m] form for models with no such variant, or warn at session start when the configured string resolves to a different model family.

Feedback ID (submitted via /bug): ec1d3551-326c-4156-83c6-34f953b225f4

Follow-up with new evidence: the invalid [1m] value is written on normal /model use - no save-as-default step required.

After my previous comment I reset the key to a bare claude-fable-5 and avoided save-as-default entirely. The next day it rewrote itself twice anyway (CC 2.1.220, macOS - times below are file mtimes on ~/.claude/settings.json, local):

• start of day - "model": "claude-fable-5" (manually set, clean)
• 11:24 - became "model": "opus[1m]" - after switching the running session to Opus via /model
• 13:35 - became "model": "claude-fable-5[1m]" - no save chosen; the only /model interaction around then was checking which model the session was on

So the picker persists a <family>[1m] id as a side effect of selection/interaction, not just through the explicit save-as-default flow. I can't pin the exact UI action that triggers the write - there was no deliberate save either time. Two consequences:

1. The regeneration loop from my last comment is worse than reported - manually correcting the key doesn't hold, because ordinary /model use re-poisons it.
2. It writes the suffixed form for any family (opus[1m] too). The silent-mismatch case is still claude-fable-5[1m]: Fable is natively 1M, the suffix isn't a valid variant there, and the loader lands on Opus 5 (1M) while everything except the /model fine print still says Fable.

Ground truth that made this diagnosable: the per-request "model" field in the session transcript JSONL - e.g. one of yesterday's sessions logged claude-opus-5 on 352 of 352 requests while settings claimed Fable. Suggest the fix cover selection-persistence too, not just save-as-default: either don't persist on selection, or validate before writing (reject [1m] where no such variant exists).

Reporter here. New evidence that changes the diagnosis in my original post: the silent
fallback also happens on a path that never touches settings.json and never involves the
[1m] suffix. So there appear to be two distinct defects in this thread, and for my
account the [1m] invalid-id explanation (@DelanoJoey's, which reproduces cleanly on his
machine) is not what keeps Fable from running.

Environment: CC 2.1.220, Windows 11, Max 5x. Entitlement present.

Repro that isolates it from config

Spawn a subagent with an explicit model override, from a session running Opus 5:

Task(subagent_type: "general-purpose", model: "fable", prompt: "reply with one word")

Then read the ground truth — the per-request "model" field in that subagent's transcript
(~/.claude/projects/**/agent-<id>.jsonl), same method @DelanoJoey used:

agent-<id-A>.jsonl  ->  {'claude-sonnet-5': 1}

Requested Fable. Served Sonnet 5. No error, no warning, no notice anywhere in the UI.

This path reads no model key from settings.json and constructs no [1m] id.

Control (the part that makes the above diagnostic)

The obvious alternative reading is "the model override is simply ignored for subagents,
and general-purpose just runs Sonnet 5 by default". Ran the identical spawn with the
override removed, same session, same agent type:

agent-<id-B>.jsonl  ->  {'claude-opus-5': 1}

With no override the subagent inherits the parent session's model (Opus 5). So
general-purpose does not default to Sonnet 5, and the override is not being dropped — if
it were, the Fable spawn would have landed on Opus 5 too. The Fable spawn landed on a model
that is neither the one requested nor the one inherited, which leaves one reading: the
request is routed as Fable, refused, and silently substituted.

Side benefit: this is a ~2-second, config-free check for "is Fable serving yet?" that
doesn't require restarting a session or editing settings.json.

Scope on this account

Counting message.model across all 499 transcripts on this machine (at time of writing):

| model | messages |
|---|---|
| claude-sonnet-5 | 18,305 |
| claude-opus-4-8 | 15,572 |
| claude-opus-5 | 14,976 |
| claude-fable-5 | 0 |

Fable has never served a single message here, by any route.

Client-side state is fully permissive (so this isn't entitlement or a kill switch)

From ~/.claude.json, cachedGrowthBookFeaturesAt = today:

• clientDataCacheSlots[*].data.cedar_lagoon.claude-fable: true
• tengu-fable-off-switch: {"activated": false}
• tengu_usage_overage_included_models: ["Fable", "Fable 5"]
• additionalModelOptionsCache[0]: {value: "claude-fable-5[1m]", label: "Fable"}

A diagnostic trap worth fixing on its own

lastShownEmergencyTip still reads:

Claude Fable 5 is currently unavailable. Please use Opus 4.8 or another available model.

It is a last-shown record with no timestamp, so it persists indefinitely and reads as
current state. Mine dates from the June 12–30 export-control window; those controls were
lifted at the end of June, and the string is still there weeks later. It sent my own
diagnosis down the wrong path twice — once by making a stale condition look current, and
once by making a genuinely current condition look like it was already explained. Either
clear it when the condition clears, or timestamp it.

Asks, in priority order

1. Do not declare a model in the session context that is not the model serving. This is

the one that caused real damage: a full day of multi-agent work in my case was produced
under Sonnet 5 while every surface — including the assistant's own system context — said
Fable 5, so nothing in the session could flag it. A silent fallback is recoverable; a
silent fallback plus a false identity is not.

1. Make the fallback visible. Either fail the request with "Fable 5 is unavailable" or

emit a one-line notice naming the model actually used. Right now the only way to find out
is to parse transcript JSONL after the fact.

1. Fix the [1m] persistence/validation issue as described in the comments above — it is a

real second defect even though it is not what blocks Fable here.

Happy to supply the raw transcript excerpts or re-run the probe on request.

Ran your probe on my setup - opposite result, which helps scope defect #2.

Environment: macOS 26.5.2, CC 2.1.220 (same build as yours). Same account as my comments above.

Probe:

Task(subagent_type: "general-purpose", model: "fable", prompt: "reply with one word")

agent-a093c6b49d91a3ba7.jsonl  ->  {'claude-fable-5': 2}    (every model field in the agent transcript)

Caveat on the control side: my parent session was already on Fable 5 (10/10 assistant messages in the parent transcript are claude-fable-5), so unlike your A/B pair this spawn can't distinguish "override honored" from "override dropped and inherited". For the serving question it's decisive either way: a request routed to Fable was served claude-fable-5. A wider sweep of this machine's transcripts shows claude-fable-5 as the served model across sessions and subagents on Jul 30, Jul 31, and Aug 1.

Same client build, opposite serving outcome. That points at server-side per-account gating for your defect #2, not client code - consistent with your GrowthBook flags being permissive; the client isn't the layer making the call.

Defect #1 fired end-to-end here today, in one exchange. /model -> Fable 5, "saved as your default for new sessions". That save wrote

"model": "claude-fable-5[1m]"

back into settings.json (the save path re-adds the suffix, same as my comments above). The same dialog then printed:

.claude/settings.json pins Opus 5 (1M context) — that applies on restart

So with the file literally reading fable-5[1m], the product's own banner describes the pin as Opus 5 (1M). The UI displays the pin post-resolution. Save Fable, file says fable with the suffix, banner says it pins Opus, restart serves Opus. I reset the file to bare "claude-fable-5", which behaves.

Your stale-tip find reproduces here. My ~/.claude.json carries the identical lastShownEmergencyTip string, dating from the same June window. +1 to clearing it when the condition clears, or timestamping it.

One note for anyone grepping transcripts for the served model: tool_use inputs are structural JSON in the parent transcript, so the spawn's own model: "fable" argument matches unescaped greps. Filter to assistant entries (message.model is the response's model, i.e. what actually served) or read the subagent transcript like you did.

Your asks 1 and 2 would have caught both defects on both machines.

That's the control I couldn't run on my own machine — thank you for running it, and for flagging the limitation of your own probe before anyone had to ask. That kind of caveat is exactly what makes the rest of your data easy to trust.

Same build, same probe, opposite serving outcome is about as clean a scoping result as this thread could get: whatever is deciding is not in the client. Your reading looks right to me.

One more data point that separates defect #2 from defect #1 on my account

Since my last comment my settings.json has read a bare, valid "model": "claude-opus-5" — no [1m] suffix, and no Fable string anywhere in my config. Fable still never serves. So on this machine the two are now cleanly independent: there is no invalid id left for the loader to resolve wrongly, and the fallback behaves exactly as it did before. Your [1m] persistence finding stands entirely on its own — my case just isn't downstream of it.

Refreshed count (same method you used: message.model on assistant entries)

All transcripts on this machine, re-counted today:

| model | messages | last served |
|---|---|---|
| claude-sonnet-5 | 18,305 | 2026-08-01 |
| claude-opus-4-8 | 15,572 | 2026-07-24 |
| claude-opus-5 | 15,367 | today |
| claude-fable-5 | 0 | never |

501 transcripts. Opus 5 served me ~40 minutes before writing this, so the account is serving normally — just never Fable, by any route: session default, /model, or subagent override.

Your grep caveat deserves to be the headline for anyone auditing this

I'd put it even more strongly than you did, because it's the crux of the whole diagnosis: in the parent transcript, a spawn's own model: "fable" argument is structural JSON inside the tool_use input, so a plain search for fable matches the request, not the response. Only message.model on type: "assistant" entries records what actually served. Someone checking the obvious way would conclude Fable was working fine.

Why asks 1 and 2 still stand, even if the gating is server-side

If the decision is made per account on the server, the client still doesn't have to describe it incorrectly: the response that comes back carries the model that produced it. The mismatch is observable at the moment it happens, client-side, with no server change required — my own session context said Fable 5 while every response in that transcript said Sonnet 5.

So the part that actually caused damage isn't gated on whatever is doing the gating:

1. Don't declare a model in the session context that isn't the one serving. A silent fallback is recoverable; a silent fallback plus a confident wrong identity is not — nothing inside the session can flag it, which is how a full day of work here was produced under a model I didn't choose.
2. Make the substitution visible — either fail the request, or emit one line naming the model actually used.

Between the two machines in this thread, those two would have caught both defects on both platforms, without either of us having to parse JSONL after the fact. Thanks again for the cross-check — it turned two separate anecdotes into something with a shape.

Also submitted through /bug, so this thread and the internal pipeline are linked for whoever triages it:

Feedback ID b1db0568-4a6f-41ac-82bd-fb91e4fdddde — Windows 11, CC 2.1.220, Max 5x.

Same substance as my comments here: the subagent probe with its control (override honored → inherits Opus 5; override set to fable → served Sonnet 5), the 501-transcript count with claude-fable-5 at zero, and the scoping against @DelanoJoey's opposite outcome on the same build.

Both affected accounts in this thread now have an internal feedback ID attached — @DelanoJoey's is ec1d3551-326c-4156-83c6-34f953b225f4 (macOS, served Fable) and mine is the one above (Windows, never served Fable). Same client version on both, which should make the two IDs useful as a matched pair rather than two separate reports.