/model: picker checkmark tracks the default instead of the active session override; full model ID silently drops the [1m] suffix
Environment
- VS Code extension
anthropic.claude-code2.1.222 (darwin-arm64), macOS 26.5.2 - Session model:
claude-fable-5(set via/modelin an earlier session / carried by the session)
Bug 1: model-picker checkmark shows the saved default, not the effective model
With the session actively running Fable 5 (confirmed by /model with no args: Current model: Fable 5), opening the model picker shows the checkmark on "Default (recommended) — Opus 5 with 1M context". The Fable row carries no indicator.
The status line and the picker disagree about the same session: the text says Fable, the checked row says Opus. I spent a day believing review runs were on Opus when they were on Fable.
Expected: the checkmark (or a second indicator) reflects the model actually serving the session, or the picker distinguishes "your default for new sessions" from "what this session is running."
Bug 2: [1m] suffix silently dropped when combined with a full model ID
/model opus[1m] → Set model to claude-opus-5[1m] ✅ suffix honored
/model claude-fable-5[1m] → Set model to claude-fable-5 ❌ suffix silently droppedThe short-name form honors the 1M-context suffix; the full-model-ID form accepts the input but applies less than was asked, with no warning. If the combination is unsupported, an error would be better than a silent partial apply.
(Report drafted with Claude Code from the affected session.)
3 Comments
+1
I can reproduce the model-picker mismatch on Windows in the Claude Code VS Code extension as well.
My global Claude settings explicitly contain "model": "opus". When the settings JSON is valid, the VS Code model picker does not clearly place its checkmark beside the explicitly configured Opus selection. The picker instead appears capable of showing a saved/default state that does not reliably communicate the effective model for the current session.
I also tested removing my project-level custom main-agent setting, and that made no difference, so in my case this does not appear to be caused by a custom agent.
One particularly interesting reproduction: when my global settings.json was temporarily malformed by a trailing comma, the picker visibly checked Default (recommended). After correcting the JSON, the checkmark behavior changed again. This makes it look like Default may represent fallback/default configuration state rather than the model actually serving the session.
Environment:
Windows
VS Code Claude Code extension
configured model: opus
picker currently offers Default (recommended), Opus, Fable, Sonnet, and Haiku
This seems consistent with the original report: the picker checkmark should either represent the effective session model, or the UI should explicitly distinguish default for new sessions from model currently serving this session.
Partially reproduced on 2.1.233 (Linux CLI).
Bug 2 (silent
[1m]drop) — reproduced, with one refinement: on 2.1.233 the short-name and full-ID forms behave the same. For a model with a 1M variant, both/model opus[1m]and/model claude-opus-5[1m]honor the suffix; for models without one, both/model fable[1m]and/model claude-fable-5[1m]silently apply the base model with no warning. So the trigger isn't short name vs. full ID — it's whether the model has a 1M option — but the core complaint stands: an unsupported[1m]request is silently ignored where a warning or error would be appropriate.Bug 1 (picker checkmark on default instead of the session override) — not reproduced in the CLI TUI on 2.1.233: after setting a session-only model, reopening
/modelshows the checkmark on the overridden model, not the saved default. Your report was from the VS Code extension (2.1.222), which we couldn't exercise in this environment — if you still see the mismatch there on a current version, a screenshot of the picker plus the/model(no args) output from the same session would help pin it down.🤖 Generated with Claude Code
For your information: the label
reproducedon this issue does not prevent it from becoming stale and eventually auto-closed. See https://github.com/anthropics/claude-code/issues/87647 for details, and consider upvoting that for visibility.This means to avoid auto-closing, this issue needs to acquire at least 10 thumbs up, or get new comments every time before the 14 days stale bot interval expires.