PricingSign inDownload

Blog / claude code

Claude Code uses a different model than you set? Here's the order

--model beats ANTHROPIC_MODEL, then settings.local.json, the project settings.json and your own. We tested each pair, and how to check which model ran.

On this page
  1. The order
  2. Check which model ran
  3. Find what is overriding you
  4. Two sessions in one folder, two models
  5. Pin the model in scripts
  6. A misspelled model doesn't fall back
  7. One model per project, for the whole team
  8. Seeing each session's model
  9. Frequently asked questions
  10. Why is Claude Code ignoring the model in settings.json?
  11. Which wins, ANTHROPIC_MODEL or settings.json?
  12. How do I see which model Claude Code used?
  13. What happens if the model name is wrong?
  14. Try it with your team

You put "model": "haiku" in your settings, and Claude Code still answers with another model. Or two sessions in the same folder end up on different models, and you can't tell why.

Claude Code reads the model from five places, and the first one that is set wins. We tested every pair with Claude Code 2.1.318 in claude -p, reading the model that actually answered from the JSON output.

The order#

  1. --model on the command line
  2. The ANTHROPIC_MODEL environment variable
  3. .claude/settings.local.json in the project
  4. .claude/settings.json in the project
  5. ~/.claude/settings.json, your own settings

If none of them is set, you get the default for your account.

What we ran, and which model answered:

SetModel that answered
nothingsonnet (the default here)
project settings.json: haikuhaiku
project: haiku, ANTHROPIC_MODEL=sonnetsonnet
project: sonnet, ANTHROPIC_MODEL=haikuhaiku
project: haiku, env: sonnet, --model opusopus
project: haiku, settings.local.json: sonnetsonnet
user: haiku, project: sonnetsonnet
user: haiku, --model sonnetsonnet

The one that catches people is the environment variable. An export ANTHROPIC_MODEL=… in your shell profile from months ago quietly beats every settings file, in every project.

Check which model ran#

Don't trust the setting; ask the run. In print mode the JSON result lists the models it used:

bash
claude -p "Reply with only: ok" --output-format json < /dev/null | jq '.modelUsage | keys'
[
  "claude-haiku-5-5"
]

With --output-format stream-json --verbose, the system event with subtype init has a model field, so a script can check it before any work starts. In an interactive session, /model shows the current one.

Find what is overriding you#

Work down the list:

bash
echo "env: ${ANTHROPIC_MODEL:-unset}"
cat .claude/settings.local.json .claude/settings.json ~/.claude/settings.json 2>/dev/null | grep '"model"'
  • Something in env? Find the export in ~/.zshrc, ~/.bashrc or a .envrc and remove it, or unset it for one run: env -u ANTHROPIC_MODEL claude.
  • A "model" line in settings.local.json? That file is yours, not the team's, and it is usually git-ignored, so it's easy to forget. It beats the shared settings.json.
  • A wrapper script or alias that adds --model? type claude shows whether claude is an alias or function.

Two sessions in one folder, two models#

Both sessions read the same settings files, so when they differ, the difference came from the terminal that started them: an environment variable set in one shell and not the other, or a --model flag in one command. We started two runs in the same folder at the same time, with "model": "haiku" in the project settings and ANTHROPIC_MODEL=sonnet set for one of them only:

["claude-haiku-5-5"]
["claude-sonnet-5-5"]

Same folder, same settings, two models. If one of your sessions is on the wrong model, compare echo $ANTHROPIC_MODEL in the two terminals before you look at anything else.

Pin the model in scripts#

A script or scheduled job inherits whatever environment runs it, which is often not your shell. If it matters which model a job uses, pass --model in the command itself. It is the only setting nothing else can override.

A misspelled model doesn't fall back#

We set "model": "opus-typo" in the project settings. Claude Code didn't fall back to the default; the run failed:

There's an issue with the selected model (opus-typo). It may not exist or you may not have access to it.

The exit code was 1 and is_error was true. A short alias such as opus, sonnet or haiku and a full model ID such as claude-opus-5-5 both worked.

One model per project, for the whole team#

Put the model in the project's .claude/settings.json and commit it. Everyone who opens the project gets it, unless they override it with one of the three things above it. If a teammate says "it's using the wrong model", ask them to run the two checks above. If you set up a team this way, our guide to setting up Claude Code for a team covers the rest of the shared settings.

Seeing each session's model#

When several agents run at once, it helps to see which model each one is on without asking it. Joxo lists every session on your phone and desktop with its agent and status, so a session that started on the wrong setup stands out. See running several Claude Code sessions at once.

Frequently asked questions#

Why is Claude Code ignoring the model in settings.json?#

Something higher in the order is set: the --model flag, the ANTHROPIC_MODEL environment variable, or .claude/settings.local.json. In our test ANTHROPIC_MODEL beat both the project and user settings files.

Which wins, ANTHROPIC_MODEL or settings.json?#

ANTHROPIC_MODEL. Only the --model flag beats it.

How do I see which model Claude Code used?#

Run claude -p with --output-format json and read the keys of modelUsage, or the model field of the init event in stream-json. In a session, /model shows it.

What happens if the model name is wrong?#

The run fails with "There's an issue with the selected model" and exit code 1. It does not fall back to the default model.