Parallel fan-out

Race one task across up to four agents in isolated git worktrees, compare the finished diffs, and keep the winner.

Some tasks are a coin flip. The approach matters more than the execution, you can't tell which approach is right by reasoning about it, and one agent's answer tells you nothing about whether a better one existed.

Fan-out runs the same task several times in parallel, in isolation, and lets you compare finished work instead of guessing up front.

What it does

Run in parallel takes one prompt and starts up to four independent sessions from it. Each lane gets its own fresh git worktree on a branch named foreman/fanout/<slug>-<stamp>/N. Nothing is shared between them: no context, no working tree, no chance of two agents editing the same file.

Four is a hard cap, enforced in the controller rather than only in the UI. It exists to keep a burst polite to your account — a fan-out is the easiest way to accidentally look like abuse to a rate limiter.

Requirements

The project must be a git repository. Lanes are isolated worktrees, and there is no worktree without git — Foreman will tell you rather than silently degrading to shared-directory chaos.

Setting up a run

  • Lanes — how many parallel attempts, up to four.
  • Agent & permissions — which CLI each lane uses and how much autonomy it gets.
  • Run on — subscription or API key. Fan-out defaults to the API key, because four concurrent lanes is exactly the shape that eats a subscription's limits.

Vary the model or the effort per lane. This is the part people skip and shouldn't: four lanes on identical settings is rolling the same dice four times. Four lanes across different models, or different effort levels, is actually testing approaches.

If the project has a setup script configured, every fresh worktree runs it before the agent starts — dependencies, env, ports — so lanes boot ready to work rather than failing four times in parallel on a missing node_modules.

Comparing and keeping

When lanes finish, Compare lanes puts the diffs side by side. You can also run an AI judge over them, which returns a one-sentence assessment per lane — useful as a first read, not as the decision.

Keep branch takes the winner. What happens to the others is the part worth knowing:

Losing lanes are folded away, not deleted. They collapse behind a counter so the canvas stays readable, and their branches and worktrees stay where they are. "Actually, the second one was right" is a click, not a re-run.

This is deliberate. The value of racing four attempts collapses if choosing one destroys the other three — you'd be back to a single answer, just having paid four times for it.

When to use it

Worth the cost:

  • Architectural decisions where you'd like to see two designs before committing to one.
  • Bugs where the cause is genuinely unclear and different agents will chase different theories.
  • Anything you've already asked one agent to do twice without a good result.

Not worth it:

  • Mechanical work with one obvious correct answer. Four identical diffs is four times the spend for no information.
  • Anything touching files outside the repo — worktree isolation doesn't cover those, so lanes can still collide there.

Cost

Four lanes cost roughly four times one session, and you keep one. That is the trade: you are buying information about the solution space, not throughput. Per-lane spend shows live on each card, and the fan-out's total is on the group.

Parallel fan-out — Foreman docs