Ultracode is the name of two different things in Claude Code, and most of the confusion around the feature comes from that one fact. Typed as a keyword in a prompt, it makes Claude structure a single task as a multi-agent workflow. Switched on as a session toggle, it does that for every substantive task until you turn it off. Both now run on Claude Opus 5.5, Anthropic's current default Opus model in Claude Code, and both work on Claude Sonnet 5.5 as well. For the right class of work, either one removes the need to orchestrate agents by hand or break a large task into sequential prompts. For routine work, both are an expensive way to do something simple.
Two things changed in the last two weeks of September 2026 and this guide reflects both. Claude Opus 5.5 shipped on September 22 and became Claude Code's default Opus. Then, on September 28, Claude Code 2.1.284 turned ultracode into its own on/off toggle that no longer forces xhigh reasoning effort. If you read an earlier version of this article, or any post that says "ultracode means xhigh plus workflows", that description is now out of date.
This guide covers what ultracode actually does, how to enable it today, what a real run cost and returned on a public codebase, what Opus 5.5 changes about the cost, and how to decide whether a given task warrants it.
Key Takeaways
- Ultracode means two different things. The `ultracode` keyword in a prompt runs one task as a workflow at your current effort. The ultracode toggle (Tab in `/effort`, or `/effort ultracode on`) does it for every substantive task in the session. Since Claude Code 2.1.284 (September 28, 2026) the toggle no longer forces `xhigh`: effort and orchestration are now separate dials.
- It runs on Opus 5.5 by default. Opus 5.5 became Claude Code's default Opus on September 22 at $4/$20 per million tokens, about 40% cheaper than Opus 5 on a typical workload. Its default effort is `medium`, not `high`, so a fresh session with ultracode on fans out at medium unless you raise it. Sonnet 5.5 supports ultracode too.
- The mechanism is context economics, not smarter thinking. A workflow script holds the plan and intermediate results; each agent gets a fresh context window. Effort scales depth inside one context, orchestration scales breadth across many.
- A real pre-check on Excalidraw cost 471k tokens, 264 seconds, 5 agents, and refuted the issue thread's own technical proposal, caught a shallow-clone defect in its inputs, and found a newer upstream precedent. The value came from the adjudicator layer that disbelieved the searchers.
- Best fits: codebase-wide audits, large migrations, cross-checked research, security reviews, and long feature-request threads. Skip it for single-file edits, quick questions, anything needing mid-task input, and the writing itself.
- Gotchas: the keyword is inert from `-p`, SDK, scheduled, and webhook input; the 25-agent / 1.5M-token warning is OFF when the toggle is on; the medium size guideline now means fewer than 10 agents (Pro plans default to small); and one request can chain several workflows.
- Benchmark honestly: effort and ultracode are independent now, so test them as a 2 x 2 grid, use a fresh session per arm, hold the size guideline fixed, and report token counts for every arm.
Learn this hands-on
Go from idea to a live product with real users. Build and ship your first SaaS with Claude Code in a live cohort, with auth, payments and deployment done by the end. Join the Ship Your First SaaS with Claude Code cohort.
What Changed With Claude Opus 5.5
Claude Opus 5.5 was released on September 22, 2026, and Claude Code 2.1.280 made it the default Opus model the same day. Pro and Team Standard plans also switched their default model from Sonnet to Opus on that release, matching Max, Team Premium, and Enterprise. If you have not pinned a model, your ultracode runs are already happening on Opus 5.5.
Three facts about the model matter for ultracode specifically.
It is cheaper to fan out. Opus 5.5 is priced at $4 per million input tokens and $20 per million output tokens, a 20% cut from Opus 5's $5 and $25. Cache reads dropped 60%, to $0.20 per million. Anthropic says a typical workload costs about 40% less than on Opus 5, with output generated more than 30% faster. Anthropic's own usage data explains why the cache number matters most: between March and September 2026 the input-to-output ratio in Claude Code sessions moved from 189:1 to 324:1, so agentic work is overwhelmingly rereading context, which is exactly what a fan-out of agents does.
It defaults to medium effort, not high. Opus 5 started at high. Opus 5.5 starts at medium in Claude Code and on the API, and a saved effort level from before /effort became per-model does not carry over to it. Combined with the toggle change below, that means a fresh Opus 5.5 session with ultracode on orchestrates workflows at medium effort unless you raise it yourself.
It still supports xhigh, so ultracode is available. The ultracode toggle only appears for models that support xhigh: Opus 5.5, Sonnet 5.5, Opus 5, Sonnet 5, Opus 4.8, Opus 4.7, and the Fable models. Opus 4.6 and Sonnet 4.6 do not qualify. Opus 5.5 ships with a 1M-token context window, 128K maximum output, and a June 2026 knowledge cutoff. On Anthropic's published benchmarks it leads Fable 5.1 on Terminal-Bench 4.0 (66.4% vs 55.8%) and on AutomationBench (40.0% vs 31.4%), which are the two evaluations closest to what a workflow agent actually does. For the full breakdown against Opus 5 and Fable 5.1, see our Claude Opus 5 guide and the Claude API pricing guide.
Ultracode Means Two Different Things
Before anything else, get this table straight. It is the single most confusing thing about the feature, and it changed on September 28.
| Effort | Orchestration | Scope | |
|---|---|---|---|
ultracode typed in a prompt | unchanged | this turn only | one turn |
Ultracode toggle (/effort then Tab, or /effort ultracode on) | unchanged | every substantive task | whole session |
claude --effort ultracode at launch | raised to xhigh | every substantive task | whole session |
The docs are explicit on the keyword: "To run a single task as a workflow without changing the session's effort level, include the keyword ultracode in your prompt. The keyword only chooses how Claude structures the work." And on the toggle: "Ultracode is a Claude Code setting that turns on automatic workflow orchestration for the session, at whichever effort level the session runs at."
What changed: before 2.1.284, ultracode was the top stop on the /effort slider and selecting it forced xhigh reasoning. The release note reads: "Changed Ultracode into its own toggle in /effort (Tab, or /effort ultracode [on|off]): it no longer forces xhigh effort and stays on at any effort level." So the setting no longer bundles an effort bump. Effort is one dial, orchestration is another, and you set them independently. The one exception is the launch flag claude --effort ultracode, which still sets xhigh and turns the toggle on in one move.
Why the collision existed in the first place: the keyword arrived by rename. Claude Code's changelog notes that the dynamic-workflow trigger was renamed from workflow to ultracode, and that the word "workflow" no longer triggers a run. An existing trigger word was renamed onto an existing effort tier, and for a few months the two were welded together. The decoupling is an improvement, but it means a lot of advice written before September 28 is quietly wrong. While preparing the benchmark described below, we got the two meanings wrong twice in one session, once in each direction, with the changelog open. If you are comparing ultracode against anything, decide first which of the two you mean, and check which effort level your session is actually running at.
What Ultracode Actually Does
The honest claim is not "ultracode uses subagents and a normal session does not." A normal session can spawn subagents too. The claim is about who holds the plan.
With subagents, skills, or agent teams, Claude orchestrates turn by turn, and every intermediate result lands back in Claude's context window. With a workflow, a JavaScript script written by Claude holds the loop, the branching, and the intermediate results. Agents fan out in parallel where possible, each with a fresh context window, and only the final answer returns to the main context.
That distinction is the mechanism. Effort scales depth inside one context. Orchestration scales breadth across many. A solo run at maximum effort still reads everything through a single window and starts sampling when the material does not fit. In a fan-out, one agent can spend its whole window on a repository's type definitions while another spends its whole window parsing a 232-entry library catalog, and neither competes for the other's budget. Ultracode is context economics, not smarter thinking.
What it looks like in practice: you ask Claude to audit authentication across your API layer. With the toggle on, Claude may spin up one workflow to map all the routes, a second to audit each one, and a third to verify the findings adversarially before producing a report. All of that happens without you specifying the structure. A single run can spawn hundreds of agents. The technical ceiling is 1,000 per run and 16 concurrent on a typical machine. Completed work is cached and resumable within the session.
How to Enable It
There are three routes, matching the three rows in the table above.
For one task, include the keyword in your prompt:
ultracode: audit every API route for missing authentication
For the whole session, open /effort, press Tab to flip the Ultracode toggle, then Enter. Or type it directly:
/effort ultracode on
In VS Code, the extension shows an Ultracode on/off switch under the Effort slider, and the model pill reads "· Ultracode" whenever it is on, at any effort level. Turn it off with /effort ultracode off when you return to routine work.
To start every session with it on, set "ultracode": true in your settings file. To start one session with ultracode on and effort at xhigh in a single move, launch with claude --effort ultracode. The CLAUDE_CODE_EFFORT_LEVEL environment variable and the effortLevel setting accept standard effort levels only.
The toggle is session-scoped unless you set it in settings. That is deliberate: choose it for specific heavy tasks, then drop back to routine work. Because effort is now a separate dial, also check /effort before a large run. On Opus 5.5 a fresh session sits at medium, which is fine for a bug sweep but thin for an adversarial security review, where xhigh is worth the extra spend.
One gotcha that will silently ruin any scripted comparison: the keyword does not fire from non-human input. The docs list where it is inert: a prompt passed with -p, an Agent SDK prompt not stamped as human input, a scheduled task prompt, and a webhook payload or pull request comment relayed into the conversation. If you script a benchmark non-interactively, you will measure a plain run and not be told.
This shift toward delegation is already well underway. As Anthropic CEO Dario Amodei observed, "some of the strongest engineers I've ever met are now handing over almost all their coding to AI." Ultracode is built for exactly that kind of hand-off: tasks that benefit from parallel agents and adversarial verification before anything is committed.
What a Fan-Out Actually Buys: A Real Run
Abstract arguments about verification are easy to make. Here is what one run returned on a public codebase.
The setup: we are preparing a demo on the Excalidraw monorepo around a four-year-old feature request for native tables (325 reactions, 147 comments). Before building anything, we needed a yes-or-no answer to one narrow question: does any table feature already exist in Excalidraw, in the core element types or the public library? That preliminary check was run as an ultracode fan-out.
| Metric | Value |
|---|---|
| Agents | 5 (4 parallel searchers, 1 adjudicator) |
| Tokens | 471,480 |
| Wall clock | 264 seconds |
| Tool calls | 84 |
State that plainly: nearly half a million tokens and four and a half minutes for a pre-check, not the main task. At Opus 5.5 list prices the same token count costs 20% less than it did on Opus 5, and closer to 40% less once cache reads are counted, but it is still a half-million-token answer to a yes-or-no question. Now what came back, beyond the "no" that was asked for.
It refuted the source material's own technical proposal. The GitHub thread contains a contributor's 2023 proposal to implement tables as "a subtype of the frame element." The audit found that Excalidraw elements have no subtype mechanism at all. The one type that looks like one is derived at runtime from geometry and never persisted, and the element that looks like a frame variant is its own top-level type. A single-context run reading the thread would very likely have repeated the proposal as the implementation path.
It caught a defect in its own inputs. The checkout was a shallow clone with exactly one commit of history, which makes any git log question unanswerable. The agent said so explicitly instead of returning an empty result that would have read as "nothing found," then went to the GitHub API instead.
It found a better precedent than the one it was pointed at. A commit adding an entirely new element type had landed upstream two days earlier and was absent from the local checkout. That commit is a far better template for the work than the older examples the prompt named.
The verification layer corrected the searchers. The adjudicator noticed that one auditor's dissenting verdict was not a disagreement at all, since it was answering a different question. It flagged that a second auditor's claim was already stale because it came only from the behind-by-two local checkout. And it surfaced a consequence none of the four were asked about: the scene restore code is an exhaustive switch with a deliberate no-default policy, so any client predating a new element type silently drops those elements rather than degrading them.
That last finding is the argument for the pattern. The value was not four searches. It was a layer whose only job was to disbelieve the searches.
Use Cases Where Ultracode Makes Sense
The right question is not "could ultracode help here?" but "does the cost of getting this wrong exceed the cost of extra compute?" When the answer is yes, ultracode earns its token spend.
Codebase-wide audits. Checking 200 API routes for missing authentication, or scanning a repository for SQL injection exposure. A single-agent pass will miss things. Ultracode fans out parallel auditors, then runs a verification pass that adversarially reviews each finding before surfacing it.
Large-scale migrations. Renaming a pattern across 500 files, migrating from one ORM to another, or updating all usages of a deprecated API. Parallel agents working across file groups beat sequential single-agent work on both speed and consistency, and the verification layer catches the 10 files where the pattern was missed.
Multi-source research requiring cross-checking. The built-in /deep-research workflow is the model: fan out searches, fetch sources in parallel, then have separate agents check each other's conclusions before synthesis. For any research task where factual accuracy matters, the adversarial step is what changes the quality of the output.
Complex refactors where the architecture needs several angles. Redesigning a service boundary or extracting a shared module from tightly coupled code. One agent drafts the approach while another identifies the dependency implications before you commit to a plan.
Security reviews. Missing a single finding can cost far more than the compute for a thorough one. The verification step catches cases where the primary auditor made a plausible-but-wrong assumption, which is exactly what happened with the frame-subtype proposal above.
When Not to Use Ultracode
Ultracode is genuinely overkill for most daily work, and the token cost is real. The pre-check above spent 471k tokens on a yes-or-no question. A full audit with the toggle on can consume more of your plan's weekly rate limit than a full day of normal Claude Code usage, and the docs say so directly: a session with ultracode on reaches a session or weekly limit sooner than the same work with it off.
Routine single-file edits do not benefit from orchestration. Fixing a bug in one function, renaming a variable, explaining a block of code, writing a unit test for a known interface: none of these have the surface area that parallel agents improve. Quick questions are similarly poor fits; ten agents to answer what one search answers.
Any task where you need to interact mid-way is also a poor fit. Dynamic workflows cannot pause for user input once running. If you expect to redirect Claude partway through, a regular session where you guide the conversation turn by turn is the better tool.
Three more things to know before turning the toggle on.
The cost tripwire is off exactly when you need it. Claude Code normally warns when a run schedules more than 25 agents or projects past 1.5 million tokens. Per the docs, sessions with ultracode on do not show that warning, because turning it on already opts you into large runs. The concurrent-subagent limit is not enforced either, and in auto permission mode the first workflow launch is not confirmed.
One request can become several workflows in a row. With the toggle on, the docs describe one workflow to understand the code, one to make the change, one to verify. So the setting is not one fan-out, it is a chain of them. That, not the effort level, is where the cost lives.
Low effort does not make the fan-out cheap. Since the toggle no longer raises effort, it is tempting to run ultracode at low or medium and call it a bargain. The agents still each read their own context, and a chain of three workflows at medium is still a chain of three workflows. Lower effort trims the thinking inside each agent, not the number of agents.
Ultracode and Dynamic Workflows
All three routes lead to the same underlying system: dynamic workflows.
| Mechanism | How | Effort | Scope | Claude decides? |
|---|---|---|---|---|
ultracode keyword in prompt | Include the word in your prompt | unchanged | Per-prompt | No, always triggers |
| Ultracode toggle | /effort then Tab, or /effort ultracode on | unchanged | Whole session | Yes, Claude decides per task |
claude --effort ultracode | Launch flag | xhigh | Whole session | Yes, Claude decides per task |
The keyword gives you more control; the toggle gives you more automation and a chain of workflows per request.
The number of agents Claude aims for is governed by a size guideline. The default is medium, which since Claude Code 2.1.271 targets fewer than 10 agents (it was 15). small targets fewer than 5 and is the default on Pro plans, large fewer than 50, and unrestricted lets Claude size the run to the task. This is a guideline rather than a hard cap, and it can be changed in /config. If you are comparing runs, hold it fixed, because changing it mid-comparison silently changes the fleet size.
Workflows you find useful can be saved to .claude/workflows/ for project-scoped reuse or ~/.claude/workflows/ for personal cross-project use. Saved workflows become slash commands. The /workflows command opens a view of running workflows, where you can pause, restart individual agents, or stop a run entirely. Stopping mid-run halts token accumulation and preserves completed work.
How to Benchmark It Honestly
If you want to test ultracode against a plain session rather than take our word for it, three design mistakes will invalidate the result before you start.
Treat effort and ultracode as two separate variables. This got easier on September 28. Before, the setting changed both at once and you needed a fourth arm to untangle them. Now the two dials are independent, so the clean design is a 2 x 2 grid on the same model:
| Run | Effort | Ultracode |
|---|---|---|
| A | medium | off |
| B | medium | on (keyword or toggle) |
| C | xhigh | off |
| D | xhigh | on |
A against B isolates orchestration at the Opus 5.5 default. C against D isolates orchestration at high effort. A against C isolates effort. And C against B answers the skeptic who says the orchestrated run simply spent more tokens: if B beats C, structure won over spend.
Do not let the naive run inherit the research. A session that already did the fan-out holds the findings the plain run is supposed to fail to discover. Every arm needs a fresh session.
Report the token counts for every arm. Part of any orchestrated run's advantage is that it spends more. A write-up that hides this is easy to knock down. State the numbers and let the reader weigh them. Also state the model: an Opus 5.5 run and a Sonnet 5.5 run are not comparable on cost or on output.
Ultracode for Product Managers
Everything above applies outside engineering work. Ultracode does not care whether the task is code. It cares whether the task is big enough to justify parallel agents and adversarial verification, and a specific shape of PM work qualifies. It is the shape most PMs hit maybe once a week, not daily. The test: does answering this require reading across more sources than one context can hold, or is being wrong expensive? If neither, skip it.
Feedback synthesis at scale. 200 support tickets, 40 interview transcripts, six months of call notes. Ultracode fans out parallel readers by source, dedupes the pain points centrally, then runs a second pass that asks "what theme did we miss?" before ranking themes by frequency and severity, with quotes attached. This is the workload where a single context simply cannot hold the inputs.
Competitive teardowns. One agent per competitor per dimension (pricing, onboarding, positioning, changelog velocity), then a synthesis pass. Far better than sequentially reading eight sites and losing the first four by the time you reach the last. A verification agent re-checks every claim against the sources before the comparison reaches you.
Audits with a checklist. Every page against a rubric, every flow against a heuristic set, every event in the tracking plan against what actually fires in production. Rubric-times-inventory work is exactly what parallel agents plus a verification pass do better than one long session.
Decisions where you want to be confident, not fast. Generate four independent approaches to a problem from different angles (risk-first, MVP-first, user-first), score them with independent judges, then synthesize the winner. This beats one plan iterated three times, because the failure mode of solo reasoning is committing early to a frame.
Feature requests with a long thread behind them. The Excalidraw case above is a PM task. A 147-comment thread splits into two camps who want different products, contains a maintainer's stated position, and carries a technical proposal that turned out to be wrong. One context reads the title and writes a tidy generic spec. A fan-out reads all of it and tells you which proposal to distrust.
Where ultracode is waste for PM work: the writing itself. A PRD, a strategy memo, or a launch recap needs one coherent voice, not fifteen agents merging. Use the fan-out for the research beneath the document, then write the document in one pass. Same for anything where the bottleneck is your judgment rather than information volume.
One honest caveat. The failure mode is a PM who runs ultracode on everything and gets confident-sounding synthesis over shallow inputs. The value comes from the verification structure, agents actively trying to refute each finding, not from the parallelism itself. Learn the "when not to" half as hard as the "when to" half. None of this requires writing code: you describe the outcome, ultracode decides the orchestration.
Product manager and want to work like this? This is exactly what we teach in Claude Code for PMs, our live cohort for product teams: 3 live sessions of 90 minutes over 2 weeks. Every PM ships a real feature, builds their own agent, and gets personalized written feedback.
Ultracode on Opus 5.5: Questions People Are Asking
Does ultracode work on Opus 5.5? Yes. Ultracode is available on any model that supports xhigh effort, and Opus 5.5 does. Since Claude Code 2.1.280 it is the default Opus model, so if you have not pinned a model, your ultracode runs are already on it.
Was ultracode removed from Opus 5.5? No, but it moved. Until September 28, ultracode sat at the far end of the /effort slider, past max. In Claude Code 2.1.284 it became a separate toggle: open /effort, press Tab to switch it on or off, then Enter. If your slider now stops at max and you cannot find ultracode, that is the change, not a removal. The model pill shows "· Ultracode" when it is on.
Ultracode vs max effort on Opus 5.5: which is "more"? They are different axes. max is the deepest single-context reasoning the model offers. Ultracode is orchestration: more agents, each with its own context, plus a verification pass. You can combine them (/effort max, then Tab for ultracode), but for most audits xhigh with ultracode on is the better trade, and medium with ultracode on is a reasonable default for migrations where the per-file reasoning is shallow.
Does ultracode work on Sonnet 5.5? Yes. Sonnet 5.5 supports xhigh, so the toggle appears for it. Claude Code runs each workflow agent on your session's model unless the script names another, so a Sonnet 5.5 session fans out Sonnet 5.5 agents at $2 and $10 per million tokens instead of Opus 5.5's $4 and $20. Independent testing found Sonnet 5.5 uses noticeably more output tokens per task to reach similar results, so the saving is smaller than the list price suggests. Our Opus 5.5 vs Sonnet 5.5 in Claude Code guide goes through that trade-off.
What does an ultracode run cost on Opus 5.5? The same number of tokens as before, at lower rates. The 471,480-token pre-check above would bill about 20% less on list input and output prices than on Opus 5, and the cache-read cut (from $0.50 to $0.20 per million) matters more in a fan-out, where agents reread the same repository context. Anthropic's 40% typical-workload figure is the right mental model. The run is still the run, though: nothing about Opus 5.5 reduces the agent count.
Which effort level should I pair with ultracode on Opus 5.5? Start where the model starts, at medium, for bug sweeps and migrations. Raise to xhigh for security reviews, research with cross-checking, and anything where a wrong finding is expensive. Set effort first, then flip the toggle, and check /effort before every large run since the two no longer move together.
Closing Thoughts
Ultracode is not a setting to leave on. It is a mode you reach for when missing something is more expensive than the compute required to be thorough: large audits, complex migrations, adversarial research, security reviews, and any question whose inputs do not fit in one context.
Know which ultracode you are using, and know which effort level you are running at, because since September 28 those are two separate decisions. The keyword buys structure for one task. The toggle buys structure for every task, and chains workflows per request. Opus 5.5 makes each of those runs cheaper and faster, not smaller. For everything else, Opus 5.5 at medium or high effort delivers strong results at a fraction of the cost. The discipline of switching intentionally is what makes ultracode useful rather than just expensive.
