Cursor publishes results from a long-running experiment: a system of agents working in parallel to rebuild SQLite from scratch in Rust, starting only from documentation. The architecture has two roles: planner agents with the most expensive models that break down the goal into sub-tasks, and executor agents with cheap models that implement them.

The data that matters is about cost. Changing which models do which work doesn’t change the quality of the final output, but it changes costs dramatically. A strong model that plans and a cheap one that executes produce the same output as a strong model doing everything, at a fraction of the price.

Cursor attributes the gain to context efficiency rather than raw parallelism. The planner never writes code, so its context stays free from low-level details. The executor never plans, so it spends all its context on a single piece. The system’s shape grows to fit the problem, like an organization that divides into units when coordination costs exceed the value of direct work.

We’ve been following this thread. On July 12 we reported how GPT-5.6 Sol Ultra used 64 sub-agents in parallel for a verified mathematical proof. Cursor’s post brings the same principle onto software ground and gives it an economic framework: which model to assign to which role, and what it costs.

Cursor is honest about limitations. The first swarm had built a browser “far from finished software”. Even SQLite from scratch remains a proof of concept, not a ready product.

In detail

Where it comes from.

Early this year Cursor launched a first swarm with an ambitious goal: build a web browser from scratch. The experiment succeeded as a proof of concept, but the result was rough software, not polished. The approach was deliberately empirical: start from a blank canvas and improve through trial and error until finding something stable.

The new work returns to a task the old swarm had failed at: rebuilding SQLite in Rust from documentation alone. Same task, same models, same time budget. They measure how much of the official test suite (held back, not seen during development) each system passes.

The numbers.

With Grok 4.5, the new swarm reaches 80% of the test suite in four hours. The old swarm had to be stopped before the second hour because it “spiraled”. Cursor reports that every model configuration tested with the new system beat the old one.

On execution speed, Cursor built a version control system from scratch. The old peak was around 1,000 commits per hour with Git. The new system reaches 1,000 commits per second. VCS is where conflicts become visible, and some coordination mechanisms are implemented directly there.

Why context matters more than parallelism.

The central thesis is that the gain comes from context efficiency, not from running in parallel. When a single agent tackles an entire task, it must keep the global goal in mind, its current position in the work tree, and low-level details. After a while it loses focus: either it concentrates on the piece and forgets the big picture, or it keeps the big picture and does worse on the piece.

In the swarm, the planner never implements. Its context stays clean. The executor never plans. Its context is all for a narrow piece. The system’s shape grows to fit the problem, instead of imposing a fixed topology.

Cursor cites Ronald Coase: organizations stratify into units with boundaries because coordination costs grow faster than work. The swarm does the same thing with agents.

Where it breaks.

At 1,000 commits per second, failure modes appear that human teams don’t encounter.

The first is split-brain: two planners, unaware of each other, implement the same concept in two different ways in different parts of the code. Cursor solves this with prompting: planners make design decisions on their own and must ensure two sub-trees don’t decide the same question.

The second is planner conflict: two planners aware of each other fight with back-and-forth edits on the same files. The merge tool doesn’t resolve disagreement, it only resolves text. Cursor has decisions recorded in shared design documents.

What’s missing.

The post is honest about limits: the swarm building SQLite remains a proof of concept, not ready software. The “new model economics” is described in the results (different mixes, different costs, similar quality) but specific cost numbers aren’t published in detail. For those building agents, the direction is clear (strong planner + cheap executor), but exact calibration remains to be done on your own case.

This confirms a thread running through recent weeks: orchestration matters more than the model. Today three convergent papers said the same thing with production data. July 12 GPT-5.6 Sol Ultra showed 64 parallel sub-agents for math. Now Cursor brings empirical evidence to code.