@therobertta_ — 22x breakout selling Fable 5

@therobertta_ — 22x breakout selling Fable 5 | Overshot

On-screen text

CURSOR JUL 20, 2026 Research Agent swarms and the new model economics Wilson Lin - 17 min read The $1,339 swarm that rebuilt SQLITE Cursor had an agent swarm implement SQLITE in rust from scratch 835 page manual graded by SQL Logic test. Cost to rebuild SQLITE by model mix 20k 10k $1,339 Opus 4.8 + Composer 2.5 $1,929 Groq 4.5 $2,234 Fable 4.5 + Composer 2.5 $4,153 Opus 4.8 $10,565 GPT 5.5 $20,997 Fable 5 Planner Worker *Information for cost calibration, not part of the controlled comparison Trees and leaves Descriptions of large tasks naturally take the shape of trees, with a goal at the root that subdivides recursively into basic units of work. Our Decomposing work keeps every agent's context small One agent node (the tree's root) Context tree Sub-context Sub-context Sub-context Sub-context Sub-context The goal Sub-goal Sub-goal The goal Sub-goal Sub-goal The context splits the context across the tree Parents Goal Planner Christmas Gift Dice Supplement Winter Context node We suspect the ability to scale the agent swarm comes from this context efficiency, more than from "specialism" asset. That efficiency is present in the swarm at every scale, which is why this decomposition helps agent performance even on moderately sized tasks. Personally, I've been using Fable 5 as a planner and then GPT 5.6 swarm, as like the implementation. it's not the cheapest way but for unbound planning, Fable is a great model either or run them. Here they showed their own composer 2.5 working with Opus 4.8. cheapest one, Opus 4.8, on a task like create something with a fixed spec is actually a pretty good model to do that. And Fable 5 is like overkill. There's not enough creativity where Fable can really show its value and I think I would use Fable in something where it could produce a better result than Opus 4.8, and expect SQLITE grade over time -- Opus 4.8 / Composer 2.5 1.0 Grade 0.8 0.6 0.4 0.2 0.0 30 60 90 120 150 180 210 240 Time (minutes) v1 v2 SQLITE grade over time -- Fable 5 / Composer 2.5 1.0 Grade 0.8 0.6 0.4 0.2 0.0 30 60 90 120 150 180 210 240 Time (minutes) v1 v2 A deep dive into the runs Starting with the simplest measure of activity, we can see how the rate of commits varied for Grok 4.5 under the old harness versus the new. The old run produced 68,000 commits in its first two hours, roughly 70 times the new run's pace. One reading is that it was more productive. Another is that most of those commits were busywork (slash, contention, churn). Grok 4.5 -- cumulative commits over active minutes 70k 60k 50k 40k 30k 20k 10k 0 0 50 100 150 200 250 Active minutes - v1 - v2 The merge conflict data points to the latter interpretation. The old run accumulated more than 70,000 conflicts before we paused it, accelerating rather than slowing, while the new run logged fewer than a thousand over its full four hours. Grok 4.5 -- cumulative merge conflicts over time 70k 60k 50k 40k 30k 20k 10k 0 0 50 100 150 200 250 Time (minutes) - v1 - v2 Rust code is organized into packages called crates, and in a project like this, each crate is roughly one major component. The old swarm ran up to 54 crates, including three separate SQL packages. The new run settled on nine crates early and never added another. Grok 4.5 -- distinct crates 60 50 40 30 20 10 0 0 50 100 150 200 250 Time (minutes) - v1 - v2 - v3 - v4 - v5 - v6 - v7 - v8 - v9 - v10 - v11 - v12 - v13 - v14 - v15 - v16 - v17 - v18 - v19 - v20 - v21 - v22 - v23 - v24 - v25 - v26 - v27 - v28 - v29 - v30 - v31 - v32 - v33 - v34 - v35 - v36 - v37 - v38 - v39 - v40 - v41 - v42 - v43 - v44 - v45 - v46 - v47 - v48 - v49 - v50 - v51 - v52 - v53 - v54 - v55 - v56 - v57 - v58 - v59 - v60 - v61 - v62 - v63 - v64 - v65 - v66 - v67 - v68 - v69 - v70 - v71 - v72 - v73 - v74 - v75 - v76 - v77 - v78 - v79 - v80 - v81 - v82 - v83 - v84 - v85 - v86 - v87 - v88 - v89 - v90 - v91 - v92 - v93 - v94 - v95 - v96 - v97 - v98 - v99 - v100 In our new agent swarms, the same models needed for fewer lines of code to complete the SQLITE experiment 75k Lines of code 64,505 50k 25k 0 Fable 5 / Composer 2.5 9,908 19,015 6,845 v1 v2 Opus 4.8 / Composer 2.5 v1 v2 Model economics We said at the top that every model mix produced similar quality while the costs varied enormously, from $1,339 for the Opus 4.8 hybrid to $10,565 for GPT-5.5 alone. The token data shows where that difference comes from. The structure of the spend was consistent across every run, with workers carrying at least 69% of the tokens, and over 90% in most. But the dollars split differently than the tokens, because planner tokens cost more. In the Opus 4.8 and Composer 2.5 mix, the Opus-as-planner produced a small fraction of the tokens but roughly two-thirds of the cost, while Composer-as-worker handled the vast majority of the tokens for the remaining third of the cost. Tokens by model (planner vs worker) 200 150 100 50 0 0.76 3.39 4.54 5.76 9.93 14.70 12.26 Opus 4.8 + Composer 2.5 Grok 4.5 Fable 4.5 + Composer 2.5 Opus 4.8 GPT 5.5 Fable 5 Planner Worker *Information for cost calibration, not part of the controlled comparison But yeah, exactly the kind you're kind of running every day as a builder right now, right? They just did it at scale. numbers to it. It's really helpful for expect instruction, less expensive models simply have to know RL. This is a huge potential source of cost savings. In the run that used GPT-5.5 for both planner and workers, the cost was $9,375. In the run where Opus 4.8 did the planning and Composer 2.5 did the work, the entire worker fleet cost $411. One detail worth noting comes from comparing the two hybrid runs. The Fable 5 planner ran up a slightly smaller bill than the Opus 4.8 planner, despite roughly twice the per-token price, because it used far fewer planning tokens. But the Fable run's workers went through several times as many tokens, and the run as a whole came but substantially more expensive. 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. 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 much of this post is about. We gave the swarm 835 pages of spec and it helpful for the rest of us.

Transcript

curser had an agent charm implement sequal light in rust from scratch against an 835 page manual graded by sequal logic test. The cost to rebuild the sequal light by model mix, you could see Fable 5 here with the highest cost $20,000, lowest cost OP 4.8 plus composer 2.5 where they split up the workloads to rebuild sequal light. That came in at almost at elite score actually. 1339, so only $2 off of elite. The architecture was planner agents being the frontier models. They deep compose goals, worker agents, fast cheap models execute on them. And Wilson Lynn says a planner doesn't implement, so its contacts never fills with low-level detail. Worker never plans, so it can spend all its contacts on one narrow piece of work and now the architecture they went for. They saw that GPT 5.5 alone burned 14.7 billion tokens and fable 5, 12.2 billion 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 instructions so explicit that cheap models couldn't get them wrong.Once the thinking is done, execution is nearly free, and it turns out execution is where most of your token bill actually goes. So the question for anyone building with agents isn't which model is smartest. It's where the ambiguity in your task really lives, because that's the only pla Personally, in in my work I've been using Fable 5 as a planner and then uh GPT 5.6 swarm, as like the implementation. I know it's not the cheapest way to get it done, but for unbond planning, especially creative planning, Fable is like a really great model and then it can either architect 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 about task like really create something with a fixed spec is actually a pretty good model to do that and Fable 5 is kind of like overkill. There's not enough creativity needed where Fable can really show its value and I think I would use Fable in something where it could produce a better result than OP 4.8 and expect to see results there. Is 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 experiences you're kind of like running every day as a builder right now, right? They just did it at scale. numbers to it. It's really helpful for the rest of us.

CURSOR JUL 20, 2026 Research Agent swarms and the new model economics Wilson Lin - 17 min read

Promoted product

Why it worked

Summary

Structure

Original caption

More from @therobertta_

Product placement

On-screen text