Robert Ta explains how Cursor rebuilt SQLite with AI agents at costs ranging from $1,339 to over $10,000, then cut expenses by 18-20 times by pairing expensive models as planners with cheaper ones as workers. The real bottleneck isn't model knowledge but writing precise specs detailed enough for agents to follow reliably.
Cursor rebuilt SQLite 6 ways and the cost ranged from $1,339 to over $10,000 on the exact same task. And here's what it means for engineering leaders staring at their runaway AI bills. And for a lot of people out there, we've talked about this before and people show up in the comments and they're like, well, it was trained on SQLite. It knows about SQLite. It's like, yeah, that's not really the point of these benchmarks. Like a benchmark is a benchmark. It's not perfect. I'm just going to say that. But what these benchmarks do, and I'm glad Cursor did this research, is because we're builders, Trying different metas. So they actually experimented and showed the cost efficiencies or lack thereof of this particular meta of let's just let a frontier intelligence run away and rebuild SQLite. And you see Fable 5 at $20,000 in cost, GPT-5 at about $10,000, Opus 4.8 at $5,000. So the question becomes, can we get the same result using a different meta, which is the frontier intelligence is the brains and the lower cost models are the hands? So what Cursor indeed found is you could do this, like Opus 4.8 and Composer 2.5 together as like planner and worker here. You can get it down to, looks like about an 18th to 20th of the cost. And this is one use case understood, but this is how it kind of looks. And I thought this was really interesting is the agent swarm concept. They talk about specs as prompts. So each jump in AI capability, this is from Cursor. Has raised the level of abstraction at which an engineer can work. Autocomplete let engineers work one line of code at a time. Early models raised that to a block of code, and agents raised it to a file or a feature. With swarms, the unit of work becomes the spec. For that to work, the swarm has to actually follow the spec, which is what much of this post is about. In all of traditional software development, it always comes down to how good are the requirements, how well understood is the specification, and if you have hundreds of engineers working on it, are they actually following the spec? And so you can of akin this to, well, if we had a bunch of engineers, we got a cat herd towards a specific spec. This is just cat herding your agents, like with swarms, right? So Cursor says, 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. Seen this way, the swarm starts to resemble a compiler. A compiler translates source code down to machine code through a series of intermediate steps. The Swarm does something similar with intent. Planners parse a goal into task trees, then lower it step by step into executable work. The difference is that a compiler preserves meaning at every step while the Swarm is probabilistic at every one. Everything described in this post— my cursor— exists to close that gap. They actually have the Swarm output here, which is really cool. You can go take a look at their SQLite implementation from this 830+ pages of prose. I will say I have never written an 835-page spec. But now it's making me think, holy shit, maybe I should be.
