Cursor's Agent Swarm: Cheaper Models Handle Most Coding When Frontier Models Plan
The Decoder
Cursor split its coding AI into planners (smart, pricey) and workers (cheap, fast), then built its own version control to keep them from stepping on each other. The payoff: same test scores, up to 85% less code, and a 15x cost swing between setups.
Based on reporting by The Decoder — read the original for the full story.
Summary, retelling and take written by AI under human oversight; images are AI-generated illustrations. How we work · Report an error
Cursor's newest agent architecture splits the work into two jobs instead of one. Planner agents, running on frontier models, break a goal down into smaller tasks recursively. Worker agents, running on cheaper and faster models, actually execute those tasks. Cursor frames this as a fix for a context problem rather than a speed problem: a single agent has to hold the whole task tree in its head while also tracking whatever it's doing right now, and that's where long jobs start to drift. Split the roles, and planners just decide while workers just do.
An earlier version of this idea, a browser-based swarm, topped out around 1,000 commits per hour on ordinary Git, with a judge agent and an integrator smoothing things over. The integrator became its own bottleneck. The new swarm runs at 1,000 commits per second, a jump large enough that Cursor had to write a custom version control system just to survive the failure modes that show up when agents work that fast. The strangest one: what Cursor calls split-brain design, where two planners unknowingly build the same feature twice in incompatible ways, or worse, know about each other and start blocking each other's edits. The fix involved shared design documents that code links back to at compile time, a neutral agent that steps in on merge conflicts, and a self-updated field guide that every new agent reads at startup so lessons don't get relearned from scratch.
Cursor tested the setup by handing four configurations the 835-page SQLite manual and asking for a Rust implementation, with no source code, no test suite, and no internet access allowed. The judge was sqllogictest, a benchmark the swarm didn't know existed. GPT-5.5 alone, Grok 4.5 alone, and two planner-worker pairings, Opus 4.8 with Composer 2.5, and Fable 5 with Composer 2.5, all ran under both the old and new architectures. After four hours, the new setups scored between 73 and 85 percent against the old setups' 11 to 77 percent, and every new configuration eventually reached 100 percent.
The old system's problem wasn't a lack of effort, it was too much of the wrong kind. The Grok 4.5 run under the old architecture produced 68,000 commits in two hours, about 70 times what the new system generated, and racked up more than 70,000 merge conflicts against fewer than 1,000 for the new run. One file alone drew 7,771 conflicts from 1,173 agents under the old system, versus 47 under the new one. The old run also splintered the project into 54 Rust crates; the new run settled on nine. Under the Fable 5 pairing, the old architecture needed 64,305 lines of engine code where the new one needed 9,908. Under Opus, the old system hit 97 percent with 19,013 lines, while the new one hit 100 percent with 4,645, a reduction in codebase size of as much as 85 percent for equal or better results.
Costs ranged from $1,339 for the Opus hybrid to $10,565 for GPT-5.5 running solo, a 15-fold spread for comparable quality. Workers ate at least 69 percent of tokens in every run, usually more than 90 percent, but planner tokens are pricier, so the bill split differently: in the Opus hybrid, the planner produced a small share of tokens yet accounted for two thirds of total cost. The gap traces mostly to worker pricing. GPT-5.5's workers alone cost $9,373; Composer 2.5, priced at $0.50 per million input tokens and $2.50 per million output tokens and reportedly built on Kimi K2.5 according to Cursor founder Michael Truell, ran the entire worker fleet for $411 at similar quality. Cursor's takeaway is that only a narrow slice of a big task, breaking it down and making key design calls, actually needs a frontier model; everything downstream can run on something far cheaper, though the Fable 5 pairing showed that a weaker planner can still cost more overall if its workers end up needing far more tokens to finish.
Cursor published the Opus solo run's codebase as minisqlite on GitHub, and the approach is already leaving the lab: a prerelease version of Fable 5 handled most of a rewrite of Bun from Zig to Rust, with 64 instances producing more than a million lines of code in 11 days for roughly $165,000. Reality outside these showcase runs looks messier. A study from late 2025 found that 68 percent of production agents complete no more than ten steps before a human has to step in, and for 47 percent the limit is fewer than five.
My take — AI-written commentary, not fact-checked reporting
The headline number here isn't the 100 percent benchmark score, it's the 15x cost gap between setups that landed in the same place. That's the real argument for cheap worker models: most of what agents do all day is grunt work, not genius work, and paying frontier prices for grunt work is just waste dressed up as rigor. But the closing stat about production agents choking after five to ten steps is the one worth sitting with, because it's a reminder that a gorgeous, purpose-built SQLite demo doesn't automatically survive contact with messy, real codebases and impatient humans in the loop.”
Read more about this at: The Decoder
