Agent swarms and the new model economics

Wilson Lin on rebuilding Cursor’s agent swarm around a split between planning and execution: frontier models as planners that decompose a goal into subtasks, cheaper and faster models as workers that carry them out. The supporting machinery is the interesting part, including a custom version control layer taking about 1,000 commits per second, shared design documents with compile-checked references, neutral third-party agents to settle merge conflicts, and automatic file decomposition so no file becomes the thing every agent fights over.

The test was to implement the whole 835-page SQLite manual in Rust. With Grok 4.5 the new swarm reached an 80% test pass rate in four hours, where the old swarm spiralled and had to be paused before its second hour. The coordination gap is the clearest evidence: the old two-hour run produced 68,000 commits and over 70,000 merge conflicts, with its hottest file hitting 7,771 conflicts across 1,173 agents, while the new four-hour run stayed under 1,000 conflicts with a hottest file at 47.

The economics argument follows from the split. Once a capable model is doing the planning, workers can be cheap without losing much, and workers carried between 69% and over 90% of tokens across runs. GPT-5.5 in both roles cost $10,565; an Opus 4.8 planner with Composer 2.5 workers cost $1,339, of which the entire worker fleet was $411. Output got tighter too, with the Fable 5 hybrid needing 9,908 lines at full pass rate against 64,305 for the old version, and the crate count settling at 9 rather than sprawling to 54.

With swarms, the unit of work becomes the spec.

Cursor benchmarking its own system, so treat the comparison with the usual caution. The code from the solo Opus 4.8 run is public at cursor/minisqlite. See also their later note on the cloud agent environment.