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

Summary

When the Fable 5 safety classifier flags a request, Claude Code re-runs it on a fixed default Opus model and keeps the session there. Please allow users to configure which model the classifier fallback lands on, and at which effort level — on the Anthropic API, not only on third-party providers.

Current behavior

• On the Anthropic API, the classifier fallback target is fixed (currently Opus 4.8) and the switch is sticky until a manual /model.
• ANTHROPIC_DEFAULT_OPUS_MODEL can redirect the fallback target, but per the docs this applies to third-party providers (Bedrock / Vertex / Foundry). Anthropic API users have no equivalent handle.
• --fallback-model / fallbackModel is a separate mechanism: it only fires on availability errors (overload / unavailable), never on classifier flags.
• "switchModelsOnFlag": false gives a pause-and-choose prompt, but the choice is still binary (default Opus, or edit and retry) — the target itself is not selectable, and per-flag prompts don't work for long-running or unattended sessions.

So today there is no way for an Anthropic API user to say "when the classifier fires, send me to Opus 4.6 at max effort" — even though every ingredient (model routing, effort control) already exists in the product.

Why users need explicit control (not only a better default)

#73833 proposes mapping the fallback to a capability-equivalent effort tier automatically — that would fix the silent degradation for most users, and I support it. But an automatic mapping cannot know user-specific constraints, e.g.:

1. Model-specific regressions. Several reports describe tool-call serialization problems on the current default fallback target. A user tracking such an issue may prefer an older Opus until it is resolved.
2. Effort compensation as a deliberate strategy. Effort levels are not capability-equivalent across tiers. When the substitute model is less capable, some of us want to compensate by raising effort — if the stand-in is less clever, let it be more diligent. That trade-off (latency/cost vs. quality mid-fallback) is a preference, not a constant.
3. Language/workload-specific behavior. Model behavior on e.g. CJK-heavy tool-calling workloads differs across versions; teams keep their own compatibility notes and want to route accordingly.

Proposed behavior

A settings key (naming up to the team), e.g.:

{
  "classifierFallbackModel": "claude-opus-4-6",
  "classifierFallbackEffort": "max"
}

or extending the existing fallback concept to accept model+effort pairs for the classifier path. Constraining the target to the Opus family (as the current mechanism already does) would be fine — the point is choosing the seat, even inside the cage.

Supporting context

This request came out of a community discussion in which --fallback-model was (very reasonably) assumed to cover the classifier fallback — the two same-named mechanisms are widely conflated:
https://x.com/hawkymisc/status/2073444035336065067
The effort-compensation point in that thread:
https://x.com/Bizuayeu/status/2073458044919497111

An explicit classifierFallback* setting would not only add the missing control, it would also make the mental model of the two mechanisms clearer.

Related issues

• #73833 — fallback preserves effort instead of mapping to a capability-equivalent tier (automatic-default side of this request)
• #67009 — auto-restore the primary model after a model_refusal_fallback (stickiness side)
• #68107 — auto-mode classifier fallback / ANTHROPIC_DEFAULT_OPUS_MODEL pinning is undocumented (docs side)

Environment

• Claude Code CLI (v2.1.x), Windows / Git Bash
• Session model: claude-fable-5, Anthropic API (subscription)