[Bug] Silent model fallback from Fable 5 to Opus 4.8 overrides explicit model pinning

Bug Description

Bug report — silent Fable 5 → Opus 4.8 model fallback on a model-pinned task

Summary: Claude Code silently fell back from the requested model (Fable 5) to a more expensive model (Opus 4.8) partway through agent execution, with no notification, no opt-out, and despite the model being explicitly pinned for those agents. This happened on a routine, read-only local task.

Severity: High — not a correctness failure, but a silent, unrequested upgrade to a costlier model has real cost / usage-cap impact, and pinning a model should be honored or hard-fail, not silently overridden.

Environment:

• Claude Code, local machine (macOS, darwin 25.4.0)
• Default/session model: Fable 5 (claude-fable-5)
• Task: a background multi-agent Workflow review, all spawned agents explicitly pinned model: 'fable'
• Session ID: 8fb779ce-2b30-4f6e-893d-b02d6c1ab26d

What I expected: Every agent I pinned to model: 'fable' runs on Fable 5. If Fable is unavailable, I'd expect either a wait/retry on Fable or a visible notice — not a silent substitution to a higher-cost model.

What happened: 27 of 133 agents in the run had turns served by Opus 4.8. The transcripts log the substitution explicitly as an automatic fallback:

{"type":"fallback","from":{"model":"claude-fable-5"},"to":{"model":"claude-opus-4-8"}}
...
{"type":"fallback_message","model":"claude-opus-4-8"}

Once an agent fell back, all of its subsequent turns stayed on Opus. There was no surfaced notification in the UI and no setting presented to decline or to make the request hard-fail instead.

Reproduction / evidence:

• Same workflow run twice. Run pinned to Haiku: 0 of 137 agents fell back. Run pinned to Fable: 27 of 133 agents had Opus-served turns.
• Fallback markers are in the per-agent transcripts under:

~/.claude/projects/-Users-shane/8fb779ce-.../subagents/workflows/wf_49d1e421-3af/agent-*.jsonl
(grep '"type":"fallback"').

Concrete asks:

1. Surface model fallbacks visibly when they occur (especially fallback to a more expensive model).
2. Provide a setting to disable fallback / opt out of upgrade-on-unavailability so a pinned model either runs or fails cleanly.
3. Document the fallback policy: what triggers it, what the target models are, and the billing implication.

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.170
• Feedback ID: e4e31809-1dcb-4462-8488-30445c4dfef9

Errors

[]