AIDiveIntro: same checks, twice the meter, five caps
Ultracode is the keyword, or the toggle, that turns one request you type into Claude Code into a whole team of agents. On a paired test with the same spec, both runs passed the same hidden checks, and the ultracode run took more than twice the session meter. The reason is not a smarter model: it is one sentence the harness injects and three guards it switches off.
This article covers four things:
- the paired test, read on the plan meter;
- the token multiplier across several more pairs;
- the one kind of job where a team found 66 planted bugs while a single agent found 14;
- the five settings that cap a run before it eats your week, one of which stops it at the usage limit itself.
What ultracode switches on: the keyword, the toggle, a workflow of agents
Ultracode is two switches. Typing ultracode inside one prompt runs that single task as a workflow without touching the session's effort level. Flipping the toggle through the /effort command makes Claude plan a workflow for every substantive task, so one request can turn into several workflows in a row.
A workflow is a script Claude writes for itself; that script runs a team of agents in phases. On a tiny sandbox (a couple of files with sloppy promise handling, read-only review requested), Claude scouted the files, fanned out a workflow it named "unhandled promise audit", and a task row appeared under the prompt box with a progress bar, the agent count, the elapsed time and a ticking token total. The /workflows command lists one row per agent with its own token count, plus keys to pause, stop or restart.
On that run, each finder had read about 45,000 tokens before the verifiers even started, for a handful of lines of code.
Every session also carries a size guideline, the agent count Claude is advised to stay under:
| Size guideline | Agents advised |
|---|---|
| small (default on Pro) | fewer than 5 |
| medium | fewer than 10 |
Every agent sends its own requests on top of your conversation. A workflow is never one bill; it is one bill per agent, and the meter counts every one of them.
The paired test: same 136 checks, 8 percent against 18, and it never stops
A developer measured the cost on the top subscription plan with a clean setup: the same spec for a small spreadsheet app, the same model at the same effort, one plain run and one ultracode run. Both were scored by hidden checks, tests the model never sees. Both passed all 136.
| Run | Finished | Session limit used | Checks passed |
|---|---|---|---|
| Plain | on its own, 25 min | 8 % | 136 / 136 |
| Ultracode | cut off by the clock at 76 min, still checking | 18 % | 136 / 136 |
Inside the ultracode run, Claude wrote a script whose only job was to run a team: 12 agents counted, testers, a few judges, and later some "breakers" whose job was to break the page. One breaker did find a real bug in the formula bar, which kept showing the old text after clicking another cell.
Per minute, the ultracode run used the limit about as fast as the plain run, on average a little slower. It did not burn faster; it did not stop. Ultracode does not make Claude smarter, it makes Claude check, and you pay for every check. This is one pair on a small spec, and the second run was cut by a clock, but the shape is clear: same answer, more than twice the session window, and the extra time was all checking.
Why it costs: one sentence and three guards switched off
The model is the same. What changes is the text the harness hands it; the harness is Claude Code itself, its tools and the instructions around the model.
When ultracode is on, Claude Code loads a reference before writing any workflow. That text tells the model to run a workflow for every substantive task by default, and it contains the sentence that explains the bill: "The goal is the most exhaustive, correct answer you can produce, and token cost is not a constraint." That is the harness's own text, and a public GitHub issue quotes the same lines.
Three guards go off at the same time:
- The large workflow warning, which normally fires when a run schedules too many agents, does not appear.
- The session's limit on how many agents may run at once is not enforced for the agents Claude spawns.
- In auto mode, the first launch is never submitted for approval.
The size guideline is advice, not a cap: set to small (fewer than 5 agents) on the sandbox, the ultracode run still spawned 9. To be fair, the sentence is a default the model can still weigh, and the guards are dropped on purpose for very large jobs. The answer fits in one line: ultracode does not change the model, it changes the instructions to "a team for everything, and cost is not a constraint".
The multiplier: three pairs, the effort ladder, the 30x pair
A second developer ran several single-agent against workflow pairs on the Pro plan, review-style scripts, reading the usage meter before and after each one.
| Measure | Single agent | Workflow |
|---|---|---|
| Tokens on one review script | about 115,000 | 972,000 |
| Token multiplier across the pairs | 1x | up to 18x, for roughly the same findings |
| Meter movement | 1x | up to 3x |
| Wall time | almost identical | almost identical |
The workflow did not finish faster; it spent more while you waited the same. The one place parallel paid was a batch of independent research jobs, where the agents finished faster, still for more than twice the tokens.
A third test built a few small apps at every effort level at API prices. Each step up the ladder roughly doubled the bill, and ultracode landed at several times what max cost without ever coming out on top. Most of those tokens were cache reads, the cheap ones; the tiny slice of output tokens made up nearly half the cost.
One more pair, a city scene: a single agent took about an hour for a few dollars of API price. The ultracode run took most of a day, dozens of subagents, and about 30 times the cost.
These are whole-number meter readings, greenfield apps at API prices and one city scene, so none of them is a scoreboard on its own. Together the pattern is the same every time: the fan-out buys checking and coverage, not a better answer, unless the job splits into independent pieces.
Where the fan-out pays: a test suite as the judge, and the one-line rule
Some jobs really are this shape: a migration, an audit, a sweep across a codebase.
Bun was rewritten from Zig to Rust with about 50 dynamic workflows in Claude Code, running continuously for 11 days. That is over half a million lines of Zig, from start to the whole test suite passing on every platform in those same days. What made it work was not the agent count but the judge: a huge existing test suite said pass or fail without anyone's opinion.
Anthropic's bug hunt shows the same thing. Seventy bugs were planted in a large codebase and a single agent ran several times.
| Agent | Bugs found out of 70 |
|---|---|
| Single agent (3 runs) | 14, 15, 27 |
| Workflow (3 runs) | 66 every run |
One caveat: that test ran on Claude Managed Agents, the API product, not Claude Code, and no cost was given.
The launch thread adds the other reported wins, and they all look alike: review against a rule file, translate a whole codebase, clean up a pile of scanned pages. The launch blog says it plainly: most traditional coding tasks do not need a panel of five reviewers.
The rule: fan out only when a test suite or a rule set judges the output, and the job splits into independent pieces. Everything else runs plain, at high. The paired tester said the same in his own words: save it for jobs where the checking is the work, like a migration across hundreds of files.
Five settings that cap a run
Each cap sits in a place you already know.
| # | Setting | Where | Effect |
|---|---|---|---|
| 1 | workflowSizeGuideline: "small" |
/config under Dynamic workflow size, or settings.json |
advice (fewer than 5 agents), also lowers the large workflow warning threshold |
| 2 | CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS |
environment variable, exported before launch | default up to 16 agents at once; set to 4 and the rest queue, slowing the burn without killing the run |
| 3 | CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL |
environment variable | runs every workflow agent on one model you choose while other subagents keep theirs; a cheaper model makes the checking cheaper |
| 4 | the ultracode keyword, never the toggle |
in the prompt; never the ultracode key in settings |
the keyword runs one task as a workflow and stops; the toggle makes it standing until switched off |
| 5 | autoContinueAtUsageLimit |
settings | on: a run that hits the limit pauses, waits for the reset and carries on, more than once; off: the agents fail at the wall and the run ends there |
Three habits go with them. The launch blog says a budget written in the prompt, like "use 10k tokens", sets the cap. After any run, /usage shows how much of recent usage went to subagents and workflows, with a warning when they dominate. If a run looks wrong while it is going, the /workflows pane and the x key stop it, and the work already done is usually kept.
None of this makes an agent cheaper. It caps how many agents a run can spend, and how long it can keep spending.
The runaway run, the limits, and the verdict
One public report shows how a week disappears. A model-written script on the biggest plan started 221 agents in under an hour. After the first session-limit error the script kept dispatching, and 189 more agents started in the next few minutes. The filer's own table counts tens of millions of tokens across the phases before the wall.
| Phase | Tokens, cache included |
|---|---|
| Ground | 11,063,801 |
| Find | 35,885,272 |
| Merge | 516,226 |
| Total | 47,465,299 |
The culprit was one line in the generated script, a fallback that said: if the agent returned nothing, use the raw list and carry on. The merge failed and the run kept going. That version predates the pause at the usage limit, and the filer says those tokens were not from the failed agents. A concurrency ceiling would have thinned that run, and auto-continue off would have ended it at the wall.
The verdict: on the same task, with the same checks passed, ultracode took more than twice the meter of a plain run. Not because it is smarter, but because of the injected sentence and the guards it drops. It pays when a test suite or a rule set judges the output and the pieces do not wait on each other. Everywhere else, you type it and you pay for checking. Five settings cap what a run can spend: the size guideline, the concurrency ceiling, the workflow model, the keyword over the toggle, and the stop at the limit.
