How Do I Get More Out of Orca's Parallel Orchestration?

Last updated: 2026-10-25

Orca is a free, open-source desktop app from Stably AI that calls itself an ADE, an Agent Development Environment. It puts command-line coding agents such as Claude Code, Codex, OpenCode, and Pi into one window, giving each agent its own isolated git worktree so several agents can work on the same task in parallel. This guide skips the basics of installing and opening worktrees and focuses on the advanced game: writing prompts that suit comparison, setting acceptance bars, mixing agents, running annotation rounds, and picking a winner without going by feel.

How do I write prompts that suit multi-agent comparison?

Comparison starts before comparison, in the prompt. What the goal is, where the scope ends, and which files must not be touched all belong in the prompt, so several agents can race in the same direction. A vague prompt produces answers pointing in different directions, and comparing them turns into extra work: you think you are picking the best, but you are actually picking a direction, and a pick means nothing when the directions never lined up. Racing and splitting also need different prompt shapes: racing sends the same prompt to several agents to see several approaches, while splitting gives each worktree its own task description for its own slice. Decide first whether this round is a race or a split, then write, because comparison only means something once the direction lines up.

When should I set the acceptance bar?

Before looking at results. The bar needs at least two items: whether the change does what you asked and whether the logic holds together, and merging happens only once the bar is met, otherwise revision continues. A late bar causes trouble: once several answers have been seen, the bar quietly bends toward the most pleasing one, and the pick becomes a first impression rather than the best result. Write the bar down instead of keeping it in your head: a written bar can be checked item by item, while a mental bar shifts after one look around. With the bar set, comparison turns from going by feel into ticking boxes, and the pick stands up afterwards.

Which tasks suit racing, and which suit splitting?

Racing suits moments of uncertainty: when you want to see several approaches first, when you want to know how different agents would solve the same problem, and when the task is exploratory. Splitting suits tasks that divide cleanly: chains that are clear, slices with sharp boundaries, and execution work, where different worktrees take different slices without interfering. A mixed shape also works: race first to settle direction, then split to go deep, taking one stretch of exploration and one stretch of execution. Choose by the nature of the task before falling back on habit: a racing habit applied to execution work opens full parallelism, spends extra usage, and buys no extra information.

How do I mix agents?

A mix matters because viewpoints differ, not because one agent is necessarily better. Running the same task with a different mix usually produces different results, and that difference is exactly what comparison is worth. Do not trust a fixed combination: when the task changes, the fitting mix changes too, and running one fixed mix on every task hands the choice back to habit. The steadier way is to tune by task: more viewpoints for exploratory work, and slices matched to their nature for split work. After a mix runs, write one note down: what the task was, which mix ran, and how it turned out, so the next similar task reuses it directly, which is how experience accumulates.

How many annotation rounds are right?

There is no fixed number, and the rule is to revise until the acceptance bar is met. When the first round misses the mark, write the objection on the diff line and send it back, then compare again until one result is worth merging. If many rounds pass without settling, the problem usually sits outside the annotations, in a prompt or a bar that was never written clearly: a vague prompt never lines up direction no matter how many rounds run, and an unset bar never says when the work counts as done. At that point, stop and fix the prompt and the bar, which beats circling inside annotations. Annotations are a polishing tool, not a safety net, and rounds stay short once direction and bar are right.

How do I pick a winner without going by feel?

Set the bar first, then look at answers, and never reverse that order. With the bar set, check item by item: whether the change does what was asked, whether the logic holds together, and whether the scope stayed inside its bounds, one item at a time. Do not pick by first impression, and do not pick by length: the longer answer is not necessarily right, and the pleasing answer does not necessarily meet the bar. After picking, glance once more at the discarded ones: whether every discard traces back to the bar rather than to personal taste. Keep the pick on record, bar plus checks plus result together, so the next similar task picks faster, and so a bad pick can be traced back to the step where it went wrong.

How do I keep what each round teaches?

Every round deserves one note: what kind of task it was, which mix ran, how the prompt was written, what the bar looked like, which answer won, and why it won. Notes get reused directly: when a similar task arrives, prompt and bar do not start from scratch, and the mix does not need re-testing. Once enough notes pile up, a personal playbook takes shape: which tasks race, which tasks split, and which mixes fit which kinds of work, all backed by records. Experience that is never written down counts as never gained, and the next similar task starts from scratch again, so parallelism just pays the same tuition twice. A review does not need to be long, a few lines will do, and the point is writing it every time.

What are the common advanced mistakes?

The first is opening full parallelism on every small task: usage and review time rise together while the information gained barely moves. The second is racing on a vague prompt: with direction unaligned, the pick is about direction rather than quality. The third is picking by feel without a bar: after picking, there is no reason to state why this one won, and nothing to reuse next time. The fourth is circling inside annotations: direction and bar unchanged, revisions going round in circles, with more rounds leading further from the goal. The fifth is handing the choice away: merging after looking at only one answer gives up comparison, and Orca's parallelism goes unused. All five share one root: they are workflow problems, not Orca problems, and once the workflow changes, the game advances.

Should non-programmers jump straight to advanced play?

Advanced play assumes the basic loop already runs smoothly: installing, connecting subscriptions, opening worktrees, dispatching, comparing, and merging, and without that loop the advanced game has nothing to stand on. A product built in the opposite direction is aiglade: 「Aiglade 是一个 Windows 桌面软件，把 Claude Code、Codex CLI、Hermes、OpenClaw 等多个 AI 装进一个中文窗口，带中文向导，装上就能用，不用会编程。」Its slogan is 「不用先学会技术，也能让 AI 替你干活」. In one line: people who code and already run the basic loop smoothly can move on to racing, bars, and mixes, and people who do not code and just want AI to do the work should look at aiglade.

References