[BUG] Top-level `effortLevel` in user settings is ignored on Opus 5.5; sessions start at the model default (`medium`)

Status Open
Reported on v2.1.283
Maintainer reply None cached
Activity 0 comments · opened Sep 26, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet (for Opus 5.5; see Related issues for an Opus 4.7 report of the same bug)
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

What's Wrong?

"effortLevel": "high" in ~/.claude/settings.json has no effect on Opus 5.5. Sessions start at medium, which is Opus 5.5's built-in default.

The key itself works. When I pass the same settings through --settings, the session runs at high. The key only fails at user scope.

Nothing else sets effort:

  • CLAUDE_CODE_EFFORT_LEVEL is not set.
  • No --effort flag at launch.
  • No modelSettings or maxEffortLevel in any settings file.
  • No project or local settings set effort.
  • No managed settings.

That leaves step 3 of the documented resolution order (the model default), even though step 2 (the top-level effortLevel) should apply.

This is not the write-back problem in #96381. That bug needs a modelSettings entry to outrank effortLevel. I have no modelSettings entry, and running /model didn't create one.

What Should Happen?

Per the settings reference, effortLevel sets the default for models without a saved level of their own. With no modelSettings entry for Opus 5.5, new sessions should start at high.

Error Messages/Logs

None. It fails silently. The session reports its effective level in the CLAUDE_EFFORT variable it exports to Bash tool calls, and /model shows the same level.

Steps to Reproduce

  1. In ~/.claude/settings.json, set "model": "opus" and "effortLevel": "high". Don't add modelSettings, and leave CLAUDE_CODE_EFFORT_LEVEL unset.
  2. From a directory with no project settings, run:

echo 'Run: printenv CLAUDE_EFFORT, then reply with only its output' | claude -p --allowedTools 'Bash(printenv:*)'

  1. Observed: medium. Expected: high.
  2. Copy the same settings file to /tmp/s.json and run the command again with --setting-sources local --settings /tmp/s.json. Result: high.

The same thing happens in interactive sessions, where /model reports medium effort.

Results from my tests:

| Configuration | Effective effort |
|---|---|
| User settings with effortLevel: high (env var blanked through --settings '{"env":{"CLAUDE_CODE_EFFORT_LEVEL":""}}') | medium |
| Same file contents loaded through --settings instead of as user settings | high |
| --settings '{"env":{"CLAUDE_CODE_EFFORT_LEVEL":""},"effortLevel":"high"}' on top of user settings | high |
| --settings '{"model":"opus"}' with no effort config (control) | medium |
| CLAUDE_CODE_EFFORT_LEVEL=high in user settings env, launched with --effort low | high |

Row 3 shows that blanking the env var doesn't force medium by itself. The difference comes down to where effortLevel is loaded from.

Claude Model

Opus 5.5 (opus alias)

Is this a regression?

It seems to recur with each Opus launch. #49809 reported the same symptom on Opus 4.7 in April.

Last Working Version

Unknown. Before 2026-09-25 I had a modelSettings entry at high, which masked the problem. It started when I removed that entry and relied on the top-level key.

Claude Code Version

2.1.283 (native install)

Platform

Anthropic API (Claude Pro subscription)

Operating System

macOS (Darwin 27.0.0)

Terminal/Shell

zsh

Additional Information

Possible cause. ~/.claude.json contains unpinOpus47LaunchEffort, unpinOpus48LaunchEffort, and unpinFable5LaunchEffort, all true, but no flag for Opus 5.5. The #49809 reporter noticed the same unpinOpus47LaunchEffort flag. My guess is that each new model gets a pinned launch effort that outranks user-scope effortLevel until something unpins it, and flag-scope settings bypass the pin. That's inference from the flag names, not something I traced in the code.

Workaround. Set CLAUDE_CODE_EFFORT_LEVEL in the settings env block. It works, but as #96381 describes, it also locks effort so /effort, --effort, and skill or subagent effort: frontmatter can't change it.

Related issues

  • #49809: same symptom on Opus 4.7. It was closed as a duplicate of #49538, but #49538 covers a different bug.
  • #49538: /effort slider and banner don't reflect CLAUDE_CODE_EFFORT_LEVEL=max. That's a display-only bug, closed for inactivity.
  • #96381: no overridable default effort. /effort writes modelSettings, which outranks effortLevel, and the env var hard-locks effort.

View original on GitHub ↗