Cursor's agent swarm hit ~1,000 commits an hour building a browser

Cursor has published a long engineering account of the multi-agent harness behind its browser-from-scratch experiment, and the headline number is throughput: the system peaked at roughly 1,000 commits per hour across 10 million tool calls over a week of continuous running, with no intervention once it started. Author Wilson Lin writes that the company is also making part of the harness available to try in preview for some users.

Luis Catacora's five-minute animated walkthrough of the post: the four harness designs, and the role each redesign removed. Credit: @lucataco.

The project started with Lin prompting Opus 4.5 to plan a browser engine and nudging it to "keep going." That failed fast: the model lost track of what it was doing, declared success early and stalled on implementation detail. A browser was the benchmark precisely because it is overwhelming for one agent and has many subsystems that must work together.

#Self-coordination failed, structure worked, then structure was cut back

The first multi-agent attempt gave every agent an equal role and a shared coordination file. Agents held locks too long, forgot to release them, and locked or unlocked when it was illegal to. Contention was brutal: 20 agents slowed to the effective throughput of 1-3, mostly waiting. Worse, flatness made agents timid — nobody took on the big, contentious work.

The first structured design: a planner, a single accountable executor, spawned workers, and an independent judge. Credit: Cursor.

Roles fixed coordination but left the system bottlenecked on its slowest worker, and a plan fixed up front could not adapt. Cursor merged the planner into a "continuous executor," which promptly went pathological: it slept randomly, stopped spawning agents, did work itself and claimed premature completion. The diagnosis was role overload — plan, explore, spawn, supervise, review, edit, merge and judge, all in one agent.

The final design: a root planner that never codes, recursive subplanners owning slices of scope, and isolated workers returning written handoffs. Credit: Cursor.

The final design is recursive. A root planner owns the whole instruction and writes no code; it spawns subplanners that fully own narrow slices; workers take tasks in their own copy of the repo, never talk to each other, and return a single handoff carrying not just what they did but concerns, deviations and feedback. Planners keep receiving those handoffs after they think they are done, which keeps the system converging without global synchronization. The central integrator role was deleted: one merge gate for hundreds of workers was, in Lin's words, red tape. The recurring lesson across all three iterations is that adding management layers cost more throughput than it bought.

#The tradeoffs that bought the throughput

Cursor made two deliberate concessions. Demanding 100% correctness at every commit serialized everything: one typo would halt the system while agents piled onto the same fix. Accepting a small, steady error rate — with a later "green" branch where an agent snapshots and does a cleanup pass — kept throughput up. When several agents touch the same file, Cursor likewise lets the turbulence settle rather than engineering it away.

Each run used one large VM. After capping agent RAM, disk became the hotspot: hundreds of agents compiling a monolith simultaneously moved many GB/s of build artifacts, so compilation, not thinking, dominated wall-clock time. A later run that broke the monolith into self-contained crates ran several times faster, and converged out of a heavily broken repo state in a few days. Lin's suggested fixes are borrowed from databases: real concurrency control for the shared locks in Git and Cargo, and copy-on-write deduplication across the near-identical repo copies each agent holds.

#Prompts move the needle more than the harness

Lin's prompting notes are concrete. Instruct only what the model does not already know — your test commands, your deploy pipeline — and treat it as a brilliant new hire. Prefer constraints ("no TODOs, no partial implementations") over reminders. And give numbers: "generate many tasks" produces a conservative handful, while "generate 20-100 tasks" changed behavior across the whole system.

#Why it matters

This is the most detailed public description yet of a coding harness run at hundreds of concurrent agents, and it lands against Cursor's earlier results post: a browser at over 1 million lines across 1,000 files, a Solid-to-React migration of Cursor's own codebase at +266K/-193K over three weeks that passed CI, and running experiments including a Java LSP (7.4K commits, 550K LoC), a Windows 7 emulator (14.6K commits, 1.2M LoC) and Excel (12K commits, 1.6M LoC). Early social coverage of the browser run circulated a figure of roughly 3 million lines of code; Cursor's own post is more conservative, putting the browser above 1 million lines and reserving the larger totals for the other experiments. Model choice matters by role: Cursor moved the harness to OpenAI models after GPT-5.1 and GPT-5.2 followed instructions more precisely, calls GPT-5.2 a better planner than GPT-5.1-Codex, and says Opus 4.5 "tends to stop earlier and take shortcuts when convenient."

The caveats are Cursor's own: the browser was never meant to ship, the code was expected to have quirks, and every number is self-reported with no external audit. What is notable is the closing claim — that a structure nobody trained the models to adopt converged on something resembling how human software teams already work, which Lin reads as emergent rather than imitated.