Cursor's AI Swarm Rebuilt SQLite From Scratch at 15x Lower Cost
Cursor's new agent swarm rebuilt SQLite from its 835-page manual in Rust, passing 100% of tests at up to 8x lower cost than before.
- Cursor's new agent swarm rebuilt SQLite in Rust from its 835-page manual alone, passing 100% of a held-out SQL test suite.
- The new swarm dramatically outperformed the old: fewer than 1,000 merge conflicts vs. 70,000+ in the old run, and 9,908 lines of code vs. 64,305 for the same result.
- Cost varied 15x across model configurations, from $1,339 (Opus 4.8 planner + Composer 2.5 worker) to $10,565 (GPT-5.5 solo).
- Key innovations include a custom VCS handling 1,000 commits/second, neutral conflict-resolver agents, megafile decomposition, and a self-authored agent Field Guide.
- The core economic insight: use a frontier model only for planning; cheap models can execute detailed instructions at a fraction of the cost.
- The minisqlite codebase from the Opus 4.8 run is publicly available on GitHub.
Cursor just published a detailed 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, and a set of findings about model economics that should change how you think about building with agents.
This is a follow-up to 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 old and new systems is dramatic.
The planner-worker split
The core architectural insight is deceptively simple. Descriptions of large tasks naturally take the shape of trees, with a goal at the root that subdivides recursively into basic units of work. Cursor's swarm maps directly onto this 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.
In a swarm, a planner never implements, so its context never fills with low-level detail, and a worker never plans, so it can spend all its context on one narrow piece of work. This is the key to why the system scales: it's not just parallelism, it's context efficiency. A single long-running agent eventually loses the plot because it can't hold both the big picture and the implementation details at once. 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 simply cannot handle that rate, so Cursor built a new VCS from scratch. But throughput was only part of the problem. At this scale, entirely new failure modes emerge that human engineering teams never encounter.
The team identified and solved five distinct failure modes: