Cursor's agent swarms: how they rebuilt SQLite in Rust and what it reveals about the real cost of models

The article, published on Cursor's research blog on July 20, 2026 and written by Wilson Lin, describes a follow-up experiment to an earlier company project: a "swarm" of AI agents that earlier in the year had attempted to build a web browser from scratch. That first experiment, which Cursor itself described as purely empirical and built "blind" through trial and error, worked as a proof of concept but produced software far from polished. Since then, the team's stated goal has been to understand the behavior of these swarms well enough to design them deliberately, rather than letting them emerge by guesswork. To measure that progress, they returned to a task the original swarm had already struggled with: building SQLite —the database engine— entirely from scratch, in Rust, using only its documentation (835 pages), with no access to the original source code, the binaries, the test suites or the internet.

It is important to note, as a framing device, that this is a research article self-published by Cursor on its own corporate blog: it is not a peer-reviewed paper or an independent analysis, but the company itself presenting results from its internal experiments with its own product. That does not mean the data are false, but it is worth keeping in mind when assessing the performance and cost figures cited, since they come entirely from its own measurements.

The swarm's architecture rests on two distinct roles that mirror the tree structure large tasks naturally take on: "planner" agents, powered by the most capable models, which break an objective into pieces and delegate them; and "worker" agents, generally powered by faster, cheaper models, which execute those specific pieces. According to the article, this design is a more flexible superstructure than rigid orchestration systems: instead of imposing a fixed topology on the problem, the shape of the swarm grows to fit the contours of the problem, and compute and context scale in proportion to the complexity of the task. Cursor argues this is why the design generalizes well to tasks as varied as building a browser, solving math problems, optimizing GPU kernels, finding and fixing vulnerabilities in open-source software, increasing test coverage of its own code, or generating billions of tokens of synthetic training data.

A central idea in the article is what this tree structure contributes to agents' memory management. When a single agent takes on an entire task, it has to walk the whole tree by itself, descending into each concrete task while keeping in context the ancestors, its current position and the overall objective. Cursor proposes that this explains why individual agents working over long stretches tend to "drift": either they focus on the immediate work and lose sight of the big picture, or they hold on to the big picture and do the concrete work worse. In a swarm, by contrast, a planner never implements, so its context never fills up with low-level detail, and a worker never plans, so it can devote its entire context to a bounded piece of work. The article suggests that this context efficiency —more than parallelism itself— is what allows the swarm to scale, and that the benefit shows up at any scale, even on moderately sized tasks. As a conceptual parallel, they cite economist Ronald Coase and his question about why firms exist: coordination costs grow faster than the work itself, so organizations settle into bounded hierarchical levels instead of letting everyone talk to everyone.

Another relevant technical point is that Cursor had to build its own version control system (VCS) from scratch for the swarm, because tools like Git or Cargo rely on coarse-grained locks that work fine for a single human developer but are unworkable for the volume of activity of hundreds of concurrent agents. According to the article, the browser swarm from earlier in the year peaked at roughly 1,000 commits per hour on Git; the new system peaks at around 1,000 commits per second. Beyond the need for greater throughput, owning this layer mattered because every change in the system passes through the VCS, which is where collisions first become visible, and several of the swarm's coordination mechanisms are implemented directly there.

At that rate of activity —they note— failure modes appear that human engineering teams, working at a much slower pace, rarely encounter, and which required specific solutions:

- "Split-brain" design: two planners, unaware of each other, implement the same concept in different ways in different parts of the code. They solved this through prompting: planners make design decisions themselves rather than delegating them, and are required to ensure that no two delegated subtrees decide the same question.

- Contention between planners: a harder form of conflict arises when two planners do know about each other and "fight" through successive changes to the same files. The problem, they note, is two different views of reality, something no code merge tool can fix on its own. The solution was to have agents record their decisions in shared design documents; code that depends on a decision carries a compiler-checked reference to that document, and when planners contradict each other unknowingly, a "reconciler" agent merges the documents and that resolution then propagates through the references.

- Merge conflicts: inside the swarm, agents collide constantly over the same files, and to resolve a collision they would have to stop, absorb the other agent's context and merge around it; worker agents are bad at this and, in practice, either overwrite the other's change or abandon their own. The solution was to create a "neutral third party" agent that steps into merge conflicts and resolves them on behalf of all parties, with the sole goal of being impartial and efficient, much like merge queues work in human engineering teams.

- "Megafiles": some files become especially popular places where many agents work; each adds only a small amount of code and no particular agent is responsible for keeping them small, so these giant files "clog" the whole system: they are expensive to transport, diff and merge, and become constant hotspots for collisions. The solution was to give workers a way to flag bloated files; once flagged, new commits to them are blocked and an outside agent breaks the oversized file into smaller modules.

- Ossification: from working in existing codebases with humans supervising, agents have learned not to touch core code even when it needs to change. Cursor decided to "license intentional breakage": an agent that judges a core change to be worthwhile can make a focused patch outside its scope and leave a comment explaining why. The compiler propagates the change through the rest of the system and everything that depended on the previous design stops compiling; each agent that runs into one of those errors finds the comment, reads the reasoning and updates its own piece of work to fit the new design.

The article also devotes a section to what they call "review lenses". In a system that is both long-running and multi-agent, errors accumulate, and the swarm needs to correct itself before small faults become defective foundations. Cursor experimented with many kinds of review: giving a reviewer agent the worker's full transcript, or only its final output, or nothing but the codebase itself; they also tried reviewers running on different models, with different training and "personality". No single lens catches everything, but uncorrelated lenses add up, much as self-driving systems achieve better-than-human reliability without any individual component being perfect. According to the article, compute spent on review has a very high return, because reviewing is far cheaper than the work being audited, and they suspect this stacked review system was an important factor in the sustained quality of the runs.

Another novel element they describe is letting the agents themselves shape their working environment, drawing on "stigmergy", the mechanism by which organisms such as ants or termites coordinate their behavior without direct communication: they modify the environment, and the environment modifies the next organism. In earlier runs they had already hard-coded rules like "take notes" or "document decisions" because they seemed obviously good; in hindsight, they say, these rules let agents institutionalize knowledge for their future versions and teammates. They took the idea further with an experiment in shared context written by the agents themselves, which they call the "Field Guide": a folder that belongs entirely to the agents, whose index file is automatically injected at the start of every agent, and which the agents themselves must curate, with a line budget as the only constraint. The underlying logic is that the model weights are frozen, so what is worth capturing is precisely the surprising encounters, so that the next agent's trajectory is shorter. Cursor describes it as an early experiment with promising results, and anticipates even greater benefits in codebases the agents do not fully control, pointing to training models specifically to write with their "successors" in mind as a future research direction.

The article's central experiment consisted of instructing this new version of the swarm —with all the improvements described— to implement the entirety of the SQLite manual (835 pages) in Rust, with no source code, no test suites, no original binary and no internet access. To measure progress they used sqllogictest, a test suite from the SQLite project itself designed to check that different database engines return the same results for the same queries; it contains millions of queries with known correct answers, and the score is the fraction the swarm-built database gets right. The swarm was never told that this test suite existed. After each run they manually reviewed the code and the process, checking that there was no cheating or shortcutting and confirming that the system had been built evenly and not only in the areas the tests evaluate. They also highlight that the agents chose their own strategies: some built broad foundations and scored low for hours before a late surge, while others went deep on one specific area, scored early and then plateaued while filling in the rest; according to the article, trends matter more than exact scores at any given moment.

Four model configurations were tested, combining capability and cost: (1) GPT-5.5 as both planner and worker, described as a powerful frontier model end to end; (2) Grok 4.5 as planner and worker, presented as Cursor's most cost-efficient frontier model, used as a benchmark; (3) Opus 4.8 as planner alongside Composer 2.5 as worker, combining a frontier model's judgment with efficient execution; and (4) Fable 5 as planner alongside Composer 2.5 as worker, to test whether a higher-tier planner makes the hybrid combination more or less cost-effective. (Opus is Anthropic's flagship model family and GPT is OpenAI's; these are publicly known links that the article does not spell out. The source does not detail the origin of Composer 2.5 or Fable 5, and refers to Grok 4.5 as "our" cost-efficient frontier model).

The new harness beat the old one across every combination tested. The Fable 5 combination cleared roughly two thirds of the test suite within the first hour. At the four-hour cutoff, the new runs landed between 73% and 85% correct, versus a range of 11% to 77% in the old runs; the old Grok 4.5 run had to be paused before reaching two hours because the process ran away. Each new configuration went on to reach 100% of the test suite. The article notes that, for this cycle, the relevant comparison is between harness versions (old vs. new) rather than between models, and that the differences in behavior turned out to be far larger than the score differences suggest. In a footnote, the authors explain that they originally wanted to include a model called GPT-5.6 Sol as the frontier configuration, but that this model seemed more sensitive to literal wording and emphasis in the text than the other models tested, producing "runaway spirals" not seen with other models; with no time to tune the instructions for a model that had arrived so recently —and not wanting to bias the comparison by tuning them for just one— they opted to replace it with GPT-5.5.

The article then digs into the specific run data. Comparing Grok 4.5's activity under the old harness versus the new one: the old run produced 68,000 commits in its first two hours, a rate roughly 70 times that of the new run. The authors offer two possible readings: either that activity was more productive, or most of those commits were unproductive work (friction, contention, churn). The merge-conflict data point to the second interpretation: the old run racked up more than 70,000 conflicts before being paused, accelerating rather than stabilizing, while the new one logged fewer than a thousand conflicts across its full four hours. Conflicts concentrated where files grew most: in the old run, the largest files kept growing throughout, and its most conflict-prone file accumulated 7,771 conflicts, touched by 1,173 different agents; in the new run, the most contested file in the entire codebase logged just 47 conflicts.

The old swarm's biggest coordination failure —"split-brain", that is, planners duplicating each other's work— showed up in the package structure (crates, in Rust terminology), where in a project of this kind each crate corresponds roughly to one main component. The old run sprawled to 54 crates, including three separate SQL packages; the new run settled on nine crates from the start and never added another. All of this is reflected in the final size of the code: in the Fable 5 combination, both the old and the new swarm ended up passing the full test suite, but the old one needed 64,305 lines of engine code versus 9,908 for the new one. The Opus combination showed a similar pattern: 19,013 lines with a 97% score under the old harness, versus 4,645 lines at 100% under the new one.

A particularly relevant part of the article is the section on model economics. Although all model combinations produced similar quality, costs varied enormously: from $1,339 for the Opus 4.8 hybrid combination to $10,565 using GPT-5.5 alone. The token data show where that difference comes from: the structure of spending was consistent across all runs, with workers accounting for at least 69% of tokens (and more than 90% in most cases); yet the dollars split differently from the tokens because planner tokens are more expensive. In the combination of Opus 4.8 as planner and Composer 2.5 as worker, Opus produced a small fraction of total tokens but accounted for roughly two thirds of the cost, while Composer, as worker, handled the vast majority of tokens for the remaining third.

According to the article, very few moments in a large task genuinely require frontier-level intelligence —such as the initial decomposition, design decisions or certain trade-offs—; once a frontier planner has reduced the ambiguity to an explicit, detailed instruction, cheaper models simply have to follow it, which represents an enormous source of potential cost savings. As a concrete example: in the run where GPT-5.5 acted as both planner and worker, the workers alone cost $9,373; in the run where Opus 4.8 planned and Composer 2.5 worked, the entire worker fleet cost $411. One further detail they note when comparing the two hybrid combinations: the Fable 5 planner generated a slightly smaller bill than the Opus 4.8 planner, despite a per-token price roughly twice as high, because it used far fewer planning tokens; however, the workers in the Fable run consumed several times more tokens, so that run as a whole came out substantially more expensive.

The article closes with a conceptual reflection under the heading "specs as prompts". It argues that each leap in AI capability has raised the level of abstraction at which an engineer can work: autocomplete allowed line-by-line work; the first models raised that to a block of code; agents raised it to a file or a feature; and with swarms, the unit of work becomes the full specification (spec). For this to work, the swarm has to be genuinely capable of following that spec, which is what much of the article is about. They gave the swarm 835 pages of text and got a database back; what proved scarce in this experiment —and what they expect to be scarce in software engineering in the future— is the correct description of intent. Seen this way, the swarm starts to look like a compiler: a compiler translates source code into machine code through a series of intermediate steps, and the swarm does something similar with intent, where planners translate an objective into task trees and then reduce it step by step to executable work. The difference, they stress, is that a compiler preserves meaning at every step, while the swarm is probabilistic at each one; according to the authors, everything described in the article —the version control systems, the anti-collision mechanisms, the review lenses, the field guide— exists precisely to close that gap.

As a practical closing note, Cursor invites readers to explore the swarm's output for themselves: the code from the solo Opus 4.8 run is published in the repository github.com/cursor/minisqlite. At first glance, they say, the result "looks great", but they explicitly clarify that they have not done a deeper manual analysis, and they invite third parties to review it and report what they find. In addition, to have a reference point for the cost of using frontier models on their own, they also ran Opus 4.8 and Fable 5 solo; those runs were only graded informally, so the authors say they draw no conclusions about their quality, though from previous experience they would expect both models to perform well; their costs are shown as hatched bars in the charts in the original article.

Taken together, the article defends a clear thesis, consistent with the title chosen for this summary of the source: orchestration —how planning and execution roles are divided among agents, how collisions are managed at high speed, how work is reviewed and how knowledge is shared between agents— can matter as much as or more than the size or raw power of the underlying model in determining both the final quality of the software produced and, above all, its cost. The combination of an expensive planner used sparingly alongside cheap workers used in volume emerges, by their own data, as the cheapest path to results equivalent to using a frontier model end to end. These figures should be read for what they are, though: results from the internal experiments of a company that sells precisely coding-agent tools, presented on its own blog without independent external review.