Effort-level and ultracode setting resolution reworked
The logic that figures out each model's effort level and whether ultracode is active was reworked, changing how userSettings and legacy effort settings combine.
You'll noticeTier: how much it should matter to you
2Useful: my rating, 1 to 5
2Signal: worth watching, 1 to 5
ElsewhereArea: what it touches
ImprovementsKind: in v2.1.280,
ImprovementsSection of the release
What
The function that resolves the effective effort level for a model across settings sources changed how it treats a setting from the "userSettings" source: it's now only honored if another, non-userSettings source also matched, or a new check passes for that model. Previously any userSettings effortLevel was used directly.
The broader function computing per-model effort levels was rewritten to separate a top-level "legacy user effort" from settings-file-declared effort and to track which source sets the top-level default; when ultracode is on for the whole session it now returns a default of xhigh plus a per-model map, instead of the previous empty per-model map.
The check for whether ultracode mode is active (via settings or a keyword trigger) no longer performs an extra side-effect call as part of just checking the boolean; it's now a pure check.
Why
This makes effort-level resolution more predictable, so settings-file values and legacy user settings interact consistently, and checking whether ultracode is on no longer has unrelated side effects.
How sure we are
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubtWhat the new model check specifically verifies, and which configurations are affected in practice, is not stated in the evidence.
Anthropic's release notes agreeChanged Opus 4.7, Opus 4.8 and Fable 5 to stop holding their launch-default effort over /effort in -p or the Agent SDK, a project, managed…
