Ultracode · for people who already build with Claude

Claude can now run a team of itself.

Ultracode is the setting that shipped in Claude Code alongside Opus 4.8. Flip it on and a single request can fan out into hundreds of Claudes working in parallel — then checking each other before anything reaches you.

You already know how to drive Claude. This is about a new gear: when to let it orchestrate, what it can now finish that it couldn’t before, and what that costs.

Sub-agents on a single task 1,000 up to — written, run, and reconciled by Claude itself

The frame

What it is, in one sentence.

Ultracode turns Claude from one assistant working in order into a manager that splits a job across many copies of itself, has them check each other’s work, and hands you the reconciled result.

You drive the same way you always have. What changes is how much one prompt can take on.

What it means · 1 of 4

A setting, not a model.

Ultracode lives in Claude Code’s effort menu. Turning it on does two things at once.

1 · Maximum reasoning

Effort pinned to xhigh — the deepest thinking level — on every request.

2 · Auto-orchestration

Claude splits a big task across parallel sub-agents on its own.

You don’t have to flip the switch. Type the word workflow anywhere in a prompt and Claude orchestrates that one task. Ultracode just makes that the default for everything substantial.

What it means · 2 of 4

One prompt, many Claudes.

What actually happens when a workflow fires.

Ultracode Off

Flip the switch. Coverage and tokens are shown relative — the trade ultracode makes is more of both.

A script Claude writes itself coordinates the run. The agents attack from independent angles, then try to refute each other; the run iterates until the answers converge — reaching results a single pass can’t. On a codebase, your test suite is the bar for “done.”

What it means · 3 of 4

Built for engineer-weeks.

Where the fan-out earns its keep: big, parallelizable jobs with a clear bar for “correct.”

Migrations & ports

Framework swaps, API deprecations, language ports spanning thousands of files — carried to a merge.

Codebase audits

Whole-service reads — quality, dead code, consistency — in one pass instead of file by file.

Bug & security hunts

Many agents probe from different angles and try to refute each finding — fewer false alarms.

Optimization sweeps

Profiler-guided audits across a whole codebase, with the test suite holding the line on correctness.

The common thread: a job too big for one pass, where the answer can be checked. That’s exactly what the refute-and-converge loop is for.

What it means · 4 of 4

You won’t migrate a codebase. Here’s your version.

Run it yourself or hand it to your team. Either way, here are three jobs — each one a pile of inputs, a workflow, and a checked answer.

Make sense of a data dump.

Point it at four years of attendance or discipline data — it cleans, cross-checks, and hands back the anomalies in plain English.

Synthesize the stack.

Thirty board policies and three reports become one reconciled brief — every claim traceable to its source.

Pressure-test a decision.

Give it a proposal; agents argue both sides and try to refute each other, so the risks surface before the board does.

Relevance, plainly: the unit of work changes. One person can take on a job that used to need a team — and the model checks its own work against the bar you set. Whether you run it or your team does, that’s the shift worth planning a year around.

The receipts

The scale, in numbers.

How much one prompt can mobilize when ultracode is on.

Tens to hundreds run on a typical job, and one request can chain up to three workflows — understand → change → verify. Each agent gets its own context, so the script, not the window, is the limit.

Before you turn it on

It burns a lot of tokens.

The one honest caveat — and it’s a big one.

data_usage

Heads up · cost & speed

With ultracode on, a single request can spawn several workflows in a row, each running many agents. It uses substantially more tokens and takes longer than a normal session — the speed and cost of a session now swing on one switch, not just the model behind it.

Treat it like heavy machinery: scope the first runs, watch your usage, and reach for it when the job is genuinely large and verifiable — not for a quick edit or a back-and-forth chat, where it’s pure overhead.

Judgment call

When to reach for it — and when not.

The switch is free; the run isn’t. Match it to the job.

Rule of thumb: if you’d hand it to a team and check their work at the end, it’s a workflow. If you’d just do it yourself in five minutes, it isn’t.

The close

Turning it on, carefully.

Two ways in — and a sane way to start.

toggle_on

Heads up · is it already on?

On Max and Team plans (and through the API) ultracode is on by default; Enterprise needs an admin to enable it. Reports differ — so check your own effort menu before you assume either way.

Find the switch.

It’s in Claude Code’s effort menu — one level past xhigh.

Or just say “workflow.”

Drop workflow into any prompt to orchestrate one task.

Start scoped.

Point the first run at one job — and watch the spend.

Try this first

“Use a workflow to audit this repo for security issues. Have independent agents verify each finding before you report it.”

The close

Where this came from.

Everything here traces to Anthropic’s own announcement and the Claude Code documentation.

The announcement

Dynamic Workflows in Claude Code

Anthropic’s post on what shipped — the source for the orchestrator, the 1,000-agent cap, and the refute-and-converge loop.

Read it arrow_outward

The setting

Claude Code docs

Where ultracode lives in the effort menu, plan availability, and how workflows are scripted and run.

Open the docs arrow_outward

For the room

Bring it to your team.

Which of your big, checkable jobs — a migration, an audit — is worth a scoped first workflow run? Start there, and watch the spend.

Discussion forum