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

Preflight Checklist

• [x] I have searched existing issues — this consolidates and reframes #65156, #66860, #68860, #63468, and #69068 around a labeling/transparency problem none of them states head-on.
• [x] This is a single bug report.
• [x] 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 (#65156) and setting it as a default via CLAUDE_CODE_EFFORT_LEVEL (#68860) both fail with low, medium, high, xhigh, max; the status line reports xhigh, with no ultracode signal (#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