Key takeaways
- The system divides agents into two roles: planner agents using powerful frontier models recursively break a goal into smaller tasks.
- A lone agent has to traverse the entire tree while keeping both the goal and the current task in mind.
- The integrator ended up creating more bottlenecks than it removed.
What happened
The system divides agents into two roles: planner agents using powerful frontier models recursively break a goal into smaller tasks. Worker agents using faster, cheaper models carry out those tasks. The result is a task tree that adapts as the work progresses. Cursor says this role split primarily solves a context problem.
After four hours, the new runs scored between 73 and 85 percent, while the old runs scored between 11 and 77 percent. Every configuration of the new system later reached 100 percent. 5 runs showed why the old system fell behind. The old swarm produced 68,000 commits in two hours, about 70 times as many as the new one. Most of that activity was wasted work.
The old run accumulated more than 70,000 merge conflicts, while the new run stayed below 1,000 throughout the test. The most contested file in the old run recorded 7,771 conflicts from 1,173 agents, compared to 47 in the new run. The same split-brain problem appeared in the package structure. The old run broke the project into 54 Rust crates with three separate SQL packages.
The new run settled on nine crates early. In the Fable 5 configuration, the old swarm needed 64,305 lines of engine code, while the new one needed 9,908. In the Opus configuration, the old system produced 19,013 lines and scored 97 percent. The new system reached 100 percent with 4,645 lines. 5 running alone.
Workers accounted for at least 69 percent of the tokens in every run and usually more than 90 percent. Planner tokens cost more, so the cost split looked different. In the Opus hybrid, the planner produced only a small share of the tokens but accounted for two thirds of the total bill. The worker model created the largest cost gap. 5 run, workers alone cost $9,373.
In the run using Opus and Composer, the entire worker fleet cost $411 at comparable quality. The difference comes down almost entirely to pricing. 50 per million output tokens. 5, according to Cursor founder Michael Truell. Cursor argues that only a few parts of a large task need the intelligence of a frontier model, including task breakdown and key design decisions.
The company says accurately describing that intent was the main constraint in the experiment. Cursor published the codebase from the Opus solo run as minisqlite on GitHub.
Why it matters
A lone agent has to traverse the entire tree while keeping both the goal and the current task in mind. That helps explain why agents drift during long jobs. In Cursor's swarm, planners don't write code, and workers don't plan. An earlier Cursor browser swarm reached about 1,000 commits per hour on Git. It used worker agents, a judge agent, and an integrator that resolved conflicts.
The integrator ended up creating more bottlenecks than it removed. The new swarm reached 1,000 commits per second, so Cursor built its own version control system because agents working at that rate created failure modes that human teams never encounter. In what Cursor called "split-brain design," two planners would unknowingly build the same idea in different places and implement it in different ways.
Contention was even harder to manage when planners knew about one another and blocked each other with competing edits. Cursor had agents record decisions in shared design documents. Code tied to a decision linked back to the document through a reference checked at compile time. When merge conflicts occurred, a neutral agent stepped in and resolved them. Workers flagged bloated files for an outside agent to split into smaller modules.
Because agents had learned not to touch core code while working in existing codebases with humans in the loop, Cursor let them break things on purpose. An agent could patch code outside its assigned area, and the compiler would carry the change through the system. Cursor tested several review approaches. One reviewer received the worker's full transcript, another saw only the output, and a third saw only the codebase.
No single perspective caught everything, but uncorrelated perspectives combined for higher reliability. Cursor also tested a "field guide," a knowledge folder maintained by the agents themselves with a fixed line limit. Every agent received its contents at startup. Since model weights are frozen, it pays to capture surprising findings so later agents can take shortcuts.
Cursor gave the swarm the 835-page SQLite manual and told it to build a Rust implementation. Source code, test suites, the SQLite binary, and internet access were all withheld. The benchmark was sqllogictest, a test suite with millions of SQL queries and known answers. The swarm didn't know it existed. Four configurations were tested. 5 as worker. The new system beat the old one in every configuration.
What to watch
Once a frontier planner resolves the ambiguity, cheaper models can follow its plan, though the hybrid runs showed that planner quality still mattered. The Fable 5 planner used fewer planning tokens than Opus, but its workers needed far more tokens to finish the job. The Fable run cost more overall. Cursor describes swarms as a kind of probabilistic compiler that translates intent into executable work one step at a time.




