Cursor Team Proved Harness matters more than Models

[00:00:00]The cursor AI team rebuilt SQLite from scratch in Rust using a swarm of agents with different agents configuration from using Fable 5 with composer to using Grock 4.5 with composer a bunch of combinations. And the intriguing part really is that when they tried to use Fable 5 both as a worker and as a planner like it cost them more than $20,000 in tokens. That is just insane.

[00:00:24]And they got the exact same results when they tried it with like Opus 4.8 ace as a planner with composer 2.5 which is pretty cheap as the executor or worker and it costs like 20 times less with only $1,000 in tokens. So now the real question why would you use a frontier model like feeble 5 or ous 4.8 to rebuild everything from scratch instead of just using the combination of a frontier model used for planning and a smaller much cheaper and easier to manage and work with model like composer 2.5 or Groank for execution. It is just insane. So the backstory all started when the cursor AI team started experimenting with swarm agents and swarm systems because earlier this year exactly in January 14, 2026, so 7 months ago, like the team started to run experiments to test the limit of scaling agents to cooperate toward a goal. You can imagine this experiments to make it look like a real developer team with like managers and actual developers at front end, back end, those kind of stuff. And they had a hypothesis in here that this would unlock a new tier of task scale and complexity. The flagship project they worked on on January 2014 through 2026 was a longunning swarm building a web browser from scratch and it succeeded as a proof of concept because a browser is literally a very big thing and very complicated. Also building it from scratch using agents in January like 7 months ago when we didn't have the capabilities that we do have nowadays is just fascinating to say the least about it. And as they were mentioning, they took a lot of time to actually rebuild and improve the swarm agents compared to the previous one. You know, the system that they used to rebuild a browser from scratch or build a browser from scratch from an empty canvas. Now, this new agent swarm is much more capable and they wanted to test the progress of this. So they returned to the old swarm task that the old swarm has actually struggled with which is building SQLite from scratch because they ran this test with the original swarm like the v1 of agent swarm and it failed miserably. So now they wanted to rebuild SQLite in Rust from nothing but its documentation and the manual. And they mentioned in here that the new swarm did it better in every model configuration using Grog 4.5 and it reached 80% in 4 hours. 80% success rate in the test suit while the or swarm spirald and had to be caught paused before its second hour. And honestly, what they did is actually pretty fascinating. So, I would really love to look at the swarm ages if they ever get a chance to release it to the public as open source as a standalone product because when you read the article in here and understand how they built it step by step and the theory behind it, the planning, the different uh strategies are going behind the scenes, it's just insane. So first of all in here like how the swarm agent works. It's it's it's something that you wouldn't actually think of but it's basically I would say the right choice.

[00:03:19]It uses tree and leaves for coordinating between different agents and more specifically coordinating between a planner agent and worker agent. So let's say you've got a planner agent as a fable file that creates the plans and you can use composer 2.5 or grock or some other cheaper models as worker agents where they take those plans from the leaves and implement them. And this section explains why they chose trees.

[00:03:42]What exactly a tree structure does from memory. For instance, if you imagine a single agent here that takes to complete a task, it has to walk the entire tree itself descending to each leaf while holding its ancestors, its current position, and the wider G in context the whole time. Even though that agent has a 1 million context, if the project is big enough, it wouldn't be able to hold the entire context of the entire project on its cognitive memory. And the agents would eventually drift and write bad code or write something or build something that you didn't ask for initially or simply maybe just start hallucinating and creating bad things and bugs. And that's why it actually explains why longunning single agents drift. They can either focus on work in front of them and lose sight of a bigger picture or hold the big picture and do a worse job at the one piece they have given. And in a swarm here, what they've actually implemented is a planner never implements. So its context never fills with low-level detail. It only stays or sees the bigger picture. And a worker never plans, never sees the bigger picture. It it's given like small tasks that the worker just picks up and go ahead and blindly implement those because technically those small cheaper models are are just basically not as capable and they can't hold a lot of context at once. It just makes it better as well for them to just pick a couple of tasks or one specific task and go ahead and implement it. And this showcases how basically an agent in here like has a single agent has to walk the entire tree by itself. But in contrast, the swarm in here splits the context across the tree. So we've got like a different context in here with different planners and workers in the leaves. So they could basically achieve a better result. So if we jump to the results across different model mixes, we see that they they actually try to use GPG 5.5 as both a planner and worker, which is a very strong frontier model throughout. There are the GR 4.5 here both at the planer worker 4.8 as a planer composer 2.5 as a worker and fable 5 with 2.5 composer as well. And what they've actually seen is really interesting is that the new harness, the new swarm harness in here outperformed the old one in every single mix. So if you've been thinking before that models matter more than harnesses, you were wrong. The harness is very very important. So, you've got a very bad harness with a very top tier capable model like Fable 5, you're just wasting tokens and you're not going to get anywhere. But if you spend a decent amount of time building and scaffolding and putting really good like solid architecture about the harness and how it works and how uses the full capabilities of a model, you are going to win eventually. It's basically what happened with the cursor AI team in here where they've put an enormous amount of time and they've actually analyzed and planned exactly how they needed to build their swarm harness to utilize the full capabilities of the planner agents, the worker agents and just have them work together. We can clearly see that this outperforms everything every single time. and the Fable 5 hybrid in here by the 4hour cut off in here. The new ones sat between 73% and 85% in test suit passing. While the older ones ranged from 11% to 77%. Same thing in here that happened with Grock in here, but they had to pause it before it 2 hour mark more below in here. Why? And every new configuration went on to pass 100% of the suit. So the main reason they had to pause grow 4.5 in here is because the V1 of the harness in here actually made 70,000 in cumulative merge conflicts like 70,000 lines of code in merge conflicts when they you know wrote the entire repository and code base um what you I mean versus in here like the V2 the V2 had less than a thousand literally less than a thousand merge conflicts and that was just over its full 4 hours run. Same thing with the lines of code produced by the agent swarm. In clear tone here with the v2, every single time the lines of code are just way fewer compared to the older one. And as we all know, more lines of code doesn't necessarily mean a better code. And for the complete experiment in here, you can clearly tell by this benchmark that in our new agent swarm, the same models needed far fewer lines of code to complete the SQLite experiment. including telling here V1 needed 64,000 slides of code with the Fable 5 Composer 2.5 uh combination versus the V2 in here almost or less than 10,000 lines of code. That is six times better. Same thing with like Opus 4.8 and Composer 2.5 is like 20,000 compared to 5,000. Now what is exactly a little bit confusing to me is how this combination of Opus 4.8 and Composer 2.5 achieve fewer lines of code compared to the Fable 5. And I mean they both passed the test suit, the SQLite experiment test suit. So they both have full code base that is running and passing the test suit of the SQLite and they run SQLite from scratch in Rust. This one is just like 5,000 compared to 10,000.

[00:08:26]That's double literally. I'm just curious to look at the code if possible of both of these. Unfortunately, we can't. But maybe I would assume that the Fable 5 in here tried to make this more abstract, bigger system, created types, creator cleaner code maybe. and this one tried to take shortcuts or maybe instead of reimplementing some crates or some libraries from scratch, it tried to use the libraries. That's my assumption, but I can't know for sure. If you got like a guts or an idea of why something like this would happen or could happen, please let me know in the comments.

[00:08:57]Okay. I mean, it's really crazy when you read such articles. It just gives you a completely different perspective on how things could be working, especially with combining different models from like a planner to a worker. The planner is very front to more expensive and the worker is a lot more cheaper, easier to work with and manage. And you're probably wondering like which combination passed the entire test suit but with the least tokens and the cheapest one. Well, the team in here actually explained this pretty well inside of the model economics. So if you go to the chart in here, you can clearly tell that opus 4.8 and composer 2.5 is the winner. Clearly 2.6 billion tokens for both of them for the planning from opus 4.8 eight and for the worker for the execution from composer 2.5 only 2.6 the next rival in here is graph 1.5 which is 3.2 billion still a little bit more stable 5 and composer 2.5 you may think oh that's better it wasn't I mean that's 7 billion opus 4.8 hybrid uh that's 5.5 billion only GPT 5.5 in here was also very intriguing because I mean we were supposed to compare GPT 5.5 with Opus 4.8 is but that one is literally like 15 billion compared to 5 billion. I don't know and Fable 5 in here I mean expected 12 billion in here but of course Fable 5 is going to be the most expensive one because just like the token price is just a lot more expensive. So the winner is clearly Opus 4.8 and Composer 2.5. I wonder if they actually had one with GPC 5.5 or if they tried it now a day with GPT 5.6 six soul because I know it's still token hungry, but it's not as token hungry as Fable 5 and it's much more optimized in my opinion. Uh so I wonder if they try to run it nowadays with that combination, would it yield a better one compared to Opus 4.8 and 2 uh 2.5? What do you think? And in the one where OPU 4.8 did the planning and composer 2.5 did the work, the entire worker fleet cost $400 $400. Compare the GPT 5.5 in here hybrid. I mean, it costs $10,000. And this clearly tells you that the best model combination matter as much as the harness implementation matters as well. Because with a very poor harness implementation, you're not going to get something working at all.

[00:11:06]And with a bad model configuration or model combination, it's going to cost you 10 times more than what you could have paid for. $10,000 versus $400 with the exact same task. And this thought from the cursor reality team that now specs are the new prompt especially with the agent swarm implementation. So as we all know each jumping AI capability has raised the level abstraction at which an engineer can work. Autocomplete first let the engineers work one line of code at a time. Early models raised that that to a block of code and agents raised it to a file or feature. Now with swarms the unit of work becomes the spec. You give it a very full detailed spec of an entire project and let the swarms split it into multiple smaller plans, delegate it to worker executions and just execute the entire thing and test it for you.

[00:11:53]And it's more interesting that I mean for this testing here they gave the swarm ages in 835 pages of pros only of text and manual nothing no code and it came back with a full database implementation. Do you know what I mean by a full database implementation? It's like a SQLite database that you can run, you can run queries on, you can host it, and it just works as a regular one. I'm not saying it's production ready, but it's something that you just give it say build me this entire database and it does it for you. I don't know if you know how long it took to build databases like SQLite or Postgres SQL or those big databases by hundreds of engineers and developers across years and years of daily work and hard work. Um, but now an agent can do it in like 4 hours. So, I don't know. I it's it's as much exciting it is, it's also frightening and and it makes things much more sci-fi. Like we're living in the future right now and this is probably AGI. So AGI isn't something super intelligent and something like that, but it's more of like an agent of swarms that can coordinate together to build meaningful stuff. But you guys let me know in the comments what do you think about this.

[00:12:58]Is it something exciting? What do you think about the cursor AI's team implementation and thoughts and the article overall? I read the article like four times today and I was amazed every single time I give it another read to basically understand what is happening behind the scenes and to grasp on all the amazing details that are inside of the article. But anyway, thanks for watching. Hope you guys enjoyed. Let's see you in the next one.