Web app: selected model (Fable-tier) not applied — session reports claude-opus-4-8 instead
What happened
In the Claude Code web app, I select a specific model (a Fable-tier model) and keep it selected. But the running session's own reported model — the model id surfaced in the system context — is a different model (an Opus-tier model, claude-opus-4-8). So the selected model and the model that actually answers / is reported do not match, and I have to re-select the intended model repeatedly.
Steps to reproduce
- In the Claude Code web app, open the model picker and select a Fable-tier model.
- Continue the session (including across a context compaction / continuation).
- Ask the session what model it is, or inspect the system-reported model id.
Expected
The session runs — and reports itself — as the selected model.
Actual
The session reports claude-opus-4-8 (Opus 4.8) even though a Fable-tier model was selected. The selection does not "stick", most reliably after a compaction/continuation, and the reported model disagrees with the picker.
Impact
On a long, phone/web-driven session the mismatch is silent — the user only notices later that the session ran on a different (often more expensive) model than the one they chose. Cost and behaviour both change without a signal.
Related
This looks like the same root cluster as model-preference-not-persisted:
- #13242 (settings.json model ignored on startup)
- #39889 (dispatch/mobile ignores the selected model, no way to correct it)
- #59516 (model not preserved after
/compact, closed as duplicate)
Filing this as the web-app manifestation of the same class: the picker's selection and the session's actually-running/reported model disagree. Ask: persist the selected model across compaction/continuation, and surface the currently active model in the web-app UI so a silent swap is at least visible.