ultracode occupies an effort tier but is a session-only workflow boolean: never persists, unobservable, and spawned sessions silently drop to `high`

Preflight Checklist

• [x] I have searched existing issues. This is a follow-up to my own #69653 (open since June, unaddressed) covering two things none of the existing reports state: ultracode has no observable state anywhere, and it is not inherited by sessions spawned from a session — they land on high. Related: #71774, #72435, #78691, #80301, #78718, #84163, #69068, #86193, #77298.
• [x] This is a single report.
• [x] I am using the latest version of Claude Code (2.1.234).

What's Wrong?

1. ultracode is a workflow boolean sitting in the reasoning-effort picker — and the correct control already exists in Settings.

This isn't interpretation; it's what the shipped bundle says. In v2.1.234 the two settings are declared side by side, with different types and different lifetimes:

effortLevel: z.enum(["low","medium","high","xhigh"]).optional()
  .describe("Persisted effort level for supported models.")

ultracode: z.boolean().optional()
  .describe("Enable ultracode for the session: xhigh effort plus standing dynamic-workflow
             orchestration. Session-scoped — typically provided via --settings or the
             apply_flag_settings control request; interactive toggles never persist it.
             Requires workflows to be enabled and an xhigh-capable model.")

One is an enum of reasoning tiers. The other is a boolean mode. Internally the real ladder is ["low","medium","high","xhigh","max"] and ultracode is just an alias entry {ultracode: "xhigh"}. Yet /effort and the app's effort selector list low, medium, high, xhigh, max, ultracode, auto — a boolean mode rendered as the rung above max, while actually resolving below max.

And here is the part that is hard to defend: the honest control is already shipped. The Settings panel already carries a persistent boolean:

{ id: "workflows", label: "Dynamic workflows", type: "boolean" }   // enableWorkflows / disableWorkflows
{ id: "workflowSizeGuideline", label: "Dynamic workflow size" }
workflowKeywordTriggerEnabled                                      // the "ultracode" keyword trigger

plus CLAUDE_CODE_DISABLE_WORKFLOWS and an org-policy gate. So dynamic workflows already have a proper on/off switch, a size knob, and a keyword-trigger switch. The effort-picker entry is a third, session-only, non-persisting duplicate of that same switch, whose side effect is to move the user's reasoning tier. That is the complaint in one sentence: stop expressing a feature flag as an effort level when the feature flag already has a home.

2. It never persists, it is not inherited, and you cannot see which state you are in.

• Never persists: "interactive toggles never persist it" is explicit and by design, so every new session silently drops it — while a picker-chosen effort tier is what a user reasonably expects to stick. effortLevel also refuses to persist max/ultracode at all (#80301). Choosing the top option is the one choice you have to re-make forever.
• Not inherited by spawned sessions: this is the one that actually costs work. With ultracode on in the parent session, spinning off a task from within that session — the background-task chip, "start locally", or running it in a new worktree — does not carry the mode over. The new session comes up at high, two rungs below what the parent was running, not even xhigh. The effort resolution has a fallback chain that lands on "high" whenever the requested tier can't apply in the new context, and nothing tells the user it happened. Same class of gap as #77298 (no per-call effort on the Agent tool), but for whole spawned sessions.
• Unobservable: there is no way to check, from any surface, whether ultracode is actually on. In this session, with ultracode active, the session-management API reports:

{ "sessionId": "local_3f81…", "model": "claude-opus-5", "effort": "xhigh", "isRemote": false }

No ultracode field. A plain xhigh session returns a byte-identical shape. The statusline has the same hole (#69068), Remote Control refuses it outright ("is session-scoped and won't reach the remote process. Use low, medium, high, or xhigh instead"), and the model itself can't read it (#86193).

Put together, the loop a daily user actually lives in: pick the top-looking option → silently get xhigh (below max) → it evaporates on every new session → spawn a task from that session and it quietly lands on high → and no surface anywhere will tell you which of the three states you are in. The only way to find out is to interrogate the assistant, which is what #69653's commenters ended up doing too.

What Should Happen?

1. Take ultracode out of the effort picker. It is a mode, not a rung. The "Dynamic workflows" boolean already in Settings is the correct home — have the in-session toggle write to that (or sit beside it as its own control), and leave the effort ladder as five honest reasoning tiers.
2. Make the state observable. An ultracode (or mode) field in session metadata, the statusline stdin JSON, /status, and something the model can read. Today it is the only session setting with zero read-back.
3. Inherit it. A session spawned from a session — task chip, "start locally", new worktree, fork — should inherit the parent's effort and mode, or state plainly at spawn time that it did not.
4. Never silently degrade to high. If the mode can't apply in the new context, keep the equivalent numeric tier (xhigh) and surface one line saying the mode was dropped. Dropping two tiers below the parent without a word is the actual bug.
5. Let it persist, symmetric with disableWorkflows — the ask in #71774 and #72435, both still open.

Steps to Reproduce

1. In a session, set effort to ultracode (or use the keyword). Note the picker shows it above max.
2. Query that session's own metadata (session-management API, statusline JSON, /status): it reports effort: "xhigh" with no ultracode field. Nothing distinguishes it from a plain xhigh session.
3. From inside that session, spawn a task — background-task chip, "start locally", or a new worktree. Open the new session's effort selector: it reads high — not ultracode, not even xhigh. No notice was given.
4. Open any new session normally: back to the default. Nothing about the choice survived.
5. Meanwhile, Settings → "Dynamic workflows" has been a persistent boolean the whole time.

Is this a regression?

No — a design issue present since ultracode was added to the effort selector. The spawn/inheritance behaviour (step 3) has not been reported before.

One broader note

I file these because I use this tool all day, not to score points. But there is a pattern worth naming: shipping a feature flag disguised as a capability tier, then making it session-only and unreadable, means the tool is quietly deciding how it wants to be used instead of telling users what the switch does and letting them choose. Most people running Claude Code are perfectly capable of deciding for themselves when they want fan-out orchestration — they just need the switch labelled honestly and left where they put it. disableWorkflows proves the team already knows how to do this. Please do the same here.

Claude Code Version

2.1.234 (native install; same behaviour in the Claude Desktop app's bundled engine)

Platform

Claude Code CLI + Claude Desktop app

Operating System

Windows 11

Terminal/Shell

PowerShell / Windows Terminal