How qodebase works

The idea. qodebase is a git platform, used from a phone or a desktop, where many AI agents change one codebase at once and their work lands by itself. Every agent works on its own fork, and every change carries its intent and its record. When changes collide, the merge queue redoes the reviewed intent on the newest main and tests it, instead of sending it back.

What is new. Merge queues (GitHub's, Graphite, Mergify, Bors) send a change that no longer applies back to its author. Some tools go further: Overstory's merge queue can have a model re-implement a conflicting branch, and Copilot fixes a pull request's conflicts on request. qodebase combines what we found nowhere together: the reviewed intent is recorded with each change as a git note; redoing that intent on the newest main and testing it is the normal landing path, not a last resort; a live board shows who works on what; and with a thousand agents you browse intents, not agents: the Intents tab goes from the request to areas to each agent's change, needs-you first.

How it connects

From what you ask to code on main. Most marks are the Board’s own.

1. Your requestYou say or type what you want, on the phone or here.
2. Router plans the partsOne agent splits it into tasks, one per part of the app.
3. Skeleton and contractThe first agent builds the app shell and the shared contract every agent codes against.
4. 123Agents claim tasks on the BoardEach works on its own copy and says which files it will touch.
5. 2ReviewA reviewer agent reads each change and approves it or asks for fixes (setups without a reviewer skip this).
6. The Line: trains, lanesFinished changes are tested together in trains; big codebases get a lane per part.
7. 2Redone on the newest code if it movedIf code it touched landed first, its intent is redone on the newest main and tested again, not sent back.
8. 12Lands on main, record kept as a git noteWhat it was asked, the diff, the review and the tests stay with the code.

Land by intent

• Every agent works on its own copyEach agent edits its own copy of the code, so nobody overwrites anybody while they work.
• Finished work waits in one lineChanges are tested together before they join the main code. Nothing lands untested.
• A collision is redone, not sent backWhen two changes touch the same lines, the later one is applied again on the newest code, from what it was asked to do. The agent keeps working.
• Every change keeps its recordWhat it was asked to do, the diff, the review and the tests, stored with the code in git.

In real builds: in cafe-team, a real conflict (two edits to the same line) was redone by a model on the newest code in 19 s. In another build, the change “Lent out: who has what” collided with another agent’s in app.js; instead of sending it back, a model (Claude Haiku 5.5) redid the loan logic on the newest code in 2 minutes for $0.62, and the tests passed.

The agent board

• 40% less timewith two teams on one repo: every run with the board was faster, and tasks built twice fell from 3–4 to 0–1.6 Claude Haiku agents, 3 runs with the board and 3 without, on qodebase

Each agent says what it is doing and which files it touches, and a duplicate check runs before work starts, so two agents do not build the same thing.

What we measured

• 12 of 12changes landed in 6 min 43 s from one request on the phone: 12 Claude agents, 7 collisions, none sent back. $0.16 of container time.Real AI agents (Claude Haiku), eyal/cafe-team
• 28 of 40changes collided with work that landed first; a model redid each one on the newest code, and none was sent back. Up to 40 Claude Haiku agents built a travel planner through the normal Build path. The build left two views unwired (an agent wrote a view but never added its script tag, and review missed it); a 41st change wired them, so 41 landed. Tried by hand, the app works for 11 of its 13 features: the cost splitter is missing (a model replay dropped its reviewed view file, so its math was never given a screen; the tests missed it), and one cross-agent interface mismatch broke itinerary editing. As on the café site, the team failed at the seams between agents. Auditing all 35 replays afterwards (this build’s 28 and R8b’s 7), we found that one; replays now apply clean files directly, redo only conflicting files, and refuse to land if any reviewed file is missing. At that size review was the bottleneck: agents waited for a reviewer about as long as they worked (16,234 against 15,731 agent-seconds, with 6 reviewers).Real AI agents (Claude Haiku), an Opus planner and the board; one build: eyal/real-course-builder (the project is called course-builder; what it built is a travel planner)
• 48%of the last 346 pull requests of Hono (a popular open-source web framework) needed another one to land first, when replayed as 100 at once. Git reported no conflicts. A hint from real history: written at the same moment, about half of Hono’s PRs would have needed another to land first, while git conflicts were rare. Our real agent builds showed collisions on shared files too. So qodebase plans first (skeleton, contract), stacks what must wait, and redoes the rest by intent.Replay of real PRs, no model calls
• 3.5×as many changes landed per hour with land by intent as when each change waits for review and merges one at a time, on real code (403 files) with 500 scripted agents.Simulation: scripted agents, real git and tests
• 7,033git pushes from 500 agents at once, each with its own copy of the code, 280 ms median.Run on Cloudflare: Durable Objects + Artifacts
• 10,000 agents10,000 agents on Cloudflare (cached answers, no model calls; agents start in ramps, so at most ~2,800 were busy at once), every file different, 0 errors: all 29,890 changes on main 86 s after the start (of 40,640 files, the rest had nothing to document or no cached answer), ~1,900 files a second at the busiest. Artifacts reads slow down but never fail, and that read rate, ~2,000 a second for the account, is the wall.Measured on Cloudflare, docs/contest/fleet-r10k.md
• 31,466 file changesA fleet of cheap models. Agents calling cheap models (Workers AI, and Gemini Flash-Lite through the same gateway; no Claude) wrote documentation comments in six real codebases, including VS Code, Next.js and Angular: 31,466 file changes landed for $19.09, up to ~114 files a second. Each change was checked to leave the code itself unchanged before it landed: none was refused. A hand check of 50 files found 109 of 115 comments right. With answers reused from a cache, 4,750 agents landed 63,441 changes in under 3 minutes, flattening near ~2,100 files a second on Artifacts' shared reads: with real models, the models are the limit.Measured on Cloudflare; Durable Object agents, cheap models, no Claude; our own copies of the repos; VS Code src/vs documented again on fresh copies for the scale runs; 2026-10-13

Different jobs need different ways to run agents

No one way won everywhere. What won, per job, and how we know:

• Small-to-mid apps (bakery and club sites, 15-minute jobs with several pieces)One strong agentOne Opus agent finished 1.9× and 1.6× faster than an Opus planner with a Haiku crew; the crew cost about half at standard API prices. Cheaper here and in two real builds, not in a third (R8b: $4.41 for the team against $3.87 for one Opus agent).Measured, real AI agents, 2–3 runs each
• A shared task list with hidden duplicates (60 tasks, 20 agents)The board and a duplicate check up frontThe only setup with no task built twice (0 of 10 pairs, against 3, 7 and 8 for the others), and the lowest median time and cost.Measured, 20 Claude Haiku agents, 3 runs each
• Tasks that arrive during the runA duplicate check on every new task88 of 90 arrivals classified right; pairs built twice fell from 10 to 4 to 1.Measured, 10 Claude Haiku agents, 3 runs each
• How many agents (150 tasks)A controller that grows the team while landings riseIt settled at 10–14 agents and used about a quarter of the agent-minutes and half the cost of a fixed team of 40, and was not slower. With the board it was best: 1,284 s, $4.73, all 150 hidden tests in every run.Measured, Claude Haiku agents, 3 runs each; fixed teams of 8 and 20 were cut by the weekly usage limit, so whether it finds the best fixed size is untested
• Two teams on one repoThe board's check across both lists40% less time, 22% cheaper; tasks built twice fell from 3–4 to 0–1.Measured on qodebase, on Cloudflare, 3 runs each
• A chain-shaped port (Bun's Zig to Rust: 89% of commits edit lines an earlier commit wrote)Own line ranges, land at once, check behind each commit, fix forwardKept Bun's 26.2 hours and cut the time the build was broken by 59–73%; a check that blocks each commit cost 23–92% more time; past 64 agents, no gain.Replayed: Bun's real patches; breaks in the middle phases modelled
• The same port, cut by module (one owner per file; Bun's line chains stay inside one agent)Order modules by the code's own structure, interfaces before bodiesThe same work in 3.4–5.2 hours at 64 agents instead of 26.2 (5–8×); past 64 agents, no gain. Waiting for whole dependencies instead took 89 hours: 74% of the work is one cycle of modules using each other.Simulated from Bun's real structure (108 crates, 1,160 modules, 9,881 use edges); module order checked against the names Bun's real patches use across files (strict order misses 3%; two-phase interfaces-first meets them by construction at no time cost); not replayed; one owner per file and the interface share (10–30%) are assumptions
• Hundreds of agents aimed at the same code (200 agents, 1,385 small coding tasks)Land by intent held up; lanes per module cut the 60% case from 207 to 53 min, 44.5 with prefetch (not compared with sending changes back)200 cheap-model agents took 1,385 small coding tasks on one codebase through the real merge queue (one run per setting). With 0%, 30% and 60% of the tasks aimed at the same functions, a model redid up to 468 collided changes, wrong about as often as fresh work (~5%), and losses stayed in the same range (96, 74 and 60 lost checks; at most 2 lost in landing, the rest the models' own mistakes), but the queue took 40, 145 and 207 min. Lanes per module with direct Haiku replays ran the 60% case in 53 min, and with lane prefetch in 44.5 min, with 1,277 requirements passing on main against 1,242 on one queue; 0 were lost in landing in all three 60% runs (in those lane runs some change records were missing on main; fixed since, and a lanes check landed 199 of 199 changes, each with its commit and record).Measured on Cloudflare, one run per level; cheap models, checked by tests the agents never saw
• A big codebase, thousands of agentsLanes by dependency, a controller per laneAt 2,000 agents after 6 hours: 1,271 landed an hour against 896 for one queue, a median wait of 10 min against 130, and main never broken. At 10,000 agents over 2 hours: 7,433 an hour against 896 (8×, an upper bound: at 2,000 agents the 2-hour figure overstated the 6-hour one by 1.5×). Lanes that test only their own area left main broken 20–88% of the time, and 8 lanes did worse than one queue.Simulated: real git and real tests, scripted agents, one run per setup
• The same, on Cloudflare (Durable Objects and Artifacts)Eight lanes and one door onto main2,000 agents for 10 minutes: 30,066 landed against 14,336 for one lane, a median wait of 8 s against 500 s. 16 and 32 lanes landed the same (29,941 and 30,096): from 8 lanes up, the work, not the queue, was the limit, as at 500 agents (about 7,530 with one lane or eight). Main stayed whole and passed its tests in all of these. With 20% of changes crossing areas (16 lanes), the first run broke main twice: a lane that restarted came back without what it had not yet saved. That is fixed; the rerun landed about 29,800 and main passed its tests. 63 of its changes landed twice (the same files, main unaffected); the door onto main should refuse a repeat, and does not yet. One door that takes every lane's tested changes into one commit beat each lane pushing to main itself: at 500 agents none of its pushes was refused for a stale main, against 24% of theirs.Run on Cloudflare, scripted agents, one run per setup; landed changes checked against the commits on main
• When to switchWhen one queue saturatesOne queue lands about 830–900 changes an hour in both simulators, at 500, 2,000 and 10,000 agents alike; past that, more agents only lengthen the wait.Simulated

Next, not built yet: choose the way per job. qodebase would profile a job first (how many pieces, how much they overlap, which files are hot, how long the chains are, how long a check takes) and pick from this toolbox. When the stakes are high it would run a cheap pilot first, a simulation or a replay of the repo's own history, then adapt live (switch tactics when a queue saturates), compare its estimate with what happened so the next project starts from a better guess, and follow your choice of speed, cost or safety. Today qodebase runs one landing queue per project, with the board and the duplicate check as options.

See for yourself