[BUG] Fable 5 → Opus 4.8 fallback is sticky for the rest of the session; benign planning/orchestration turns never return to Fable (manual /model is the only escape)

Environment

• Claude Code: v2.1.207 (desktop app session)
• macOS (Darwin 25.5.0)
• Plan: Max (20x)
• Session model: claude-fable-5[1m] pinned in settings.json (no explicit fallback config), effort: high
• NOT rate-limited when it happened: usage panel showed 5-hour limit 18%, weekly all-models 31%, weekly Fable 43%

What happened

During a long-running session orchestrating a routine web-app migration (planning, code review, PR/deploy operations, subagent delegation — no security research or other obviously classifier-adjacent content), responses started being generated by claude-opus-4-8 while the session's configured model remained Fable 5.

After that point, every subsequent turn stayed on Opus 4.8 — including pure planning/orchestration turns. The session never returned to Fable 5 on its own. The only thing that restored Fable 5 was the user manually running /model. (We initially suspected /compact had restored it; that was wrong — restoration only ever happened via manual /model.)

Session telemetry (a PreCompact state snapshot) recorded the divergence explicitly: responses generated by claude-opus-4-8 while the session setting remained Fable 5.

Expected

Per the Fable 5 announcement, flagged requests are handled by Opus 4.8. Expected scope of that fallback: the flagged turn(s) only — with automatic return to the user's selected model on subsequent non-flagged turns, or at minimum a clearly surfaced, user-reversible state.

Actual

One fallback silently downgrades the remainder of the session. Users who selected Fable specifically for orchestration/planning quality keep paying attention to a Fable session that is actually running on Opus, until they notice and manually run /model.

Related issues

• #67009 — feature request for auto-restore after model_refusal_fallback; this report is a concrete field case of the problem it describes
• #67246 — classifier switch firing on benign content
• #74311 — configurable fallback target/effort
• #66916 — overly aggressive safety filtering causing fallback

Suggested fix

1. Make the classifier fallback per-turn (retry-only), or auto-restore the configured model on the next non-flagged turn (as proposed in #67009).
2. Until then: surface the active-vs-configured model divergence persistently in the UI (not just a one-time notice), so users notice the downgrade immediately.

🤖 Generated with Claude Code

https://claude.ai/code/session_017auXvBvcByS8dTVsz2Ymtr