effortLevel setting cannot persist the "Max" effort tier the UI offers

Version: CLI 2.1.272 (also present in the bundled schema), desktop app 1.40609.1, Windows 11
Model: Opus 5

What happens

The effort picker offers five tiers and the top one is labelled Max. The status
line confirms the selection reads Opus 5 Max.

But max cannot be written to the settings key that persists the choice. In
settings.json, effortLevel is declared as:

effortLevel: ["low", "medium", "high", "xhigh"]

So the tier the UI lets you select is not a value the persisted setting accepts.
There is no way to make Max the default; it has to be re-picked.

Why this is not just a label difference

max is a real, distinct tier in the bundle, not a display name for xhigh:

1. The canonical list has five members:

var ru = ["low","medium","high","xhigh","max"]

1. Models declare max_effort and xhigh_effort as separate capabilities.
2. Each model carries a separate cost index for both, e.g. Opus 5:

effort_cost_index: { low:0.67, medium:0.76, high:1, xhigh:1.6, max:1.7 }

1. The per-turn field documents all five:

"Active effort level for the current turn (e.g., "low", "medium", "high", "xhigh", "max")"

So max sits above xhigh and is priced above it.

The one key that does accept max is the wrong key

maxEffortLevel uses the five-value list, but it is a ceiling, not a selection.
Its own description:

"Maximum effort level. Anything above it (an /effort or /model pick, --effort, CLAUDE_CODE_EFFORT_LEVEL, a model default) is clamped to it"

Setting maxEffortLevel: "max" raises the cap. It does not select Max. The same
holds for modelSettings.<model>.maxEffortLevel.

Confirmed there is nowhere else it persists

settings.json is the only file under the config roots carrying either key.
~/.claude.json and the per-root .claude.json hold no effort state.

Expected

Either:

• effortLevel (and modelSettings.<model>.effortLevel) accept max, matching

the tier list the UI and the per-turn field already use; or

• the UI stops offering a tier that cannot be saved, and the gap is documented.

Secondary: the docs disagree with the UI

Because the schema tops out at xhigh, a reader of the settings schema concludes
"there is no Max" while looking at a slider that says Max. That is how this was
found.