[BUG] Top-level `effortLevel` in user settings is ignored on Opus 5.5; sessions start at the model default (`medium`)
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_LEVELis not set.- No
--effortflag at launch. - No
modelSettingsormaxEffortLevelin 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
- In
~/.claude/settings.json, set"model": "opus"and"effortLevel": "high". Don't addmodelSettings, and leaveCLAUDE_CODE_EFFORT_LEVELunset. - From a directory with no project settings, run:
echo 'Run: printenv CLAUDE_EFFORT, then reply with only its output' | claude -p --allowedTools 'Bash(printenv:*)'
- Observed:
medium. Expected:high. - Copy the same settings file to
/tmp/s.jsonand 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:
/effortslider and banner don't reflectCLAUDE_CODE_EFFORT_LEVEL=max. That's a display-only bug, closed for inactivity. - #96381: no overridable default effort.
/effortwritesmodelSettings, which outrankseffortLevel, and the env var hard-locks effort.