/effort auto still resolves to a static level (2.1.226, Opus 5) — let the model pick the level per turn

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)

To be precise about the first box: I did search, and this has been requested before. Every prior issue was closed by the stale bot rather than on the merits, with the bot's own message "Please open a new issue if this is still relevant". This is that new issue, with fresh measurements from 2.1.226 and Opus 5. Full list under Additional Context.

Problem Statement

/effort auto reads like "the model picks the right effort for the task", but it only resolves to the model's static default and never moves.

Measured on Claude Code 2.1.226, macOS, Opus 5, three headless runs (claude -p), reading the effort field on the assistant message in the session JSONL:

| Run | prompt | effort in transcript | output_tokens |
|---|---|---|---|
| positive control, --effort low | trivial echo | low | 118 |
| auto | trivial echo | high | 111 |
| auto | "prove or disprove the twin prime conjecture" | high | 3620 |

The positive control shows the measurement would detect a change. Under auto the level is identical for a trivial shell command and for an open mathematical problem. Strings in the shipped binary are consistent with this: the effort resolution takes the model and the configuration as inputs and falls back to a hard-coded high — there is no task signal in the call.

The interesting part is the last column. The model already scales its own reasoning by a factor of 33 within the level. So the adaptive behaviour exists — what is missing is that it cannot move the ceiling.

Why this matters beyond naming: as a user I cannot tell in advance whether a given turn needs high, xhigh or max. There is no documented criterion, and the difference is not visible in the result. So I do what any user in that position does — I set /effort max for everything and accept the latency. That is a bad outcome for both sides. Claude Code's own help text for max warns it "may use excessive tokens resulting in long response times or overthinking. Use sparingly for the hardest tasks." I am knowingly accepting a quality risk on easy turns because the automatic option does not automate anything. And it burns maximum reasoning compute on echo commands.

Proposed Solution

Make auto select the effort level per turn instead of resolving to a fixed default.

Minimal version, no new setting — auto already exists and is already the default:

1. Under auto, the level for a request is chosen from the task at hand, anywhere in low..xhigh, instead of being pinned to the model default.
2. Explicit levels stay exactly as they are. /effort xhigh means xhigh, always. Only auto becomes adaptive.
3. Surface the chosen level. The effort field already exists on the assistant message and the status line already reads effort.level, so the plumbing is there — it just needs to show a value that actually varies.

Point 3 matters on its own: today there is no way for a user to see that auto never moves. I only found out by diffing transcripts.

Alternative Solutions

If per-turn selection is not on the roadmap, the fallback that would still solve my problem is documentation: concrete, testable criteria for when high, xhigh and max differ in outcome — task types, not adjectives. Today the descriptions are qualitative ("deepest reasoning", "hardest tasks"), which is not something a user can map onto their own work.

A weaker option would be making max persistable in settings.json (it is session-only today, the schema accepts low|medium|high|xhigh). That would at least remove the per-session manual step, but it treats the symptom — it makes blanket-max more convenient instead of making it unnecessary.

I would rather have the first option than either fallback.

Priority

Medium - Would be very helpful

Feature Category

API and model interactions

Use Case Example

I run operations for a Swiss SME and use Claude Code for a mix of work in the same session: renaming files and checking a service status one minute, weighing an architecture decision or analysing a contract clause the next.

I cannot predict at the start of a session which turns will be hard. Switching effort mid-session with /effort means interrupting my own train of thought to make a judgement call I have no basis for — the tool knows how hard the next turn is going to be long before I do.

So the session runs on max from the first prompt. Every trivial turn pays for it in latency, and by Anthropic's own warning, some of them pay for it in overthinking too.

Additional Context

Environment: Claude Code 2.1.226, macOS 15 (Darwin 25.6.0), Opus 5, no effortLevel in any settings.json, CLAUDE_CODE_EFFORT_LEVEL unset.

Reproduction of the measurement above:

echo 'Run this and return only its output: echo "A=$CLAUDE_EFFORT"' | claude -p --allowedTools "Bash(echo:*)"

Then read the effort field on the assistant messages in ~/.claude/projects/<project>/<session>.jsonl. Note it is not present on every assistant turn — collect across all of them. Vary the prompt difficulty and compare; add --effort low as a positive control.

Prior art, all closed by the stale bot rather than on the merits:

• #34874 — Auto-adjust reasoning effort based on prompt complexity
• #50328 — /effort auto is a hard alias (behaviour has since changed, adaptivity has not arrived)
• #60200 — Make /effort auto context-adaptive
• #65134 — Allow dynamic /effort adjustment during prompt execution
• #65732 — Model-initiated dynamic effort allocation
• #82114 — per-model default effort levels (open, related but distinct: static defaults per model, not per turn)