[Feature Request] Configurable target model and effort for the Fable 5 classifier fallback

This FR is exactly what is needed. As the only current workaround (which not really desirable), is to deactivate Fable 5 fall back to Opus in Claude Code. Which basically obliges the user to intervene, disrupting loops, goals, or any time sensitive work that could have completed while sleeping. Otherwise, we get the fallback to a lesser model, same level: the alteration of going from Fable / Low to Opus / Low or Fable / Medium to Opus / Medium is a catastrophy. The underlying issue is addressed might be much more dumber than a very carefull Opus working at xhigh or max. It might disrupt completely the work. I'm not sure how the usage (reloading the entire context is quantified). Most of the time, switching back, I had to ask Fable to double check if Opus didn't make any huge mistake. Which most of the time retriggers the classifier as Fable ended on eventually on the same line of code that triggered it. Not usage wise recommended! Eventually a compaction helped. But the loss of context does really help to keep the accuracy/consistency and the model on the top of things? One thing I didn't look into, is to see if we can have a hook on the top of the model change. But I would not recommend or play with this, as it could be seen as an attempt to change the classifier / harness fable 5 intented restriction by Anthropic. So it is up to Antropic and Mythos to give us a clean configurable fall back, full handled nativelly by the harness (aka Claude Code).

+1 with a specific extension: multi-model fallback chains and allowed_fallback_models expansion

This FR is exactly right, and I want to push it one step further: a single configurable fallback target is not enough — I want a chain.

What I want to configure

Fable 5 → Opus 5 → Opus 4.7

When Fable 5's classifier fires, fall back to Opus 5. If Opus 5's classifier also fires, fall back to Opus 4.7. When Opus 5 is the primary model and its classifier fires, fall back to Opus 4.7 directly.

The API's fallbacks parameter (beta, server-side-fallback-2026-07-01) already supports ordered lists of up to 3 models, and it does not look at the refusal category — it tries them in order. So the mechanism for a chain already exists at the API level. What's missing is a way to set it from Claude Code.

Why a chain, not a single target

I specifically do not want Opus 4.8 as a fallback target. It has well-documented quality regressions (#67855, #68780, #69628, #64961, #79726) — including tool-use loop failures and fabrication of tool outputs that make sessions unrecoverable mid-task. Opus 4.7 does not have these problems, and it's only one generation older. I'd rather fall through to 4.7 than land on 4.8.

But right now I can't, for two reasons:

1. Claude Code exposes no fallbacks configuration. The classifierFallbackModel setting proposed in this issue would help, but if it's a single model, I can't express "try Opus 5 first, then 4.7."

1. The API's allowed_fallback_models does not include 4.7 as a permitted target for Opus 5. I verified this against the Models API:

claude-fable-5  → allowed_fallback_models: ["claude-opus-4-8", "claude-opus-5"]
claude-opus-5    → allowed_fallback_models: ["claude-opus-4-8"]   ← 4.7 is missing
claude-opus-4-7  → allowed_fallback_models: []

So even if Claude Code exposed fallbacks, an Opus 5 user could only choose 4.8 — the one model I don't want. Fable 5 users get a slightly better deal (4.8 or 5), but can't reach 4.7 either.

Observed behavior (Claude Code v2.1.220, TUI)

I tested all four combinations of {Fable 5, Opus 5} × {biology, cybersecurity} classifier triggers in TUI with availableModels including 4.8:

| Model | Category | Fallback target | Final response |
|---|---|---|---|
| Fable 5 | biology | Opus 4.8 | API refusal |
| Opus 5 | biology | (no fallback) | safeguards refusal |
| Fable 5 | cybersecurity | Opus 4.8 | prose refusal |
| Opus 5 | cybersecurity | Opus 4.8 | prose refusal |

Every fallback that fired landed on Opus 4.8. There was no Fable 5 → Opus 5 path. The allowed_fallback_models data is consistent with this — Opus 5 is a permitted target for Fable 5, but the default routing didn't use it.

Notable: Opus 4.8 did not show a safeguards message — it refused at the API level or in prose, not via the classifier flag. So the model that receives all the fallback traffic is the one that doesn't surface a safeguards response, and the one with documented quality regressions.

What I'm asking for

1. Extend this FR to support ordered chains, not just a single classifierFallbackModel. The API's fallbacks list form is the right shape.
2. Add claude-opus-4-7 to allowed_fallback_models for Opus 5 (and ideally Fable 5). Without this, a chain ending in 4.7 is impossible — Opus 5 users get exactly one choice, the one they're trying to avoid.

I'm not asking to remove safeguards, fix false positives, or change the default routing. Those are separate issues. This is purely about letting users choose their fallback targets — including the option to avoid a model they know doesn't work for them.

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)

Corroborating this from an Anthropic-API session running Fable 5: when the classifier fires, the fallback lands on Opus 4.8, and the observed behavior is exactly the silent-downgrade problem this issue and #73833 describe — 4.8 is a step below Opus 5, so a session on the newest model gets quietly moved to an older one on a flag, with no signal beyond the model line changing and no way back except a manual /model.

From a user's point of view this reads as a bug, not a policy: the mental model is "Fable 5 and Opus 5 are the same underlying model, one with extra dual-use safeguards and one without," so the expected fallback for a safeguarded Fable 5 request is Opus 5 (same capability, safeguards lifted), not a prior-generation Opus. Routing to 4.8 changes capability and effort silently mid-task, which is especially damaging in the middle of a multi-step agentic run where later steps inherit the weaker model.

So the ask here (configurable target + effort) plus #73833's capability-equivalent default would both address it — but flagging that the current default specifically (Fable 5 → Opus 4.8) is the concrete degradation people are hitting, and a same-generation default (Fable 5 → Opus 5) would fix the common case even before configurability lands. Happy to provide session details if useful.