Cursor’s Swarm Rebuilt SQLite in Rust — the real cost math

Cursor’s agent swarm rebuilt SQLite in Rust from the 835-page manual alone — no source code, no test suites, no internet access — and every model configuration running on Cursor’s new orchestration harness eventually passed 100% of a held-out test suite the swarm was never told existed. That headline is real. The number attached to it in most coverage is not.

The figure being repeated across social feeds — “15x cheaper” — does not appear in Cursor’s post and does not reconcile with either of the two ratios Cursor’s own dollar figures support. Compare worker fleets alone and the spread is roughly 22.8x ($9,373 vs $411). Compare whole runs and it is roughly 7.9x ($10,565 vs $1,339). Those are different measurements of different things, and the gap between them is precisely where the useful lesson lives.

This post shows the arithmetic in the open, walks through the planner/worker architecture that produces it, translates Cursor’s five swarm-scale coordination failure modes into a checklist for teams running three agents rather than a thousand, and flags the methodological caveats that serious readers should carry into any decision this result informs.

The setup, per Cursor’s July 20 post: instruct an agent swarm to implement the entire 835-page SQLite manual in Rust, while withholding the SQLite source code, its test suites, the compiled binary, and internet access. Progress was graded against sqllogictest, the SQLite project’s own suite of millions of queries with known-correct answers — and the swarm was never told the suite existed.

The experiment is an explicit rerun of Cursor’s earlier browser-from-scratch swarm, documented in its Scaling Agents post — same task class, same models, same time budget — designed to isolate harness improvements from model improvements. Four model-mix configurations ran under the new harness, and it’s worth knowing one that didn’t: GPT-5.6 Sol was the originally intended frontier baseline, but Cursor dropped it after finding the model unusually sensitive to literal and emphasized wording, producing runaway spirals the team didn’t have time to prompt-tune for a model that had arrived so recently. GPT-5.5 took its place to keep the comparison fair. That is a methodology note about this specific harness, not a general verdict on GPT-5.6 Sol.

If you want the broader context on how Cursor got to swarms at all — the Agents Window, Composer, and cloud agents that preceded this work — Cursor’s agent-first architecture is the background read. A companion Cursor post, Self-driving codebases, documents the hill-climbing between the browser experiment and this rerun.

Here is what Cursor actually published. The run using GPT-5.5 for both planners and workers cost $10,565 in total, with $9,373 of that going to the worker fleet alone. The run using Opus 4.8 as planner and Composer 2.5 as worker cost $1,339 in total, with the entire worker fleet costing $411. Same task, same time budget, same eventual 100% grade.

Now the arithmetic that most coverage skipped. Divide worker-only costs and you get $9,373 ÷ $411 ≈ 22.8x. Divide total run costs and you get $10,565 ÷ $1,339 ≈ 7.9x. The widely shared ~15x framing — AlphaSignal’s same-day headline — matches neither. It reads like a rounding of two different, non-equivalent ratios into one shareable number. Cursor’s post never states it.

Why do the two ratios diverge so sharply? Because planners and workers have opposite cost profiles. Planner tokens are few but expensive; worker tokens are many but cheap. Swap frontier workers for Composer 2.5 and the worker line item collapses 22.8x — but the frontier planner stays in the bill, so the total-run ratio compresses to 7.9x. Neither number is “the” cost of switching; they answer different questions. If you are budgeting a fleet, the total-run figure is the honest one. If you are deciding which model executes leaf tasks, the worker-only figure tells you what the worker seat is actually worth paying for.

The architecture behind those numbers is strict role separation. Planner agents, run on the most capable models, decompose a goal into a task tree and delegate. Worker agents, run on faster and cheaper models, execute leaf tasks. The roles never blur — and that separation is what keeps each seat’s context clean.

The Fable 5 result deserves a second look, because it breaks the naive assumption that a better or pricier planner automatically produces a cheaper run. Fable 5 was more token-efficient in the planner seat than Opus 4.8 — yet its worker fleet burned several times more tokens downstream. The planner’s real output is not its own tokens; it is the quality and unambiguity of the instructions its workers receive. A plan that reads well but leaves workers iterating is more expensive than a plan that costs more to write and executes cleanly. When you evaluate planner models, measure downstream worker spend, not planner spend.

This is the same thesis Google is pushing from the model-vendor side — pricing Flash-Lite explicitly as a subagent tier so the frontier model plans while cheap models execute. We covered that half of the argument in our Flash-Lite subagent-economics analysis; Cursor’s experiment is the tooling-side confirmation, with a real workload and a real invoice.

Because the SQLite run reused the browser experiment’s models and time budget, every improvement isolates to the harness — the orchestration layer coordinating the swarm. The scale jump alone is striking: the earlier swarm peaked at roughly 1,000 commits per hour; the new one peaks at roughly 1,000 commits per second, a rate that forced Cursor to build a custom version-control system because Git could not keep up.

The head-to-head Grok 4.5 runs show what coordination is worth. The old harness produced 68,000 commits in its first two hours — around 70x the new run’s pace at the same point — before more than 70,000 accelerating merge conflicts forced a pause before the two-hour mark. The new harness logged fewer than 1,000 conflicts across its full four hours. Raw throughput without coordination isn’t speed; it’s expensive heat.

Read that last pair again: the Opus 4.8 mix went from 19,013 lines at a 97% grade to 4,645 lines at 100% — roughly a quarter of the code for a strictly better result. Coordination quality doesn’t just cut costs; it cuts the amount of software that exists to maintain afterward. This is the same lesson we found running our own writer pipeline — the orchestration layer, not the model, is where token spend is won or lost — documented in our harness-engineering token-spend research.

Cursor names five coordination failure modes it engineered against: split-brain design, contention between planners, merge conflicts, megafiles, and ossification. The post is written for 1,000-commits-per-second scale, but every one of these appears at 3-5 concurrent agents against a shared repo — which is where most teams actually operate. The first three columns below summarize Cursor’s account; the last is our translation for smaller fleets.

One more mechanism is worth stealing even at small scale: the shared, agent-curated Field Guide — a folder whose index.md is auto-injected into every agent’s context at start, capped by a line budget, where agents record surprises for future runs. Cursor explicitly compares it to the environmental signaling of ants and termites — stigmergy — coordination through a shared artifact rather than direct messages. A three-agent fleet with a shared, line-budgeted “gotchas” file gets a real fraction of that benefit for close to zero engineering.

The strongest caveat gets little airtime in mainstream coverage: SQLite is one of the most widely deployed pieces of software on earth, and its code and documentation are almost certainly present in every frontier model’s pretraining data. Withholding the source at run time does not withhold it from the weights. A highly-discussed comment in the Hacker News thread makes the point sharply: “The wording is designed to create a marketing impression that it can do spec-driven development for a novel project, but this example doesn’t actually support that.” What the experiment cleanly demonstrates is spec-following and execution at extraordinary scale — not invention of a system the models had zero prior exposure to. Extrapolate to your own undocumented, novel codebase with care.

The second caveat is provenance. StartupFortune’s July 21 analysis puts it plainly: “Cursor’s result is impressive. It is also Cursor’s own result, published by a company selling the tooling.” Cursor’s mitigations are real — manual review of each run for cheating and shortcuts, a public output repo, grading against SQLite’s own test suite — but this remains a vendor-published benchmark with no independent replication yet.

None of these caveats deflate the economics finding. The cost spread is internal to the experiment — every configuration faced the same task with the same pretraining advantage, so the 7.9x and 22.8x deltas measure the model mix, not the task’s difficulty. The caveats bound what the capability claim proves; they leave the cost lesson intact.

Cursor states the same swarm design is already applied internally — finding and fixing vulnerabilities in open-source software, raising test coverage on Cursor’s own codebase, generating billions of tokens of synthetic training data — and a companion post documents the pattern generalizing to GPU-kernel optimization. The architecture travels. Here is how the economics translate to fleets of ordinary size.

The forward projection worth making: planner/worker pricing is becoming the default shape of agent economics from both directions at once. Model vendors are shipping explicit worker-tier models, and tooling vendors are shipping the routing to exploit them — Cursor’s other cost lever, automatic model routing, is the per-request version of the same seat-assignment logic. We expect the gap between well-mixed and naively-mixed fleets to widen, not close, as worker-tier models improve faster than their prices rise — which makes model-mix discipline a standing line item, the argument we develop in our cost-optimization-as-discipline playbook.

And the closing thought from Cursor’s post is the one that outlives the benchmark: “We gave the swarm 835 pages of prose and it came back with a database. What was scarce in this experiment, and what we expect to be scarce in software engineering going forward, is the right description of intent.” The scarce input was never compute. It was the spec. If your organization wants help designing agent fleets — seat assignments, harness engineering, cost governance — that is exactly the shape of our AI transformation engagements.