Agent Swarms and the New Model Economics: Cursor's SQLite Experiment in Rust

Overview and Takeaway

Cursor’s updated agent swarm outperformed its predecessor on every tested model mix, delivering higher SQLite test scores, far fewer lines of code, and dramatically lower compute cost while eliminating the thrash that stalled the old swarm.

Agent Swarm Design: Planner and Worker Roles

Separating planning from execution improves context efficiency and lets the swarm scale to complex tasks. Planner agents, powered by the smartest models, decompose a goal into a task tree and delegate pieces; worker agents, powered by faster, cheaper models, execute those pieces without needing to hold the full goal in context.

Version Control System for High Commit Rates

To sustain the swarm’s commit rate of about 1,000 per second, Cursor built a custom version control system from scratch. This VCS surfaces collisions immediately and hosts several coordination mechanisms directly, enabling the swarm to operate at a rate far beyond what Git could handle.

Failure Modes and Mitigations

The swarm encountered specific failure modes at high commit rates, each addressed with a targeted fix. Split‑brain design was prevented by requiring planners to make design decisions themselves and ensure no two delegated subtrees decide the same question. Contention between planners was mitigated by having agents record decisions in shared design docs with compile‑checked references, allowing a reconciler to merge docs and propagate resolutions. Merge conflicts were resolved by a neutral third‑party agent that intervenes impartially. Megafiles were curbed by letting workers flag bloated files, after which an outside agent decomposes the file into smaller modules. Ossification was countered by licensing intentional breakage: an agent that judges a core change worthwhile makes a focused patch outside its scope, leaves a explanatory comment, and lets compiler errors guide teammates to update their work.

Review Lenses and Stigmergy

Stacked review lenses and stigmergic knowledge sharing raise sustained quality in long‑running multi‑agent runs. Review lenses—agents examining transcripts, outputs, or codebase with different models and personalities—catch different error types, and their combined use yields high return because review is cheaper than the work audited. The Field Guide, a self‑authored shared context folder whose index.md is injected into every agent, lets agents institutionalize surprising encounters for future teammates, shortening subsequent agent trajectories.

SQLite Experiment Methodology

The swarm was tasked to implement the full SQLite specification in Rust from documentation only, with no access to source code, test suites, binaries, or the internet. Progress was measured against the sqllogictest suite, which contains millions of queries with known correct answers; the grade is the fraction of queries the swarm’s database answers correctly. The swarm was never told the test suite existed, and post‑run manual reviews confirmed no cheating or shortcuts.

Results Across Model Mixes

Every new harness configuration surpassed the old harness in test coverage, code efficiency, and cost. Using Grok 4.5, the new swarm reached 80% of the suite in four hours while the old swarm stalled before its second hour. At the four‑hour cutoff, new runs scored between 73% and 85% across mixes, whereas old runs ranged from 11% to 77%. All new configurations eventually achieved 100% passage. The Fable 5 hybrid passed about two‑thirds of the suite in‑hour mark. Code required far fewer lines: the Fable 5 mix needed 9,908 lines of engine code versus 64,305 lines in the old mix; the Opus mix needed 4,645 lines at 100% grade versus 19,013 lines at 97% under the old harness.

Deep Dive into Activity Metrics

The new swarm produced far fewer commits and conflicts, indicating reduced thrash and more purposeful work. The old Grok 4.5 run generated 68,000 commits in its first two hours—roughly 70 times the pace of the new run—while accumulating over 70,000 merge conflicts before being paused. The new run logged fewer than a thousand conflicts over its full four hours. The old run’s hottest file collected 7,771 conflicts touched by 1,173 agents; the new run’s most contested file saw only 47 conflicts. Crate proliferation also dropped: the old run sprawled to 54 Rust crates, including three separate SQL packages, whereas the new run settled on nine crates early and never added another.

Model Economics

Cost varied enormously across model mixes while output quality remained similar, driven by the high price of planner tokens. The least expensive configuration was the Opus 4.8 planner with Composer 2.5 worker at $1,339; the most expensive was GPT‑5.5 acting as both planner and worker at $10,565. Across all runs, workers consumed at least 69% of tokens and over 90% in most cases, but planner tokens carried a disproportionate share of cost because they are priced higher. In the Opus‑Composer mix, the planner supplied a small fraction of tokens yet accounted for roughly two‑thirds of the total cost, while the worker fleet handled the bulk of tokens for the remaining third of cost. The Fable 5 planner, despite a higher per‑token price, used fewer planning tokens than Opus 4.8, but its workers consumed several times more tokens, making the overall run substantially more expensive.

Specs as Prompts and Compiler Analogy

The swarm treats a specification as a prompt, lowering abstract intent into executable work through a series of steps analogous to a compiler’s passes. Planners parse the goal into a task tree and progressively refine it into detailed instructions that workers can follow. Unlike a compiler, which preserves meaning deterministically at each stage, the swarm is probabilistic at every step; the mechanisms described in this post aim to narrow the gap between intent and implementation.

Community Reactions

HN commenters expressed excitement about the experimental approach while raising questions about training data, cost, and harness transparency. One comment noted: "Love to see these crazy kinds of experiments going on. Even if this doesn’t 100% work or is prohibitively expensive for now, these are glimpses into the future..." Another questioned whether the models might have memorized SQLite’s source: "Isn’t SQLite’s source code in its training data?" and "How do we know if these models weren’t trained on Turso’s rewrite of SQLite in Rust?" A different comment highlighted the novelty of the custom VCS: "To facilitate this rate of activity, we built a new version control system (VCS) from scratch... Talk about inventing the universe to make a button." Some remarked on the cost: "The issue is that the only models that could be trusted to work autonomously cost more than a human employee." Others wished for more harness code sharing: "I would have loved to see more of the harness engineering shared as code." A few drew parallels to prior work: "This is almost a year behind Steve Yegge’s first post on beads..." Overall, the discussion reflected both enthusiasm for the swarm’s potential and skepticism about its generalizability and accessibility.

Outlook

Future work includes running the full N×N matrix of planner‑worker model combinations to better map cost‑performance tradeoffs, and applying the swarm to tasks that require integrating multiple existing technologies rather than rewriting from scratch. The team also plans to open‑source more of the harness infrastructure to enable broader experimentation.