New agent swarm hit 100% on SQLite tests cheaper

Cursor says its latest agent swarm now performs the same large coding task with far less chaos — and much better results. In a new comparison, the company reran an old challenge that had previously exposed the limits of its system: building SQLite from scratch in Rust using only the 835-page SQLite manual, with no source code, test suites, SQLite binary, or internet access.

Using the same models and the same time budget, the new swarm outperformed the old one in every configuration. With Grok 4.5, the new setup reached 80% of a held-out SQL test suite in four hours, while the old swarm degraded badly enough that Cursor paused it before the two-hour mark. Across all new configurations, runs landed between 73% and 85% by the four-hour cutoff, versus 11% to 77% for the old harness. Cursor says every new configuration eventually reached 100% of the suite.

How Cursor changed the swarm

The core idea is a tree-shaped workflow. Planner agents using stronger models break a goal into subproblems, while worker agents using cheaper, faster models execute them. Cursor argues this matters less for parallelism than for context efficiency: planners avoid low-level implementation details, and workers avoid carrying the entire project plan.

Recommended reading

Anthropic’s $1.5 billion author settlement gets court approval

The company also rebuilt the infrastructure around the swarm. Its earlier browser-building experiment peaked at about 1,000 commits per hour on Git. The new system reaches roughly 1,000 commits per second, which led Cursor to build a custom version control system.

That system is meant to handle failure modes the company says appear at swarm scale, including:

• Split-brain design, where planners independently make conflicting architectural choices
• Planner contention, with agents repeatedly rewriting the same files
• Merge conflicts at a rate too high for ordinary tooling
• Megafiles that attract too many edits and become bottlenecks
• Ossification, where agents avoid touching core code even when it needs to change

Cursor also added layered review systems and a shared Field Guide folder that agents maintain for future runs.

What the SQLite runs showed

The benchmark used sqllogictest, a SQLite project test suite with millions of queries. Cursor says the swarm was not told the suite existed, and that each run was manually reviewed to check for shortcuts or test-specific overfitting.

The behavioral difference between old and new systems was stark. In the old Grok 4.5 run, agents produced 68,000 commits in the first two hours — about 70 times the pace of the new run — but also generated more than 70,000 conflicts before the run was stopped. The new run logged fewer than a thousand conflicts over the full four hours.

The old swarm’s package structure also sprawled. It created 54 crates, including three separate SQL packages. The new swarm settled on nine crates early and stayed there.

That showed up in code size too. In the Fable 5 mix, both old and new swarms eventually passed the full suite, but the old system needed 64,305 lines of engine code versus 9,908 for the new one. In the Opus mix, the old harness used 19,013 lines for a 97% grade; the new one used 4,645 lines and reached 100%.

The economics were just as uneven. Cursor says quality was broadly similar across model mixes, but cost ranged from $1,339 for the Opus 4.8 + Composer 2.5 hybrid to $10,565 for GPT-5.5 alone. Workers accounted for at least 69% of tokens, and more than 90% in most runs, but planner tokens drove a disproportionate share of spending. Cursor’s takeaway: use frontier models for decomposition and decisions, then hand the bulk of execution to cheaper models.