Cursor Built SQLite From Scratch With an AI Swarm — And the Real Story Is the Money

Cursor gave an AI agent swarm 835 pages of SQLite documentation — no source code, no tests, no internet access — and said "build this." In Rust. From scratch.

Four hours later, it had a working database engine that passed 100% of a held-out test suite containing millions of SQL queries.

That's a good headline. But it's not the most interesting thing in their writeup. Not even close.

The interesting thing is what they spent — and what they didn't have to.

The setup

Cursor has been building what they call an "agent swarm": a system where AI agents cooperate to build complex software autonomously. Earlier this year, they ran a swarm that built a web browser from scratch. It worked as a proof of concept but, in their words, "fell far short of polished software."

So they went back to the drawing board, engineered the system more deliberately, and returned to a task the old swarm had struggled with: implementing all of SQLite in Rust, using nothing but the 835-page SQLite manual.

They ran both the old and new swarms on the same task, with the same models, same time budget. Then they graded the output against sqllogictest — a test suite from the SQLite project itself, with millions of queries and known correct answers. The swarm was never told the tests existed.

The new swarm won across every configuration. With Grok 4.5, it hit 80% in four hours. The old swarm spiraled so badly they had to pause it before its second hour.

Every model mix in the new swarm eventually passed 100% of the suite.

What "spiraling" actually looks like

Here's where it gets fun. The old swarm wasn't just producing worse code — it was producing dramatically more of it.

In its first two hours, the old Grok 4.5 run cranked out 68,000 commits. About 70 times the new swarm's pace. That sounds productive until you look at the merge conflicts: over 70,000 of them, accelerating rather than stabilizing. The single hottest file collected 7,771 conflicts, touched by 1,173 different agents.

The old run sprawled to 54 separate Rust crates, including three — three — different SQL packages. Three teams of agents, unaware of each other, had independently decided to build the same thing.

The new swarm settled on nine crates early and never added another. Its most contested file in the entire codebase saw 47 conflicts over the full run.

Same models. Same task. Same time. The difference was entirely in coordination.

They had to build their own version control

Git wasn't going to cut it. The browser swarm earlier this year peaked at roughly 1,000 commits per hour on Git. The new system peaks at around 1,000 commits per second.

So Cursor built a version control system from scratch. Not just for throughput — every change in the system flows through the VCS, so it's where collisions become visible first. Several of their coordination mechanisms live directly inside it.

The failure modes they engineered around are genuinely fascinating, partly because they're recognizable to anyone who's managed a human engineering team — just compressed into hours instead of months:

Split-brain design. Two planners, unaware of each other, implement the same concept differently in different parts of the codebase. (This is how you get three SQL packages.) Their fix was prompting: planners make design decisions themselves rather than delegating them, and they're required to ensure no two delegated subtrees decide the same question.

Contention. Two planners who do know about each other fight through back-and-forth changes on the same files. Merge tooling can't fix a disagreement — that's not a code problem, it's a reality problem. Their fix: agents record decisions in shared design docs, and code that depends on a decision carries a compile-checked reference back to its doc. When planners unknowingly contradict each other, a reconciler merges the docs and the references propagate the resolution downstream.

Megafiles. Some files become popular places to work. Each agent adds a little code, nobody's responsible for keeping the file small, and eventually you've got a 5,000-line monster that's expensive to transport, diff, and merge. Workers can now flag bloated files. Once flagged, commits are blocked and an outside agent decomposes the file into smaller modules.

Ossification. Agents learn from working in human codebases that you don't touch core code. So they don't — even when it needs to change. Cursor's fix is elegant: they license intentional breakage. An agent that judges a core change worthwhile can make a focused patch outside its scope, leave a comment explaining why, and let the compiler carry the change through the system. Everything depending on the old design fails to build. Each agent that hits the error finds the comment, reads the reasoning, and updates its own work.

There's a review system too — what they call "review lenses." No single reviewer catches everything, but decorrelated lenses stack, the way self-driving systems reach above-human reliability without any single perfect component. The compute spent on review is high return, because review is much cheaper than the work it audits.

They even gave agents their own shared documentation folder — a "Field Guide" — that agents curate themselves. The logic: model weights are frozen, so it's precisely the surprise encounters that are worth capturing for the next agent.

The part that actually matters: the money

Cursor tested four model configurations, ranging from a strong frontier model doing everything to hybrids where a frontier model planned and a cheap model executed. Every mix hit 100% on the test suite. The quality was similar.

The costs were not.

The cheapest run — Opus 4.8 as planner, Composer 2.5 as worker — cost $1,339. The most expensive — GPT-5.5 handling both planning and execution — cost $10,565. Same end result. Eight times the price.

The token breakdown tells you why. Workers carried at least 69% of the tokens in every run, and over 90% in most. But planner tokens cost more per unit, because planners run on frontier models.

Here's the number that should make you sit up: in the GPT-5.5 solo run, the workers alone cost $9,373. In the Opus 4.8 + Composer 2.5 hybrid, the entire worker fleet cost $411.

Same work done. Twenty-three times cheaper.

The insight is simple once you see it. Few moments in a large task genuinely require frontier intelligence: the original decomposition, the hard design decisions, certain trade-offs. Once a frontier model has collapsed the ambiguity into a detailed, explicit instruction, a cheaper model just has to follow it. The expensive model's job is to remove uncertainty. After that, execution is execution.

What this means for the rest of us

Cursor frames the trajectory as rising abstraction. Autocomplete let you work one line at a time. Early models raised that to a block. Agents raised it to a file or feature. With swarms, the unit of work becomes the spec.

They gave the swarm 835 pages of prose and got a database back. What was scarce wasn't compute or model capability — it was the right description of intent.

There's a deeper point here that Cursor's post gestures at but doesn't fully connect: this is why the "just use the biggest model for everything" approach is economically untenable for serious agent work. If you're running a single agent on a frontier model for hours, you're paying frontier prices for execution that doesn't need frontier intelligence. The swarm architecture isn't just about parallelism — it's about putting expensive compute where it matters and cheap compute everywhere else.

This maps onto a broader pattern we're seeing across the AI tooling space. The bottleneck isn't model quality anymore. It's orchestration — knowing when to use which model, how to split work, how to coordinate, how to verify. The teams winning right now aren't the ones with access to the biggest model. They're the ones who've figured out the plumbing.

The open-source angle matters too. If 90% of agent work can be handled by a cheap model following instructions, the bar for what "good enough" looks like drops dramatically. You don't need a $20/month API call for every step of a multi-agent workflow. You need one good decision-maker and a fleet of efficient followers. That's a world where local models, quantized models, and open-weights models aren't just "good enough for hobbies" — they're the economically rational choice for the bulk of real work.

Cursor open-sourced the output of their solo Opus 4.8 run at github.com/cursor/minisqlite. Worth a look if you want to see what an agent-written codebase actually looks like.

The takeaway

The SQLite result is impressive. Building a working database engine from documentation alone, in four hours, passing a real test suite at 100% — that's a milestone. It's the kind of thing that would've seemed impossible eighteen months ago.

But the result that will actually change how people build things is the cost chart. Eight times cheaper for the same output. Twenty-three times cheaper for the execution layer. The frontier model isn't doing less work — it's doing the right work, and delegating the rest.

If you're building anything with AI agents right now, the lesson is: stop thinking about which model to use. Start thinking about how to split the work. Your planner and your workers probably shouldn't be the same thing.

---

This is the philosophy behind CopperRiver — a desktop AI assistant that runs on your Mac, uses open-source models for the heavy lifting, and doesn't charge you frontier-model prices for execution. Plans start at $9/mo.