Run several coding agents on one repo and merging becomes the traffic jam — they queue up, re-test against each other, and stall. cafecito clears it: work that touches different code lands in parallel, and the few changes that truly overlap are rewritten automatically from both sides' intent — never dropped on a human to resolve. Everything still passes your tests before it ships.
pipx install cafecitocd your-repo && cafecito init --ci # detects your gate, writes .mcp.json + CI, installs the tip hookcafecito swarm "add rate limiting, retries, tests" --agents 3 # one sentence → a fleet
Three agents branch from the same commit. Two commute and land in parallel; the third collides and is regenerated from both intents by a live reconciler — gated, trailer-stamped, main green. The pause in the middle is a real model call. Run it yourself.
One goal sentence. cafecito swarm plans it into independent tasks, pre-claims leases, runs the agents in parallel, and lands everything through the gate — while cafecito watch streams the fleet, the leases, and the landed log live. Real split-screen recording, 35 unedited seconds: one sentence → three agents → three gated landings → green main. Reproduce it.
Most of the time — 97% in our measurements — two changes touch completely unrelated parts of the codebase. There's nothing to reconcile, so both land together instead of one waiting on the other, and tests that couldn't have been affected don't re-run. In cafecito's terms, the changes commute.
Two agents really did edit the same code. Rather than hand a person a tangle to sort out, cafecito gives a fresh agent both sides' intent and has it rewrite that section from scratch — and the result only ships if your tests pass. It regenerates the overlap instead of resolving it; nobody ever sees a conflict marker.
Sometimes two changes want genuinely contradictory things, and no version of the code can satisfy both. cafecito stops and brings it to you with both intents in hand. It escalates — which is rare, and is the system working rather than breaking.
Point it at a repo: it detects your gate (pytest / npm test / go test), writes a checked-in .mcp.json so every clone, worktree, and agent session finds the plane, and installs a hook so commits made outside the plane still advance the tip. Add --ci and it scaffolds a GitHub Actions workflow too — your test gate plus a plane-sync guard that reddens the moment a commit bypasses the plane.
Keep opening ordinary GitHub PRs. ingest lands them through the gate — trailer-stamped, receipt commented, labeled. Its first production input was the pull request that documents it.
Symbol-level write sets from stdlib-only scanners — zero runtime dependencies. Anything unanalyzable widens safely to file granularity; other languages land at file granularity today.
Declare a generator ("package-lock.json=npm install --package-lock-only") and conflicts re-run it against the merged sources. In our TypeScript corpus that was 58 of 60 real conflicts.
Every landing gates on the whole test suite — but verdicts are content-addressed by input closure, so only tests the landing actually touched execute. The rest inherit facts. Closures resolve Python, TypeScript/JS, and Go test inputs; anything the analysis can't see through simply runs.
The gate executes candidate code, so give it a boundary: isolation: sandbox denies the network and confines writes to the gate's own worktree (macOS today; containers experimental). Unavailable backends redden the gate — no silent fallback.
A swarm worker that edits beyond its assigned paths doesn't race its siblings: the symbols it actually wrote are leased before its changeset enters the pipeline — whole files only when a file can't be analyzed — so a sibling editing a different symbol in the same file never waits. A merge-time collision becomes an intent-time wait.
A failed regeneration doesn't escalate blindly: the gate failure is fed back into a retry, so the reconciler gets to read the test output before a human has to.
watch is the live fleet dashboard; doctor checks your install; gc cleans up; --setup-cmd prepares bare gate worktrees (npm ci, pip install -e .) before tests run.
| strategy | wall-clock | CI compute |
|---|---|---|
| serial merge queue | 5.50 h | 93.5 h |
| file locking | 3.03 h | 29.7 h |
| speculative queue, unlimited window | 1.83 h | 43.3 h |
| cafecito | 1.37 h | 16.2 h |
Projected 10-min CI over measured schedules. 30/33 landed automatically, 3 correctly escalated, final main green — checked by running the combined test suite, not assumed. The speculative queue is modeled generously (free conflict discovery, offline resolution) and still loses on both axes at fleet conflict density — the honest caveats.
cafecito's own test suite was written by uncoordinated agents and landed through cafecito — including the fix for the first bug we found, which the engine landed while that code path was broken.
Since v0.1, every feature has landed through cafecito itself. Fifty-one self-hosted landings and counting — and every one of them either commuted or merged cleanly. Our own changesets have been disjoint enough that the reconciler has never fired here, which is the thesis holding on real work rather than proof that regeneration works; that proof is in the corpora, 14 of 16 conflicts regenerated with both suites green. Nobody has stared at a conflict marker. The only two escalations? The gate correctly refusing the sandbox feature it now runs inside, until that changeset fixed a latent bug in our own tests.
The whole account is written up: the two releases we shipped broken, the sandboxed gate that refused the sandbox, a repo of ours that drifted out of its own plane, the one where no model has ever heard of us so agents commit around the plane — and the six claims the first version of that post got wrong, corrected in the open rather than quietly deleted.