What this page is
This is a rehearsal of a first run, executed on one machine on the date stamped above, with the clock running. It is not a tour of the interface and it is not an aspiration. Every number below came out of a command.
Checked against the Orcyx source tree at c339cf993 on 2026-09-14. The rehearsal ran in the Orcyx monorepo on Windows 11 Pro 26100, on an NVMe volume, with fifteen other agent panes live in the same repository. Where this page describes something the build does not do yet, it says so in place rather than describing the intention.
Fifteen concurrent panes is the pessimistic case, not the flattering one: everything below that touches git was contending for the repository index while it ran. A quiet machine will be faster. We are quoting the contended numbers because that is the state a real swarm puts a repository in.
Step 0 — the install, which did not happen
The recipe is supposed to open with a download. It cannot, today, and the honest thing is to say so on the first page a new user reads rather than at the bottom of a release note.
| Probe | Result |
|---|---|
| https://downloads.orcyx.dev/orcyx/latest/release.json | HTTP 404 (Cloudflare) |
| Measured at | 2026-09-14T15:29:10Z |
That URL is the release manifest the download page fetches to render the current version, size and SHA-256. With it returning 404 there is no published build to install, and the download page discloses that state rather than offering a dead link. The rest of this rehearsal therefore ran against a development build from the source tree.
- What you should read instead: Install, which covers building from source and the prompts an unsigned binary produces.
Step 1 — three seats, measured
A seat is a git worktree of your repository that one agent pane owns: its own branch, its own working tree, sharing your installed dependencies. Spawning three of them is the first thing a swarm does, and it is the step people assume is slow.
The rehearsal ran the same sequence the app runs — prune stale worktree registrations, add a worktree on a new branch, link the dependency directories, copy the git hook shims — and timed each part.
| Step | Measured |
|---|---|
| git worktree prune | 0.13 s |
| git worktree add (seat 1 / 2 / 3) | 4.25 s · 6.00 s · 4.77 s |
| node_modules junctions per seat | 5 ms (×10 node_modules links per seat) |
| git hook shims per seat | 11–19 ms |
| Three seats, wall clock | 15.2 s |
The shape of that table is the point. Creating the worktree is essentially all of the cost — four to six seconds each, on a monorepo, under contention from fifteen other panes. Wiring the seat so it can actually build is three orders of magnitude cheaper: the dependency directories are linked, not copied, so a seat does not pay an install, and the hook shims are a few hundred kilobytes.
The hook shims are not optional. Git's hooks path here points at an untracked directory, so a worktree created by hand without copying it runs NO hooks at all — no type gate, no commit-message check — and every commit in that seat appears to pass. The app copies them on creation and on adoption; if you make a seat by hand, copy them yourself.
Step 2 — one prompt, three seats
Each seat got the identical prompt and the identical target file, so the only variable was the approach:
Add apps/site/scripts/redirects-target.test.mjs — a node:test guard that fails if any _redirects rule points at a page the site does not ship.
Racing on one file is deliberate. Three agents each producing a different file is not a race, it is three tasks; the interesting question is what happens when three plausible answers collide on the same path, because that is the situation a swarm actually creates.
The first thing that happened was not code
One agent stopped before writing anything and asked a question: the working directory it had been handed did not match the seat it had been assigned, and it declined to guess which one was real. It named the exact risk — either it would duplicate another racer's work, or it would commit onto a branch nobody was scoring.
It then won the race. That is the result, and it is not the one we expected when we set the race up: the agent that spent its first minute establishing where it was still committed first, because the two that started typing immediately spent longer inside the commit gate than it spent asking. An agent that resolves an ambiguous workspace by guessing is not buying speed. It is buying a commit in the wrong tree, at no saving.
Three answers, one path
All three produced a working guard and all three wrote it to the same path, which is what a race on one file is for. Merging the second one onto the first is therefore not a formality:
$ git merge seat/docsfirstrun/alpha Auto-merging apps/site/scripts/redirects-target.test.mjs CONFLICT (add/add): Merge conflict in apps/site/scripts/redirects-target.test.mjs Automatic merge failed; fix conflicts and then commit the result. exit status 1 · 1.4 s
An add/add conflict, in 1.4 seconds. Nothing went wrong here — this is the swarm working. Two agents independently solved one problem, and the second one now rebases onto the first and reconciles, in its own worktree, with both answers in front of it. Plan for that reconciliation as part of the task, not as an exception to it.
Step 3 — the gate
Two gates run here, and they are frequently confused. Only one of them can refuse anything.
| Gate | When | Can it stop the change? |
|---|---|---|
| The auditor gate | When a builder, scout or reviewer reports DONE, the swarm scans that role's changed files for secrets, unsafe patterns and CSP problems. | No. It is advisory. A high-severity finding is surfaced prominently — on the run banner and the error strip — and the operator or coordinator decides. |
| The pre-commit hook | On every commit in the seat: dependency-lockfile sync, then a whole-project type check. | Yes. A failure exits non-zero and the commit does not happen. |
The auditor gate being advisory is a real property of the build, not a simplification for this page: a true block would have to hook a merge step the swarm does not have today, so the count of blocking-severity findings is computed and displayed, and the block is left to a person. Plan your review around that. If you want an automatic refusal, the pre-commit hook is the surface that gives you one.
A scan that fails is never shown as a pass. If the auditor cannot run, the gate reports an error — in the same danger styling as a finding — rather than falling through to a clean verdict.
Step 4 — merging the winner
Seats merge back one at a time and the first one in wins. The others rebase onto the new tip and resolve there, in their own worktree; nobody resolves a conflict by editing the main checkout, because the main checkout is what every other seat is measuring itself against.
The merge is scripted rather than typed, for a reason worth knowing before it costs you an afternoon: piping a merge through another command makes the pipeline report the LAST command's exit status. The conflict above exits 1 on its own and 0 through a pipe — we ran both, on these branches, on this machine — so a merge lost to a conflict or to index-lock contention can read as a success, and the push that follows then prints that everything is already up to date while the merge is gone.
- The demonstration, both invocations side by side: Troubleshooting → a merge reported success and the branch did not move.
So how long is the first run
The parts that are machine time are small and were measured: fifteen seconds to put three agents in three isolated checkouts. The parts that are model time — three agents reading a codebase, writing a test, proving it catches something, and passing a type gate — dominate everything else, and vary with the task, the model and the size of your repository.
The honest headline is therefore not a single number. It is this: the environment gets out of the way in about fifteen seconds, and everything after that is the work itself.
What was not measured
Four steps in the canonical recipe were not executed on the machine that wrote this page, and are not reported as if they were:
- Installing from a published build. There is no published build — the release manifest returned 404, above. The rehearsal used a development build from the source tree.
- Running the installer. The machine was running Orcyx at the time; installing over a live app would have replaced the thing under measurement.
- Driving the three seats from Orcyx's own agent panes. The racers were driven from a terminal in the same repository. Seat provisioning, the hook shims, the commit gate and the merge are the app's own code paths and were exercised exactly as they ship; pane spawning and the in-app swarm console were not, so nothing here is a measurement of them.
- Merging onto the main branch. The winner was merged onto a scratch integration branch, because a rehearsal has no business landing on the branch everyone else is building against. The conflict, its exit status and its timing are real; the destination was not main.
Everything above that carries a number was executed. Everything in this list was not. The distinction is the only thing that makes the rest of the page worth reading.