Jul 26, 2026
AI

Cursor agent swarm SQLite test points to cheaper AI coding model mix

Cursor says its planner-worker agent system rebuilt SQLite in Rust, with hybrid runs cutting token costs versus frontier-only coding.

Colin Brandt

By Colin Brandt · Enterprise Reporter

· 4 min read

Cursor agent swarm SQLite test points to cheaper AI coding model mix
Photo: The Decoder

Cursor agent swarm SQLite testing suggests Anysphere's coding product can shift much of AI coding work to cheaper models when frontier models are used for planning, according to Cursor. The company said an upgraded swarm rebuilt SQLite in Rust from the 835-page SQLite manual, without source code, the SQLite binary, test suites or internet access, and every configuration of the new system eventually reached a 100% score on sqllogictest.

The experiment is relevant to AI coding economics because the lowest-cost hybrid run cited by Cursor cost $1,339, while GPT-5.5 running alone cost $10,565. Cursor also listed a Fable 5 solo run at $20,057 in its cost comparison. Those figures are company-reported benchmark costs, not production margins, and Cursor did not say how the results would translate to ordinary enterprise codebases with human review, legacy dependencies and security constraints.

How did Cursor's agent swarm work?

Cursor split the system into planner agents and worker agents. Planners used stronger frontier models to break the goal into smaller jobs and make design decisions, while workers used faster and cheaper models to carry out the assigned tasks.

Cursor said the split was meant to reduce context pressure. A single long-running agent has to hold the broad objective and the current implementation detail in the same context window, which can lead to drift. In the swarm design, planners did not write code and workers did not plan, creating a task tree that changed as work progressed.

The company also changed the collaboration layer after an earlier browser-building swarm ran into coordination problems. Cursor said its prior system used worker agents, a judge and an integrator, but the integrator became a bottleneck. The new system reached 1,000 commits per second, according to Cursor, forcing the company to build its own version control system because Git was not built for that operating rate.

Cursor described one failure mode as “split-brain design,” where planners independently built the same idea in separate places. To reduce that, agents wrote decisions into shared design documents, and code tied to those decisions linked back to the relevant document through a compile-time check. A neutral agent handled merge conflicts, while other agents could flag bloated files for splitting into modules.

Cheaper workers changed the cost curve

Cursor tested GPT-5.5 solo, Grok 4.5 solo, Opus 4.8 as planner with Composer 2.5 as worker, and Fable 5 as planner with Composer 2.5 as worker. After four hours, the new system scored between 73% and 85%, while the older swarm scored between 11% and 77%. Cursor said every new-system configuration later reached 100%.

The Grok 4.5 comparison shows why raw agent activity is a poor proxy for progress. Cursor said the old swarm produced 68,000 commits in two hours, roughly 70 times the new system's output, while accumulating more than 70,000 merge conflicts. The upgraded system stayed below 1,000 conflicts during the test.

The architecture also produced smaller codebases in Cursor's runs. With Fable 5 and Composer 2.5, the old swarm needed 64,305 lines of engine code, compared with 9,908 for the new system. With Opus, the old system produced 19,013 lines and scored 97%, while the new system reached 100% with 4,645 lines.

Cursor said worker agents consumed at least 69% of tokens in every run and usually more than 90%. That made worker pricing the main cost lever. In the GPT-5.5 run, workers alone cost $9,373, while the entire worker fleet in the Opus-and-Composer run cost $411 at comparable quality, according to Cursor. Cursor has said Composer 2.5 costs $0.50 per million input tokens and $2.50 per million output tokens, and founder Michael Truell has said the model is based on Kimi K2.5.

The result supports Cursor's argument that a small number of planning steps may justify expensive models, while execution can often be assigned to cheaper models once the ambiguity is removed. Planner quality still mattered in the test: Cursor said the Fable 5 planner used fewer planning tokens than Opus, but its workers needed more tokens to finish, making the overall run more expensive.

Cursor published the Opus solo run as minisqlite on GitHub. The broader production caveat remains: a late-2025 study cited by The Decoder found that 68% of production agents completed no more than ten steps before a human intervened, and 47% stopped before five steps.

This story draws on original reporting from The Decoder.

More from AI

All AI →