/effort presents 'ultracode' as a top effort tier, but it's xhigh + a workflow flag — and nothing at selection says so

[afram123]

Preflight Checklist

• I have searched existing issues — this consolidates and reframes [BUG] Unknown --effort value 'ultracode' #65156, /effort without arguments should show interactive slider UI #66860, [BUG] NO way to set ultracode effort default #68860, [Bug] Statusline effort.level reports "xhigh" instead of "ultra" for ultracode mode #63468, and Status line: no way to distinguish ultracode from xhigh (no ultracode field in stdin JSON) #69068 around a labeling/transparency problem none of them states head-on.
• This is a single bug report.
• I am using the latest version of Claude Code.

What's Wrong?

The /effort selector presents ultracode as the top option in the same list as the real reasoning tiers. /effort's own error string spells it out:

Valid options are: low, medium, high, xhigh, max, ultracode, auto

Seated there, above max, every reasonable user reads ultracode as "the highest-reasoning setting." It is not an effort level at all, and three independent surfaces confirm that:

• The docs: "Ultracode is a Claude Code setting rather than a model effort level: it sends xhigh to the model and additionally has Claude orchestrate dynamic workflows… it is not an additional API effort level."
• The shipped CLI (v2.1.183): the real effort set is exactly low / medium / high / xhigh / max; ultracode resolves to xhigh and is tracked as a separate session boolean.
• Every other entry point rejects it: --effort ultracode ([BUG] Unknown --effort value 'ultracode' #65156) and setting it as a default via CLAUDE_CODE_EFFORT_LEVEL ([BUG] NO way to set ultracode effort default #68860) both fail with low, medium, high, xhigh, max; the status line reports xhigh, with no ultracode signal (Status line: no way to distinguish ultracode from xhigh (no ultracode field in stdin JSON) #69068).

So the most powerful-looking choice actually means xhigh — one tier below max — plus automatic workflow orchestration the user never separately asked for, and only for the current session. A user who picks ultracode over max to "get the most reasoning" silently gets less reasoning than max. None of this is disclosed where the choice is made.

That is the real problem, and it deserves more than a doc edit. In #63468 a maintainer closed the matching status-line report as "the current behavior is expected" and said they would "fix our doc." But users aren't misled by the docs — they're misled by the picker. Quietly repurposing a control that sits in the effort list so that it means "xhigh + a behavior change," without saying so at the point of selection, is exactly the kind of opacity that erodes trust: it reads as the tool quietly deciding what's good for the user instead of telling them and letting them choose. People notice, and in a market where switching is one command away, being straight with users at the point of choice is not a nice-to-have.

What Should Happen?

Make the picker honest where the user actually selects it. Any of:

• Visually separate ultracode from the reasoning tiers (a divider, or a "Modes" subsection) so it is not read as "the rung above max."
• Annotate it inline with what it is — the CLI already ships the exact words: "xhigh + dynamic workflow orchestration."
• Disclose that it is session-scoped (unlike max, which persists), so the silent revert to xhigh on the next session is not a surprise.
• Either give ultracode real flag / env / status-line parity, or stop presenting it as if it were a peer effort level.

None of this changes behavior — it just stops the UI from implying something false.

Steps to Reproduce

1. Run /effort (or claude --effort ultracode).
2. See ultracode offered alongside low / medium / high / xhigh / max, above max.
3. Select ultracode. Observe: it runs at xhigh (status line shows xhigh), adds workflow orchestration, and reverts to xhigh in a new session — while max would have persisted. Nothing at selection time discloses any of it.

Is this a regression?

No — a design/labeling issue present since ultracode was added to the effort selector.

Claude Code Version

v2.1.183

Platform

Claude Code CLI (native install). The same labeling surfaces appear in the desktop app / VS Code per #66083, #66860, #68754.

Operating System

Windows 11

Terminal/Shell

PowerShell / Windows Terminal

---

Related: #65156, #66860, #68860, #63468, #69068, #66083, #68754

[danmirman]

Concrete surface: the /model set-as-default flow

Adding a repro from a surface I don't see explicitly named here yet — the /model picker's "set as default" path:

• Open /model, use the effort slider (left/right arrows) to land on ultracode, and save it as the default model.
• Nothing persists. Verified on disk: no top-level model key is written to ~/.claude.json, and ultracode appears in no config file — the selection is a silent no-op.

This is consistent with ultracode being session-only (max/ultracode aren't accepted as a persisted effortLevel), but the default picker still offers it as a selectable default with zero feedback that it can't be saved. #68860 ("NO way to set ultracode effort default") is closed, yet the /model default flow still presents it as a choosable default — so from the user's side it looks broken rather than intentional.

Suggested fix: in the set-as-default flow, either omit ultracode/max (they're session-only by design) or show an inline note like "session-only — can't be saved as default" at selection time.

Env: Claude Code 2.1.170, Opus 4.8 (supports xhigh, so this isn't the capability gate in #69653's sibling reports).

[Acuru]

+1 — hit this exact trap in practice as a power user deliberately optimizing for quality. #69653 nails the core mislabeling; adding four things it doesn't cover yet.

1. Real user, caught in the act. With a token surplus and wanting the best output for a session, my reflex was to pick Ultracode because the UI presents it as the top / "Smarter"-most option. Only a multi-turn interrogation of the assistant revealed it's xhigh (below Max) + an orchestration mode. Verbatim, in the original Polish (authentic voice — and itself a data point on non-English usage):

"...mam zapas tokenów więc optymalizuję pracę ... więc CHCĘ CI DAĆ ULTRACODE BO TAK MÓWI MI INTERFEJS, ale pytam jeszcze cię o zdanie ... wychodzi że ultracode jest pułapką, to co pokazuje mi interfejs AKTYWNIE WPROWADZA MNIE W BŁĄD"

(EN: "I have a token surplus so I optimize the work ... so I WANT TO GIVE IT ULTRACODE BECAUSE THE INTERFACE TELLS ME TO, but I ask [the assistant's] opinion first ... it turns out Ultracode is a trap; what the interface shows me ACTIVELY MISLEADS ME.")

2. The harm is often the wrong tool, not just less reasoning. Ultracode's auto-orchestration fans work into background subagent workflows — counterproductive for precise, sequential, single-file, or approval-gated tasks (careful refactors, small edits, review-gated work) where you want one tight reviewable loop, not a fleet. So a user steered to Ultracode for "quality" on such tasks gets both lower raw effort and a mismatched execution mode. (Corroborated by [MODEL] Fable 5 Ultracode spawns excessive parallel agents for single refactoring task #66867 — Fable 5 Ultracode spawning excessive parallel agents for a single refactor.)

3. Non-English users get even less signal. The "Faster/Smarter" labeling and the English-only keyword mechanics leave a non-English user optimizing in good faith with nothing to go on.

4. Consider structural decoupling, not only disclosure. The fixes here all make the coupling more transparent. Cleaner: split the axes — a monotonic reasoning-effort slider (low…max) + an independent "Ultracode / auto-orchestration" toggle. They're different things (how hard it thinks per turn vs. whether it self-orchestrates); one "Faster→Smarter" line will keep misleading while it mixes them.

[Acuru]

To add to above, yep this above is what i ordered Claude to prepare and instruct me where to post it. Sended report also by /feedback skill (have issue id saved). I am making full archive of what happened (to my best abilities), and not touching claude session.

Feel free to contact me if you want more detailed insigth :) Have a great day.