Claude Code has a keyword that turns one prompt into a team. Type ultracode and Claude writes a small program that sends many agents out in parallel to read and cross-check your material, then brings their results back to you. Add a coordinator session that starts and runs other sessions, and one chat can drive a project ten sessions wide. Below I explain when it pays off and how to prompt it, then how to grow from one workflow to a team of sessions, with one of my projects as the running example.
FT-4 is my attempt to fine-tune Qwen3.5-9B with LoRA and GRPO (a reinforcement learning method) into a personal assistant that uses my memory system well. One goal is a small model anyone can run, so I test it at 4 bits on my own GTX 1070 Ti, an 8 GB card several generations old. Before paying for training GPUs, I wanted the plan attacked as hard as possible.
I gave that job to one Claude Code session with ultracode on and asked it to play devil's advocate. Within two hours it returned "GO WITH CHANGES" and ten blockers. In about 45 hours, overnight stop included, it ran four workflows and started nine sessions (one of which started a tenth), while I typed about 20 turns, most of them "yes" or "resume". Two findings changed the project: the training script would have given every answer a reward of zero, and my untrained harness (the code that saves each turn to memory and makes the model search before answering) already scored inside the range predicted for the trained model.
The coordinator, "FT-4 red team review", with the sessions it started nested under it in the Claude Code desktop sidebar.
What ultracode does
Put the word ultracode in a prompt you type and that turn becomes multi-agent orchestration (docs). Claude writes a workflow script and runs it, and the script fans out subagents with the roles the task needs, such as parallel readers or skeptics. Their results come back to your chat. /effort ultracode keeps it on for the whole session, and Claude then decides which tasks deserve a workflow; /workflows lists the runs in progress and finished. My coordinator ran Opus 5.5 at xhigh effort with ultracode on throughout, and every substantive task got a workflow.
The coordinator half needs no keyword. Sessions in the desktop app can find and message each other (docs; v2.1.234 or later on native Windows), and Claude makes those calls itself, so I never typed a tool name. In my run the coordinator went further: it started new sessions, wrote each one's brief, and got a short note every time one of them finished a turn. The children appeared nested under it in the sidebar, as in the screenshot above, a layout I have not found documented.
When to use it
Ultracode pays off in three situations. The material is too large for one context but splits cleanly, so each reader can take a part. The claims deserve agents whose only job is to disagree. Or a missing step would cost real money, such as a day of rented GPU. FT-4 had all three: records, harness code, memos, run files and papers to read, a plan full of predictions to attack, and a training rental I had not yet paid for.
Size the workflow to the question. The Dynamic workflow size row in /config tells Claude how big to aim (medium by default, meaning under 10 agents, and Claude may go past it), and a "Large workflow" warning appears above 25 agents or a projected 1.5 million tokens. My first review had to read everything and used 17 agents. The question of which GPU to rent needed only three, and they ranked a single H200 first, because training runs on one GPU and GRPO memory decides the choice.
Skip it for a one-line fix, or when you already know the answer and only the typing is left: every subagent spends its own context, so a workflow costs far more than one careful turn. The keyword does not fire in -p runs, and Alt+W (Option+W on macOS) dismisses it for one prompt, which helps when the word appears in your text for another reason.
How to prompt a workflow
Tell it what failure looks like. Agents find what you tell them to look for, and "review this plan" names nothing. My brief asked what would void, confound or weaken the result, whether a cheaper route reached the same goal, and what the 2025 to 2026 primary sources said. Seven minutes into the first workflow, read-only readers had found my untrained harness already inside the predicted range, and a scorer that had been changed after its results came in.
Give the agents roles, and make some of them skeptics. In my run Claude chose the roles itself: readers that could only read, agents that read the full text of papers rather than abstracts, and verifiers told to refute by default. You can ask for any of these by name. The second workflow sent ten skeptics, one per group of claims, each told "Your job is to REFUTE them if you can." They confirmed that no GRPO reward code existed for FT-4, which is how I learned about the zero reward before spending any GPU time.
Claude writes this script for you. Below is pseudocode for the shape of my verify pass. The function names (phase, parallel, agent, log, the args global) and the schema option, which makes an agent return JSON instead of prose, come from the docs; the exact signatures here are my approximation.
// Pseudocode: the shape of my verify pass, not the real script.
phase("Verify");
const verdicts = await parallel(
args.claimClusters.map((cluster) => () =>
agent(
`You are a skeptic. Claims from a red-team review:\n${cluster}\n` +
`Your job is to REFUTE them if you can. Read the cited files yourself.`,
{
schema: {
type: "object",
properties: {
verdict: { enum: ["confirmed", "refuted", "partly"] },
evidence: { type: "string" },
},
required: ["verdict", "evidence"],
},
}
)
)
);
phase("Critic");
const missed = await agent(
`Compare this review against the brief. List what it did not cover.`
);
log(`${verdicts.length} verdicts in, critic done`);
return { verdicts, missed };
With a schema, each skeptic returns a verdict field, and the coordinator can merge the answers without parsing prose.
End with a completeness critic: one agent that compares the result against your brief and lists what nobody was asked to check. In my second workflow the critic read the review against my brief, and the final report came out with ten blockers, 27 findings and five experiments. A later planning workflow, with a critic before its final revision, corrected 26 claims, added 18 missing items and left me five decisions only I could make.
Stop when you need to and resume later, because a paused workflow keeps the work of every agent that finished. My planning workflow was half done when I typed, verbatim, "stop we resume tomorrow". The next morning I typed "resume", and only one check and the final revision ran again; the readers and the synthesis came from cache. You can resume from /workflows by selecting the run and pressing p, or by asking Claude to relaunch it, as long as you stay in the same session.
From one workflow to a coordinator
When the findings outgrow one chat, turn each slice into its own session, with a brief a fresh session can act on. A good brief names the findings to read first, the deliverables, the files the session must not touch, and who owns each dependency. After the review I typed one line asking for separate sessions on all the issues. In eight minutes the coordinator started eight sessions, wrote every brief itself, and posted a table mapping each session to the blockers it covered.
Give every shared file one writer at a time. Eight of my sessions worked in the same checkout without worktrees, so before starting them the coordinator agreed a file ownership list with the session that held the busiest files. From then on the sessions handled it among themselves. The harness session asked the scorer session to "Reply 'released' or name the part still yours", and got the file back with the rules it had to keep. When a third session sent five change requests for that file, the scorer session forwarded them "so one writer holds the file". The one session working in a different repository used its own worktree.
Let the coordinator relay, and ask for status in one fixed format. My part shrank to short answers, which the coordinator carried word for word to the right session. When I typed "where we are", it sent nine identical requests for replies under 200 words in four parts (done, missing, decisions for me, running) and merged them into one list showing what blocked what. It also caught stalls: one session had sat idle for 90 minutes with promised work unbuilt, and it delivered eleven minutes after one nudge.
Give each paid resource one holder at a time. My sessions shared GPUs rented on vast.ai, my VPS and my own card. When the first rental, an RTX 5090, finished its experiment, I told the coordinator, verbatim, "send a message to other session: one of them need the gpu, so we don't waste money". It offered the card to seven sessions, and the training pipeline session ran two jobs on it before I let the rental go. A second rental served experiments from a queue. Each job started only when the previous run's report said it had passed, because the report file exists even after a failure, so finding the file proved nothing. While a GPU was busy, the coordinator gave idle sessions work that added no spend.
Keep money decisions with you, behind a hard cap. All API spend went through one OpenRouter key capped at USD 50, which I created and topped up myself; the sessions could ask for it but not create it. The overnight queue on my VPS ran its last experiment only if the key still held at least USD 9. Spending approvals did not travel between sessions either. One session refused to run an experiment on my yes relayed by a peer, and the coordinator told me two sessions needed the go-ahead typed in their own chat. That cost me a few chat switches, and I want it that way: a session that spends my money hears the yes from me.
What to expect
The first thing to expect is decisions that hold up. Two days after the first workflow, a run on a rented GPU confirmed its untrained harness finding: a harness with no training "already matches the trained band on every reading and search metric". That leaves one place where training can still add value, namely what the model decides to save into memory, and I learned it before paying for any training.
The sessions also built things. In two days they produced a scorer and reward module whose 189 new test cases each failed under at least one deliberate break of the code, a new simulated world of users with sealed test splits, and a fix for 4-bit serving. One session started a session of its own to make an experiment's runs replay exactly. When a network error stopped the coordinator and two children at once, I typed "Riprova" (retry), and each session checked what had already finished before redoing anything. The target stayed the same small card throughout: once the rentals were done, the last model fit ran on my GTX 1070 Ti.
When one session is enough
Skip the coordinator when the task fits in one session, or when you cannot review results as fast as ten sessions produce them; I was the only approver for all of them. I did not measure token spend, so I cannot give you a cost figure. On a long run the coordinator's own context fills up: mine ran out on day two and carried on from a summary.
A first step
Pick one plan you are about to act on, such as a design or a pre-registration, and type something like ultracode: try to refute this plan, one skeptic per claim, refute by default, read-only.
Top comments (0)