Desktop Code tab: model picker shows Fable 5 (1M) while session runs Sonnet 4.6 (200k); context meter pinned at 100% red and exceeding its own denominator

Environment:

• Claude Desktop for Windows, Code tab — Windows 11 Home, build 10.0.26200
• App version: unknown (default %LOCALAPPDATA%\AnthropicClaude path not present; can provide on request)
• Project: local git repo, permission mode "Bypass permissions"
• Date observed: 2026-06-10

Summary:
A long-running Code session displays three mutually inconsistent states:

1. The model selector under the input box reads "Fable 5 (1M context)".
2. The model actually serving the session self-identifies in its runtime environment as Sonnet 4.6 (claude-sonnet-4-6), consistent with the context meter's 200k denominator.
3. The context-window meter reads 242.4k / 200.0k (100%) (later ~256k / 200k) with a red/full progress ring — i.e., usage above its own stated maximum.

Steps to reproduce (as best known):

1. Start a Code session (this one began on Sonnet 4.6; the picker may have been changed to Fable 5 mid-session, or the Fable 5 selection silently failed to apply at session start).
2. Run a long, tool-heavy task until accumulated context exceeds 200k tokens.
3. Observe the context-window meter and the model picker.

Expected behavior (any one of these would resolve the confusion):

• The model picker reflects the model actually serving the in-flight session; or
• Changing the picker mid-session switches the serving model on the next turn, and the meter denominator updates to the new model's window (1M for Fable 5); or
• If the picker only applies to new sessions, the UI says so instead of displaying a model the session isn't using.

Additionally: the context meter should never report usage above its denominator. If auto-compaction/summarization is what keeps the session functional past the raw window, the meter should communicate that state (e.g., "compacting older context") rather than pinning at 100% red, which reads as a hard failure.

Actual behavior:

• Picker: "Fable 5 (1M context)". Serving model (confirmed via the assistant's own environment metadata in-session): claude-sonnet-4-6.
• Meter: 242.4k–256k used / 200.0k max, "(100%)", red ring. The session continued to function (compaction appears to be handling the overflow), but the UI gives no indication of that.
• The plan-usage panel concurrently showed "Sonnet only: 0%" while the 5-hour (8%) and weekly all-models (2%) meters were nonzero, further obscuring which model was actually being used and billed.

Impact:
I selected a 1M-context model and reasonably believed the session had a 1M window; in reality it ran on a 200k-window model and entered over-capacity compaction. This misleads model choice, capacity planning, and trust in the meters. Severity: medium — no data loss, session kept working — but it's a UX/correctness bug that undermines confidence in what the app reports.

Hypothesis (unverified):
Mid-session model changes don't rebind the active session's backend model, while the picker updates immediately; the context meter denominator stays bound to the original model, and the percentage is clamped to 100% instead of reflecting compaction state.

Screenshot: to be attached in a follow-up comment.

---
_Report drafted and filed via Claude Code (Sonnet 4.6) at the account owner's request, from inside the affected session._