Cursor's AI Swarm Rebuilt SQLite From Scratch at 15x Lower Cost

Cursor just published a research post on what may be the most rigorous public test of autonomous multi-agent coding to date. The team instructed a swarm of AI agents to implement SQLite from scratch in Rust, using only the 835-page SQLite documentation. No source code, no test suite, no internet access. The result: a working database engine that passed 100% of a held-out SQL test suite, plus findings about model economics that should change how you think about building with agents.

This follows Cursor's earlier browser-from-scratch experiment, which proved the concept but produced messy software. The new work is about engineering the swarm deliberately, and the gap between the two systems is dramatic.

The planner-worker split

The core architectural insight maps directly onto how large tasks naturally decompose. A goal subdivides recursively into basic units of work, forming a tree. Cursor's swarm mirrors that structure:

• Planner agents, running on the most capable models, decompose goals and delegate subtasks.
• Worker agents, running on faster and cheaper models, execute those subtasks.

A planner never implements, so its context never fills with low-level detail. A worker never plans, so it can spend its full context on one narrow piece of work. This is why the system scales: beyond parallelism, it's context efficiency. A single long-running agent eventually loses coherence because it can't hold both the big picture and the implementation details simultaneously. The swarm sidesteps this entirely.

Engineering coordination at 1,000 commits per second

The previous browser-building swarm peaked at roughly 1,000 commits per hour on Git. The new system peaks at around 1,000 commits per second. Standard version control tooling cannot handle that rate, so Cursor built a new VCS from scratch. Throughput was only part of the problem, though. At this scale, failure modes emerge that human engineering teams never encounter.

The team identified and solved five distinct ones:

• Split-brain design: Two planners independently implement the same concept differently. Fixed by requiring planners to own design decisions and ensuring no two delegated subtrees resolve the same question.
• Planner contention: Two planners fight over the same files. Fixed with shared design docs carrying compile-checked references, so a neutral reconciler can propagate resolutions automatically.
• Merge conflicts: Worker agents are bad at resolving collisions and tend to either overwrite or abandon changes. Fixed by introducing a neutral third-party agent that intervenes and resolves conflicts impartially.
• Megafiles: Popular files grow unbounded as many agents each add a little. Once flagged, new commits are blocked and an outside agent decomposes the overgrown file into smaller modules.
• Ossification: Agents trained on human codebases are reluctant to touch core code. Fixed by explicitly licensing intentional breakage, where an agent can patch outside its scope and leave a comment, letting the compiler propagate the change to every dependent.

Agents that teach each other

One of the more novel ideas in the post is what Cursor calls the Field Guide, a folder owned entirely by the agents. Its index.md is automatically injected into every agent at start, and the agents curate what goes into it, constrained only by a line budget. When an agent hits a surprising situation, writing it down shortens the path for every future agent in the run. Cursor describes this as stigmergy, the mechanism by which ants coordinate without direct communication: shape the environment, and the environment shapes the next agent.

The team also stacked multiple review agents with different perspectives on the same work. No single lens catches everything, but decorrelated lenses stack, the way self-driving systems reach above-human reliability without any single perfect component. Review is cheap relative to the work it audits, making it high-return compute.

What the SQLite numbers actually show

The swarm was given the full 835-page SQLite manual and told to implement it in Rust, with the source code, test suites, SQLite binary, and internet access all withheld. Progress was graded against sqllogictest, the official SQLite test suite containing millions of queries with known correct answers. The swarm was never told the suite existed.

Four model configurations were tested, each run for four hours:

1. GPT-5.5 as both planner and worker
2. Grok 4.5 as both planner and worker
3. Opus 4.8 as planner, Composer 2.5 as worker
4. Fable 5 as planner, Composer 2.5 as worker

The new harness outperformed the old in every configuration. By the four-hour cutoff, new runs sat between 73% and 85%, while old runs ranged from 11% to 77%. Every new configuration eventually passed 100% of the suite. The old Grok 4.5 run had to be paused before the two-hour mark because it was spiraling out of control.

The behavioral differences are more striking than the scores. The old Grok 4.5 run produced 68,000 commits in its first two hours, roughly 70 times the new run's pace, and accumulated more than 70,000 merge conflicts before being paused, accelerating rather than stabilizing. The new run logged fewer than a thousand conflicts over its full four hours. The old run sprawled to 54 Rust crates, including three separate SQL packages. The new run settled on nine crates early and never added another.

Code quality tells the same story. In the Fable 5 configuration, both the old and new swarms ultimately passed the full suite, but the old one needed 64,305 lines of engine code and the new one did it in 9,908. The new swarm writes cleaner, more coherent code, and does it faster.

The 15x cost gap

The most practically important finding concerns model economics. Costs varied enormously, from $1,339 for the Opus 4.8 hybrid to $10,565 for GPT-5.5 alone, while producing similar quality results. The reason is structural: workers carry over 90% of tokens in most runs, but planner tokens cost more per unit. The cheapest configuration therefore uses a frontier model only for planning and a fast, cheap model for all the execution.

Few moments in a large task genuinely require frontier intelligence: the original decomposition, the key design decisions, certain trade-offs. Once a frontier planner has collapsed the ambiguity into a detailed, explicit instruction, less expensive models can follow it. In the GPT-5.5 solo run, workers alone cost $9,373. In the Opus 4.8 plus Composer 2.5 hybrid, the entire worker fleet cost $411.

One nuance worth noting: the Fable 5 planner used fewer planning tokens than Opus 4.8 despite a higher per-token price, but its workers consumed far more tokens overall, making the Fable run substantially more expensive in total. A more capable planner does not automatically produce a cheaper run if it generates less precise instructions that workers have to compensate for.

The spec as source code

Cursor frames the broader implication in terms of abstraction levels. Each generation of AI tooling has raised the ceiling: from autocomplete (one line), to early models (a block), to agents (a file or feature). With swarms, the unit of work becomes the spec. They handed the swarm 835 pages of prose and got back a database.

The analogy Cursor reaches for is a compiler. A compiler translates intent down through intermediate representations to machine code. The swarm does something similar: planners parse a goal into task trees and lower it step by step into executable work. The difference is that a compiler is deterministic and the swarm is probabilistic at every step. Everything described in this post, the custom VCS, the conflict resolution agents, the Field Guide, the stacked reviewers, exists to close that gap.

The codebase from the solo Opus 4.8 run is public at github.com/anysphere/minisqlite. The team has not yet done a deep manual analysis and invites the community to dig in.