Bug: /model switch confirmed in UI but backend continues serving previous model for hours, silently draining weekly limit + usage credits

Summary

/model claude-opus-5 and later /model claude-sonnet-5 both returned the expected CLI confirmation ("Set model to claude-opus-5" / "Set model to claude-sonnet-5") and the footer model selector updated correctly. Despite this, the backend continued serving requests with the previously-selected model (claude-fable-5) for roughly 14.5 hours, confirmed via the message.model field in the local session transcript (~/.claude/projects/<project>/<session-id>.jsonl) — which is ground truth for what actually served each response, independent of what the UI displays.

This silently exhausted the Fable-5 weekly plan limit, then drained real usage-credit balance (pay-as-you-go overage), on model requests I never selected.

Environment

• Plan: Claude Max 20x
• Product: Claude Code (desktop app + CLI)
• Session ID: b112f44c-5dc5-4028-bf08-eccbc6b4f39c

Timeline (from session transcript message.model field)

• 2026-08-20 16:40:58 UTC — switched to Opus via /model claude-opus-5; served correctly
• 2026-08-21 12:52 UTC — still correctly on Opus
• 2026-08-21 13:49 UTC — with no user action, requests silently began being served by claude-fable-5
• 2026-08-21 13:54 UTC — briefly back to Opus
• 2026-08-21 14:04 UTC — reverted to claude-fable-5 and stayed there continuously until 2026-08-22 04:29 UTC (~14.5 hours), despite the model selector displaying Opus throughout and Fable never being reselected
• 2026-08-22 04:33 UTC — after explicitly running /model claude-sonnet-5, requests finally began being correctly served by claude-sonnet-5, and have been correct since

Impact

• Fable-5 weekly limit exhausted on requests never intentionally routed to Fable-5
• Usage credits (real charges, pay-as-you-go) subsequently drained to fund the same misrouted requests
• The UI (model selector, /model confirmation output) gave no indication anything was wrong — the only way to detect this was manually grepping the local session transcript for the message.model field on each response

How to verify

For any Claude Code session, the actual serving model per response is recorded in the local .jsonl transcript under message.model on assistant-type entries. This can diverge from both the UI's displayed selection and the CLI's own confirmation output for /model, as shown above.

Request

• Investigation into why model selection stopped propagating to the serving backend for this session
• Ideally, a client-side or server-side consistency check that surfaces a warning when message.model diverges from the user's last explicit /model selection, rather than silently billing the mismatch

Happy to provide additional transcript excerpts if useful.