[FEATURE] Let ultrathink raise the effort level (up to max) for the next turn, as an option or the default

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Disclosure: This issue was drafted by Claude Code, operating autonomously in the research and drafting of its text. GitHub attributes it to the authenticated ariccio account, but Alexander Riccio is not the author of the technical claims below. His role was to ask for it, choose where it is published, and approve the exact text before posting.

ultrathink currently asks for deeper reasoning without changing the effort level: the docs say Claude Code "adds an in-context instruction" and "The effort level sent to the API is unchanged." On models with adaptive reasoning, an instruction works within the current effort level, so a session running at high or xhigh cannot get max-level reasoning for one important turn without changing the whole session's effort and remembering to change it back.

Proposed Solution

An option for what ultrathink does to the effort level of the turn it appears in, for example a setting ultrathinkEffort:

• "unchanged": today's behaviour (the in-context instruction only);
• a level name ("high", "xhigh", "max"): that level for the requests of this turn, then back to the session's level;
• "step-up": one level above the session's current level.

Either "max" or "unchanged" could be the default. In every case the raise:

• lasts one turn and reverts by itself;
• shows in the header or footer while it applies;
• respects maxEffortLevel and organization effort caps.

Where changing effort would invalidate the prompt cache (see Additional Context), keep today's confirmation prompt, or skip the raise.

Alternative Solutions

• /effort max before the turn and /effort <previous level> after it. This works but is easy to forget, and the second half is the half that gets forgotten.
• A Claude Mod (2.1.287: "Added Claude Mods: plugins may now modify deeper behavior") that rewrites the effort when the keyword appears. This works for people who write mods, but a keyword built into Claude Code should not need one.
• Setting effortLevel to max in settings is not possible ("max isn't accepted as a level"), and it would apply to every turn anyway.

Priority

Medium - Would be very helpful

Feature Category

API and model interactions

Use Case Example

A long working session on Opus 5.5 at xhigh (a sensible default for most turns). One message hands Claude dozens of answers to read, reconcile and act on. That message gets ultrathink, and the user expects the deepest reasoning available for that turn only. Today the user must also type /effort max first and restore the level after, or the keyword changes nothing about the effort sent to the API.

Additional Context

<details><summary><strong>Current behaviour, with sources</strong></summary>

• Docs, "Use ultrathink for one-off deep reasoning" (https://code.claude.com/docs/en/model-config): ultrathink requests deeper reasoning "without changing your session effort setting"; "The effort level sent to the API is unchanged."
• Docs, "Set the effort level" (same page): the effortLevel and modelSettings keys do not accept max; /effort max sets it for the session.
• Changelog 2.1.68: "Re-introduced the "ultrathink" keyword to enable high effort for the next turn". The current docs describe a keyword that no longer changes the effort.

</details>

<details><summary><strong>Why the cache cost no longer stands in the way on current models</strong></summary>

Docs, "Changing effort level" (https://code.claude.com/docs/en/prompt-caching): on Opus 5.5, Sonnet 5.5 and Fable 5.1 with an API key or a Claude subscription, "changing effort keeps the cache, and Claude Code applies the new level without asking". On other models and venues (Amazon Bedrock, Google Cloud's Agent Platform, a Claude apps gateway, HIPAA configurations) a change still reads the whole history uncached, which is why the proposal keeps the confirmation prompt or skips the raise there.

</details>

<details><summary><strong>Earlier requests (closed after going stale, not declined on the merits)</strong></summary>

• #34077 (2026-03-13): ultrathink set the effort to high rather than max; closed as not planned 2026-04-26 after inactivity. One comment proposed raising the effort one step above the current setting.
• #49612 (2026-04-17): ultrathink should default to max or xhigh; closed as not planned 2026-05-27 after inactivity. One comment asked to let users choose high, xhigh or max for the keyword.
• #49897 (2026-04-17): the same request; closed as a duplicate.

All three are locked, and the closing bot asks for a new issue that references them.

</details>

<details><summary><strong>Publication control</strong></summary>

Alexander's request, verbatim: "It's worth also drafting a feedback item so I can open a github issue to suggest they make ultrathink activate max effort for the next turn, as an option or a default, instead of requiring a custom mod." Claude Code drafted the text from the sources above. He chose to publish it here and approved the exact text.

Environment: Claude Code 2.1.285 on macOS 26.4, Opus 5.5, Claude subscription; the docs and changelog quoted above were re-checked against 2.1.289 on 2026-10-04.

</details>