Robert Ta and Jonathan show how Cursor's agent-swarm system rebuilt SQLite in Rust for $1,339 using cheap worker agents plus one high-capability planner, versus $20K for a single expensive model. Pairing a frontier planner with cheaper workers cuts costs by 8x while maintaining quality.
Cursor had an agent swarm implement SQLite in Rust from scratch against an 835-page manual graded by SQL Logic Test. The cost to rebuild the SQLite by model mix, you could see Fable 5 here with the highest cost, $20,000. Lowest cost, Opus 4.8 plus Composer 2.5, where they split up the workloads to rebuild SQLite. That came in at almost at a LEET score, actually $1,339. So only $2 off of LEET. That's kind of cool. Real quick, That's fun. The architecture was planner agents being the frontier models. They decompose goals. Worker agents, fast, cheap models, execute on them. And Wilson Lin says a planner doesn't implement, so its context never fills with low-level detail. Worker never plans, so it can spend all its context on one narrow piece of work. And that was the architecture they went for. They saw that GPT-5.5 alone burned 14.7 billion tokens and Fable 5, 12.2 billion tokens. Tokens. And the Frontier as planner plus cheap worker mix delivered near identical quality at 7.9x lower cost than Frontier only. Quote, once a Frontier planner has collapsed the ambiguity into a detailed explicit instruction, less expensive models simply have to follow it. And the quality bar— the new swarm hit 100% test pass on the Fable-5 mix using 9,908 lines of code versus 60 4,000 lines of code for the old Swarm, which is about 6.5x less code. So the thesis is really that frontier for planning and orchestration, and then lower-level models that cost less for the actual implementation could work really, really well. Jonathan, from your CTO perspective, what does this say from Cursor around the whole narrative around like token maxing and stuff like that? You and I have talked about that a lot, but it's clear that they've proven out this meta of frontier planning Personally, in my work, I've been using Fable 5 as a planner and then GPT-5.6 SOL as like the implementation.
I know it's not the cheapest way to get it done, but for unbound planning, especially creative planning, Fable is like a really great model. And then it can either orchestrate other agents or run them. So here they showed their own Composer 2.5 working with Opus 4.8. That was the cheapest one, right? And I think Opus 4.8 on a bounded task, like with literally create something with a fixed spec, is actually a pretty good model to do that. And Fable 5 is a really good model to do that. is kind of like overkill, you know, there's not enough creativity needed, you know, where Fable can really sort of show its value. And I think you could see that I would use Fable in something where it could produce a better result than Opus 4.8 and expect to see results there. It's curious they didn't try with just Cursor 2.5 alone. I wonder what's up with that. Like if it just isn't well suited for sort of like the planning and orchestration tools. But, uh, yeah, these are exactly the kind of experiments you're kind of like running every day as a builder right now. Right. Um, and they just did it, uh, at scale and put some numbers to it and It's really helpful for the rest of us.
I like this section here, specs as prompts. Each jump in AI capability has raised the level of abstraction at which an engineer can work. Autocomplete let engineers work one line of code at a time, and early models raised that to a block of code, and agents raised it to a file or a feature. I love that breakdown. With swarms, the unit of work becomes the spec. We talk about this a lot, but spec-driven development is really the meta that I've seen stick for the past year. For people to coordinate their actual coding agent workflows and hold them accountable to verifiable tests and exit criteria. So anyway, for that to work, the swarm has to actually follow a spec, which is what much of this post is about. 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. That's a really great way of putting it. It does just come down to, are you good at English and articulating your goals and then also working with, say, like a coding agent from a planning perspective on unbound creative sort of planning tasks where you're doing some iterations and then you come out with your intent at a higher fidelity through those cognitive loops with your coding agent.
