Claude Code Ignores Your Model Setting? Check Precedence and Resume State

If Claude Code starts on a different model than the one in settings.json, do not keep adding overrides at random. Start a fresh session with an explicit --model value, confirm the effective model with /model, and then check resume state, settings precedence, organization policy, and model availability in that order.

That sequence matters because a different model does not always mean the settings file was ignored. Claude Code can restore the model from a resumed transcript, apply a higher-precedence managed setting, substitute a restricted or unavailable model with a warning, or resolve a family alias such as sonnet to the newest available member of that family.

What you need before testing

Have these ready:

• The Claude Code version from claude --version.

• The exact model shown in the startup header or /model picker.

• The model alias or full model ID you expected.

• Whether you launched a new, resumed, continued, CLI, IDE, or Desktop session.

• Permission to read the relevant user and project settings files.

Do not post authentication tokens, complete environment dumps, managed policy files, or an unredacted ~/.claude.json in a public issue.

If work and personal accounts behave differently, first separate their Claude Code configuration and credentials so the test does not mix account policy with model selection.

Step 1: Reproduce in a fresh session

First, record the version:

claude --version

Then launch a new session with a model that currently appears in your /model picker:

claude --model sonnet

Inside the new session, run:

/model

Expected result: the picker identifies the active model. The sonnet alias means the latest available Sonnet model, not a permanent pin to one version.

Do not use --resume, --continue, or the /resume picker for this first test. Current Claude Code documentation says resumed sessions keep the model stored with the transcript. A resumed session can therefore differ from the current model setting without proving that new-session configuration is broken.

Step 2: Classify the result before editing anything

The visible notice is important. Do not reduce every replacement to a silent model switch.

If the mismatch appears only in delegated work, use the subagent fan-out guide to verify the worker model and concurrency boundary separately from the main thread.

Step 3: Inspect the supported settings layers

Claude Code supports user, project, local, and managed settings. To review only the model-related fields in files you control, run this from the project root:

for file in "$HOME/.claude/settings.json" \
  ".claude/settings.json" \
  ".claude/settings.local.json"; do
  if [ -f "$file" ]; then
    printf '\n%s\n' "$file"
    jq '{model, fallbackModel, availableModels, enforceAvailableModels}' "$file"
  fi
done

Expected result: each existing file prints one small JSON object. This avoids dumping unrelated settings that may contain private paths or operational details.

Check for these cases:

• A project or local setting that differs from the user setting.

• A full model ID that is no longer available to the account.

• An availableModels restriction.

• A fallbackModel chain that explains an availability fallback during a turn.

• Invalid JSON, which can prevent the intended file from loading correctly.

Do not delete internal cache fields from ~/.claude.json based on a forum workaround. That file is not the supported place to configure the default model, and destructive edits can remove unrelated session state.

Step 4: Apply the documented precedence rules

The highest-precedence managed settings can override lower settings, including command-line choices. Within ordinary model selection, --model and ANTHROPIC_MODEL apply to the launched session, while the model field provides a saved default.

Organization defaults add another distinction:

• A normal organization default is only the starting point. An explicit user selection can take precedence.

• An organization default configured to override user selection can return on the next launch.

• Managed settings still outrank ordinary user, project, and local settings.

If this is a managed account, ask the administrator for the expected model policy rather than trying to outvote it with another local file.

Step 5: Choose between a family alias and a version pin

Use a family alias when you want automatic upgrades within that family:

{
  "model": "sonnet"
}

Use a full model ID only when you need a specific version and that version is currently available through your provider and organization. Merge the field into the existing JSON object instead of replacing the whole file.

After saving, start another fresh session and run /model again. Expected result: the active model matches the supported alias or full ID, or Claude Code shows a specific restriction, retirement, remapping, or substitution notice.

Common failure modes

Testing only with a resumed transcript

Resume behavior can restore the transcript's model. A clean launch is the control test for the saved default.

Treating an alias as a version lock

sonnet, opus, haiku, and other family aliases can move to newer family members. Use a currently supported full model ID when exact-version stability is required.

Ignoring the startup notice

Restrictions and unavailable models can cause a replacement with a notice. Capture the exact requested and substituted names before filing a bug.

Comparing different surfaces as one reproduction

CLI, IDE, Desktop, subagents, and resumed sessions do not share every selection path. Record one surface and launch mode at a time.

Editing undocumented state

A current community report attributes model mismatches to internal cache and server behavior, but those claims are not a safe instruction to modify private state. Prefer supported settings, visible notices, and a minimal reproduction.

Why this diagnostic works

The fresh --model launch isolates explicit session selection from transcript restoration and saved defaults. The settings inventory then reveals lower-level conflicts without exposing the rest of the configuration. Finally, the policy and availability checks distinguish an unsupported pin from a genuine failure to honor a supported choice.

That gives an issue report a testable shape instead of a pile of overlapping overrides.

Report a high-signal reproduction

Include:

• Claude Code version and operating system.

• CLI, IDE, or Desktop surface.

• Fresh or resumed launch.

• Requested alias or model ID.

• Effective model shown by /model.

• Exact startup warning or organization notice.

• Which settings scopes define model, with secrets and unrelated fields removed.

• Whether claude --model <available-model> works in a fresh session.

If the same supported model is replaced without a documented policy, availability notice, or resume state, link the minimal reproduction to the current upstream model-setting reports.

Keep the tool layer reproducible too

Model selection and external tool access are separate failure domains. Once the model is verified, Aident Loadout can test a brokered read-only Action without copying a provider key into the project. The measurable check is one successful schema-inspected, preflighted, read-only execution.

Follow the Aident setup instructions, then ask your agent to find a read-only capability, inspect its input schema, preflight it, and execute it with an explicit no-write boundary.

Sources

• Claude Code settings

• Claude Code model configuration

• Claude Code models, usage, and limits

• Claude Code issue 82466: model setting not honored at session start

• Claude Code issue 83795: model-pinning behavior report

• Reddit report: model pinning behavior measured on August 4

Source behavior and commands were checked on August 4, 2026. Recheck the official model configuration and issue status after a Claude Code update.