Effort level 'max' should be persistable in settings.json for Max plan subscribers

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/33542
2. https://github.com/anthropics/claude-code/issues/30726
3. https://github.com/anthropics/claude-code/issues/31923

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Just chiming in that yes, right now, max seems unreliable. It can be set using the /model however, it cannot be set other ways but most notably ultrathink triggers high effort instead of max. Not very ultra when you think about it.

Related to issue: https://github.com/anthropics/claude-code/issues/34077

Does max effort level actually still exist? CHANGELOG of 2.1.72 says it was removed:

Simplified effort levels to low/medium/high (removed max)

Yes, max still exists. Just tested in CLI (Claude Code 2.1.86, Opus 4.6):

• /effort max → accepted, output: "Set effort level to max: Maximum capability with deepest reasoning (Opus 4.6 only)"
• /effort → shows "Current effort level: max"

Behavioral confirmation from Claude's side: when effort is "high", Claude receives a <system-reminder> tag saying "The user has requested reasoning effort level: high." When effort is "max", no such tag appears — reasoning is unrestricted.

The CHANGELOG note may refer to removing max as a separately tagged effort level — it now appears to be the unrestricted default (no system reminder tag), while low/medium/high each inject a tag that constrains reasoning.

it always return 'max' on not only statusline but also manual check on /effort command:

<img width="1792" height="392" alt="Image" src="https://github.com/user-attachments/assets/f6818724-5671-4e5c-8042-e790b70849b8" />

follow-up to my earlier screenshot — found a workaround that actually sticks across restarts.

on v2.1.116, claude --help now explicitly lists max as a valid --effort flag value:

--effort <level>  Effort level for the current session (low, medium, high, xhigh, max)

settings.json effortLevel: "max" still silently falls back to xhigh for me (schema enum hasn't been updated to accept max), but the CLI flag path is honored. so the cleanest fix is a shell alias that forces it per-session:

alias claude='command claude --effort max'

the command prefix prevents recursion if there's a pre-existing claude alias. verified the argument parser accepts --effort max on v2.1.116 / macOS 14 / opus 4.7 1M context, and the picker shows max highlighted after the alias is in place.

caveat worth flagging — per #40093, banner display and runtime effort have drifted apart before. haven't personally verified the /v1/messages payload carries effort: "max" via mitmproxy, so runtime correctness still needs independent confirmation. but the help-text documentation of max as an accepted value is a good signal that this path is the one being maintained.

in the meantime, keeping "effortLevel": "xhigh" in ~/.claude/settings.json as a valid baseline + the alias gives a stable setup that survives restarts without touching the UI.