Silent main-loop model fallback (Fable 5 → Opus 4.8): no notification, static identity line misleads the model, /model does not stick

Summary

During a long-running session, the harness silently switched the main-loop model from the user-selected claude-fable-5 to claude-opus-4-8 (presumably an overage/fallback downgrade) — repeatedly, and with no signal either to the user or to the model in-context. This caused the assistant to unknowingly make design decisions on a degraded model, and — worse — to falsely reassure the user it was still on Fable, because the only in-context identity signal is wrong after a switch.

Evidence (from the session JSONL, message.model per assistant message)

#571  2026-08-22T00:41:09Z  claude-fable-5 -> claude-opus-4-8   (silent; ran ~2h20m)
      2026-08-22T01:13:41Z  -> claude-fable-5                   (user ran /model fable)
      2026-08-22T01:14:56Z  -> claude-opus-4-8                  (fell back after ONE MINUTE)
      2026-08-22T01:17:19Z  -> claude-fable-5
      2026-08-22T01:50:02Z  -> claude-opus-4-8                  (fell back again)

The user had to run /model three times; the session kept flapping back within minutes.

The three concrete problems

1. No notification on switch. Neither the user nor the model receives any in-context signal (a system-reminder would be enough) when the main-loop model changes. The user discovered it only by suspicion; the model discovered it only by reading its own session transcript from disk.

1. The in-context identity line is static and becomes false. The system context says You are powered by the model named Fable 5 / The exact model ID is claude-fable-5. This line is written at session start and never updated. After the silent switch, the assistant checked this line, and told the user "model confirmed: Fable 5" while actually running on Opus 4.8. The only ground truth is ~/.claude/projects/<proj>/<session>.jsonl → message.model, which lags a turn and requires disk access.

1. /model does not stick under fallback pressure. The user explicitly re-selected Fable; the harness dropped back to Opus 4.8 after ~1 minute, twice. If a fallback policy overrides an explicit user selection, that override must at minimum be loud.

Why it matters

Model identity is part of the user's trust contract (they chose the model, and they pay for it). In our case, the main loop orchestrates multi-agent workflows and ratifies design decisions — decisions taken on a silently degraded model had to be re-audited by pinned subagents once we noticed (an earlier silent downgrade in the same project produced a real MAJOR defect that an independent audit caught). We now run a transcript check every turn as a workaround, which should not be necessary.

Requests

1. Notify on switch: inject a visible system-reminder into the conversation (and a UI banner) whenever the effective main-loop model changes, including automatic fallbacks.
2. Make identity introspectable: update the in-context model line on switch, or expose a live "current model" the assistant can read reliably.
3. Hard pin option: a setting to fail loudly instead of falling back when the selected model is unavailable/over limits (e.g. modelFallback: "ask" | "never" | "auto").

Environment: Claude Code CLI on macOS (darwin), long-lived session, model selected via /model (Fable 5).