VS Code extension ignores project-level model setting
Feature Request
The VS Code extension should respect per-project model selection, the same way the CLI does.
Current Behaviour
The claude CLI correctly reads the model from project-level .claude/settings.json:
{
"model": "haiku"
}Opening claude in a terminal in that project directory uses haiku. Other projects use the global default from ~/.claude/settings.json.
The VS Code extension ignores this entirely. It only reads claudeCode.defaultModel from the global VS Code settings.json. There is no per-project model override.
What Was Tested
All of these were tested and none change the model for the extension:
.claude/settings.jsonin the project root with"model": "haiku"— extension ignores it.vscode/settings.jsonin the project root with"claudeCode.defaultModel": "haiku"— extension ignores workspace-level settings/modelcommand in the sidebar — works, but writes to the global VS Code settings.json, affecting all open workspaces
Expected Behaviour
The extension should follow the same hierarchy as the CLI:
.claude/settings.json (project — highest priority)
~/.claude/settings.json (user global — fallback)
claudeCode.defaultModel (VS Code setting — lowest priority fallback)Or at minimum, respect VS Code's standard workspace settings mechanism (.vscode/settings.json overrides user settings).
Why This Matters
Users working across multiple projects need different models for different contexts — e.g. Opus for complex repos, Haiku for quick tasks. This works perfectly in the CLI but is impossible in the extension without manually running /model every time you switch windows (and that change is global, affecting other windows).
Environment
- Claude Code 2.1.70 (VSCodium extension on macOS)
- Also affects VS Code (same extension)
5 Comments
Workaround: use the VS Code workspace settings
This should be picked up by the extension since it's a VS Code workspace setting.
If that doesn't work, you can force the model via environment variable:
The
CLAUDE_MODELenv var takes precedence over settings files in the CLI. The extension may or may not respect it, but it's worth trying.Only work around I've found is running an Opus is terminal, Sonnets elsewhere. However having just one Opus is crippling. In addition that switch between all models runs the risk of an Opus being at a context to where the Sonnet would compress crashing and being corrupted. The sort of codebase I'm running I need specialized instances of Claude using different models. If I where able to switch the model between tasks all the better usage. Without risking user error of a global change and crashing an Opus, or forgetting my Opus and change and destroying my usage.
On another note, open sourcing Claude Code only makes sense at this point. Keeping it closed source made sense before the leak, nobody wanted the competition getting a free ride. But that ship has sailed, flying a black flag.
"The leak eliminated the competitive secrecy argument. The only people still locked out are the legitimate users funding development."
— Sonnet 1.3.3.7, 4.20.26
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
Absolutely unacceptable that this issue is closed with no reply from the Anthropic team. It is affecting our workflow greatly, especially since models have different pricing.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.