[BUG] Model chosen via /model silently reverts to default when session continues from another device (quota still billed to pinned model)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

A model explicitly selected via /model is silently reverted to the default model (Opus 4.8) when the same session is continued from a different client (e.g. Windows desktop app ⇄ mobile app). The UI still shows the pinned model and the pinned model's quota keeps draining, even though the default model is actually generating the responses. In our case ~8% of the Fable 5 quota was consumed while 4.8 was actually answering.

What Should Happen?

An explicit /model pin should survive a session bridge across devices. At minimum, the user should be notified when a bridge forces a model change, and usage should be billed to the model that actually served the response.

Error Messages/Logs

In the session .jsonl, the model field on assistant messages flips from claude-fable-5 to claude-opus-4-8 immediately after a bridge-session event. No overloaded / 529 / 503 trace anywhere in the session — this is not a capacity fallback, the model pin is dropped on session re-bridge.

Timeline (single session, UTC):
07:27 — /model set to claude-fable-5, working normally (331 messages)
17:59:04 — a bridge-session event, immediately followed by claude-opus-4-8, no notification; every message afterward is 4.8

Steps to Reproduce

1. In the Windows desktop app, select a non-default model via /model (e.g. Claude Fable 5).
2. Chat in the Windows app — Fable quota is used (correct).
3. Continue the same session from the mobile app and send a message. (Internally it switches to Opus 4.8 here.)
4. Return to the Windows app. Display still shows Fable, quota still drawn from Fable.
5. Run /model in the terminal → selected model now shows Opus 4.8 (silently downgraded).

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.199

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

The most important consequence is billing: because the UI keeps showing the pinned model, the user has no way to know a downgrade happened, and the pinned model's quota keeps being consumed while a different (default) model actually serves the responses. In our case a subscription-limited model's quota (Fable 5, weekly-capped) was drained by responses that were actually generated by Opus 4.8.

Two concrete requests:

1. Make the /model pin survive a session bridge across devices, OR surface a visible notice when a bridge changes the active model.
2. Bill usage to the model that actually served the response, not the previously-pinned one.

Detected via session .jsonl analysis (model field flips right after a bridge-session event, with no capacity-fallback traces). Reproduced 100% on demand.