claude-code - 💡(How to fix) Fix [FEATURE] Per-tab/per-session model selection in Claude Code (VS Code extension + CLI) [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#57742Fetched 2026-05-11 03:26:36
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Timeline (top)
labeled ×5commented ×1

Fix Action

Fix / Workaround

Current workarounds (all bad) ANTHROPIC_MODEL=... open -na "Visual Studio Code" — env var beats settings.json, but only if you launch from terminal, never relaunch from dock, fully quit between sessions, and never touch /model. One slip and they collide again. Use CLI in a terminal with --model — works, but you lose the VS Code extension UX (selections, file context, IDE integration). Manually edit settings.json between switches — a worse version of /model, same global-write problem. None of these are usable for real parallel work.

RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing requests and this feature hasn't been requested yet
  • This is a single feature request (not multiple features)

Problem Statement

The Ticket Title: Per-tab/per-session model selection in Claude Code (VS Code extension + CLI)

Severity: Feature request — blocks multi-model parallel workflows

Affected surfaces: Claude Code VS Code extension, Claude Code in Cursor (VS Code fork), Claude Code CLI sessions

Environment:

macOS (Darwin 25.4.0) Claude Code VS Code native extension Claude Code also installed in Cursor on the same machine Multiple Claude Code tabs open simultaneously across both editors Problem Model selection in Claude Code is global per user, not per-tab or per-session. The choice is persisted to ~/.claude/settings.json, which every running Claude Code instance reads from.

Concrete failure mode I hit today:

Opened Claude Code in VS Code, model was Opus 4.7. Opened Claude Code in Cursor (separate editor, same machine), tried to set it to Sonnet for a parallel task. Switching model in Cursor via /model rewrote ~/.claude/settings.json. VS Code tab silently switched to the same model — even though they're independent editor processes, tabs, and projects. This makes it impossible to:

Run two Claude Code tabs in the same VS Code window on different models (e.g. Opus for architecture + Sonnet for grunt work). Use VS Code + Cursor side by side with different models. Have a "fast/cheap" tab and a "slow/smart" tab open at the same time for the same project. Why this matters The Opus-vs-Sonnet tradeoff is exactly the kind of thing that benefits from parallelism. Opus thinks better, Sonnet ships faster. The natural workflow is:

One tab on Opus: planning, debugging hard issues, reviewing architecture. One tab on Sonnet: executing well-scoped tasks from the Opus plan. Right now the architecture forces you to pick one and serialize. That defeats the entire point of having multiple models.

Current workarounds (all bad) ANTHROPIC_MODEL=... open -na "Visual Studio Code" — env var beats settings.json, but only if you launch from terminal, never relaunch from dock, fully quit between sessions, and never touch /model. One slip and they collide again. Use CLI in a terminal with --model — works, but you lose the VS Code extension UX (selections, file context, IDE integration). Manually edit settings.json between switches — a worse version of /model, same global-write problem. None of these are usable for real parallel work.

Requested fix In priority order:

Per-tab model picker in the VS Code extension — small dropdown in the tab header. Choice lives in the tab's runtime state, never written to settings.json. Scope /model to the current session by default, with an explicit /model --persist flag if you actually want to update global defaults. CLAUDE_CONFIG_DIR env var so each editor (VS Code, Cursor, anything else running the extension) can be pointed at an isolated config directory. This also fixes the cross-editor leak. Show the active model in the tab header so you can see at a glance which tab is on what — currently you have to ask. Acceptance criteria I can open two Claude Code tabs in the same VS Code window, set tab A to Opus and tab B to Sonnet, and have both stay on their assigned model across messages. Switching the model in tab A does not affect tab B, and does not affect Cursor. Restarting VS Code restores per-tab model assignments (or at minimum doesn't silently collapse them to one global value). Documented env var (CLAUDE_CONFIG_DIR or equivalent) for isolating config between editor processes. Impact if not fixed Teams running multi-model strategies (Opus planner + Sonnet executor, or Opus + Haiku for cost optimization) cannot use Claude Code for parallel work. Forces a fallback to the API directly or to other tools.

Proposed Solution

Requested fix In priority order:

Per-tab model picker in the VS Code extension — small dropdown in the tab header. Choice lives in the tab's runtime state, never written to settings.json. Scope /model to the current session by default, with an explicit /model --persist flag if you actually want to update global defaults. CLAUDE_CONFIG_DIR env var so each editor (VS Code, Cursor, anything else running the extension) can be pointed at an isolated config directory. This also fixes the cross-editor leak. Show the active model in the tab header so you can see at a glance which tab is on what — currently you have to ask.

Alternative Solutions

No response

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

Why this matters The Opus-vs-Sonnet tradeoff is exactly the kind of thing that benefits from parallelism. Opus thinks better, Sonnet ships faster. The natural workflow is:

One tab on Opus: planning, debugging hard issues, reviewing architecture. One tab on Sonnet: executing well-scoped tasks from the Opus plan. Right now the architecture forces you to pick one and serialize. That defeats the entire point of having multiple models.

Additional Context

No response

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING