/ultracode

/ultracode is a switch, not a job. Turn it on, and the model in this chat may split a large task across several agents, with two checkers reviewing each part. It decides when. Short questions still get a short answer.

Type it the same way

/ultracode         on for this chat
/ultracode <task>  on, plus the task
/ultracode off     off

The word ultracode in a message does not switch anything on for good. It lets the model use the workflow tools for that one turn, and the model decides whether the task fits. If not, it works directly and says why. "No ultracode" or "what is ultracode?" gives no permission. For small mechanical parts see sub-agents. /swarm <task> skips the decision and starts a workflow right away; your account needs the swarm permission for that. In the terminal client, /ultracode-jetzt <task> does the same.

How an /ultracode workflow runsWith /ultracode on, the model decides whether a task is worth splitting. A planner divides it into two to six independent parts. Each part runs in parallel: an agent does the work in your container, two checkers look for errors and for gaps without writing files, and a fixer runs only if a checker objected. A summary agent then reports to the chat and states the review status of each part.Each part, in parallel (8 at once by default)Agent does the workin your containerChecker 1looks for errorsChecker 2looks for gapsFixer, only ifa checker objected/ultracode is on for this chatThe model decides whethera workflow pays offPlanner splits the taskinto 2 to 6 independent partsSummary agent reportsto the chat, with thereview status of each part
A part is worked, checked by two reviewers and fixed once if they object; a summary agent then reports with the review status of every part.
Diagram as text
  1. /ultracode is switched on for the chat. This is a switch, not a job.
  2. The model decides whether a workflow pays off. A short question gets a short answer.
  3. A planner splits the task into 2 to 6 independent parts.
  4. Each part runs in parallel, 8 at a time by default.
  5. An agent does the work of the part in your container.
  6. Two checkers then try to refute it. One looks for factual or logical errors, the other for missing or half-done work. They can read files and run commands such as tests, but not write.
  7. If a checker objected, a fixer repairs the flagged defects once. The fixed part is not checked again, and its review status says it changed after review.
  8. A summary agent reports to the chat which files changed and how to verify them, and states the review status of every part.

Fan-out

It fans out

The task is decomposed and the parts run in parallel rather than one after another. Breadth costs wall-clock time once instead of once per part.

One after another

In parallel

Wall-clock

Both bands carry the same parts and the same work. Only the arrangement differs.

Refutation

It reviews adversarially

Each part gets two checkers. Their job is to find what is wrong with the files an agent changed, not with its summary.

The checkers can read files and run commands such as tests, but they cannot write. One looks only for factual or logical errors, the other only for parts that are missing or half-done.

A fixer then repairs the flagged defects once. That fix is not reviewed again: the part is marked as changed after review, and the summary says so. The summary also reports parts where a checker could not answer. A finished workflow does not by itself show that tests passed.

Card

A card tracks it in the chat

While it runs, a card appears with the plan and one line per agent. The arrow on a line opens its log.

The plan
What the model gave each agent, in its own words
Per agent
NameStateA running clock
The log
The task it was givenEvery tool callWhat it wrote back

The card streams from the server. Reload, switch devices or close the tab: it picks up where the run is, and the model waits for the result before it answers you.

Status

A status line shows the work

While a run is active, one fixed line above the message box shows what the agents do: one count (for example 2 of 6 agents active), the stage, the clock and the cost. Open, it lists the agents with their live log. Errors stay visible when the line is closed.

The agents follow the approval setting of your chat. A request shows up in that line with Allow, Deny and Allow for this run. Details: approvals and status line.

Files attached to the chat go into the brief of the planner and the agents. A file that is too large for the prompt appears as an outline, its first lines and its path in the container. Images are named in the brief but not described, because the planning models read text only. Only files from your own chat are used.

With your own key you can choose the checking model: helper and checking models. Stop pauses the jobs of the chat and the card shows Resume: Stop button.

Cost

It costs more

Several models on one task is several bills. Use it when being wrong is expensive, and /goal the rest of the time.

/ultracode
Audits Migrations Reviews before a release
/swarm
Skip the decision, start right away
/goal
The rest of the time

Ceilings

The ceilings still apply

It obeys the same ceilings as any other job: your plan's run time, the budget governor and a spend cap if the model sets one.

Every lane

One bar, drawn across every lane at once. Fanning out buys no exemption from it.

It needs a paid plan: on the Free plan the switch is not available. The model starts a workflow only while the switch is on for the chat.

Agents use models available to your account. If a model cannot run, follow the message in chat or choose another model from your picker.

Several agents on one task mean several model bills. Credit and plan prices: Pricing; limits: Limits.

Overview of unattended runs and what limits them: /goal and /ultracode.

For a continuing finish condition use /goal. See unattended runs and spend limits before delegating long work.