# Cursor Agent Swarms In July 2026 [[Cursor.com|Cursor]] published the numbers behind its agent swarm work, and it is the most useful public document on [[AI Agent Swarms|agent swarm]] economics so far. Not because the idea is new, but because they ran the same task through several model combinations and published what each one cost. The task: implement SQLite from scratch, measured against the sqllogictest suite. ## The economics Planner agents run on the smartest models and split a goal into pieces. Worker agents run on faster, cheaper models and execute those pieces. The argument for the split is one sentence: **few moments in a large task genuinely need frontier intelligence.** The decomposition, the design decisions, a handful of trade-offs. Everything after that is following instructions, and following instructions is cheap. The cost table makes the point better than the argument does: | Configuration | Total cost | |---|---| | [[Claude Opus 4.8\|Opus 4.8]] planner + Composer 2.5 workers | **$1,339** | | Grok 4.5 for both roles | ~$2,500 to $3,000 | | [[GPT-5.5]] for both roles | **$10,565** | The line worth staring at: GPT-5.5 workers alone cost $9,373. Opus planning plus Composer workers cost $411 for the same worker layer. **The worker tier is where the money goes**, because that is where the volume is, and it is the tier where model choice matters least for quality. This is the same recipe as the cost-aware orchestration pattern in [[Claude Fable 5]], with a price tag attached. ## What actually broke, and what fixed it The interesting half of the post is not the economics, it is the failure catalogue. Same model, same task, old orchestration versus new: | | Old swarm | New swarm | |---|---|---| | Commits | 68,000 | 1,000 | | Merge conflicts | 70,000+ | under 1,000 | | Crates | 54 (3 duplicate SQL packages) | 9 stable | | Worst-contested file | 7,771 conflicts | 47 | | Final engine code | 64,305 lines | 9,908 lines | Six times less code for the same working result. The old swarm was not slower, it was **generating waste at industrial scale** and calling it progress. The named failure modes and their fixes: - **Split-brain**: two agents build the same thing. Fixed by making planners write decisions into shared design docs with compile-checked references. Coordination through artefacts, not through conversation - **Merge conflicts**: resolved by a third-party reconciler agent, deliberately impartial, belonging to neither side - **Megafiles**: workers flag files that have bloated, and an external agent decomposes them - **Ossification**: agents become afraid to touch core code. Fixed by explicitly permitting justified patches with explanatory comments - **Review**: multiple decorrelated lenses stacked. Full transcript, output only, codebase only. Same principle as never letting a worker check its own work - **The Field Guide**: a shared context file the agents write themselves, curated by them, capturing surprising learnings and injected into every agent They also built a custom VCS, because Git handles about 1,000 commits per hour and they needed 1,000 per second. ## Why it matters **Context efficiency beats raw parallelism.** This is the sentence to keep. The old swarm had more agents doing more work and produced a worse result more expensively. Separating planning from execution is what made scale usable, not adding workers. **Their framing is that a swarm resembles a compiler**, lowering high-level intent through intermediate stages into executable work. That is a better mental model than "many agents working together", because it tells you the stages should be typed and checked rather than chatty. It rhymes with the case for [[DSLs Make LLM Output Reliable|DSLs as handoff contracts]] and with the node-contract rule in [[Graph Engineering]]. **Every fix here is topological.** Impartial reconciler, decorrelated reviewers, shared design docs, self-curated field guide. None of them make any individual agent smarter. That is exactly the claim graph engineering makes, now with a control group. ## Caveats - Cursor benchmarked Cursor, and Composer is Cursor's own model. The cheap-worker conclusion happens to favour their product. It is also the same conclusion practitioners reached independently, which is the reason to take it seriously - The full model matrix was not tested, only selected combinations - Manual review found no test-specific shortcuts, but they say plainly they have not done a deeper analysis of the output - Agents chose their own strategies, so timings vary between runs - One task, one domain. SQLite has an unusually good oracle (a giant conformance suite). Most real work does not, and the whole approach leans on having one ## References - Cursor, "Agent swarms and model economics" — https://cursor.com/blog/agent-swarm-model-economics ## Related - [[Cursor.com]] - [[AI Agent Swarms]] - [[Challenges in Managing AI Agent Swarms]] - [[AI Agent Orchestration]] - [[Graph Engineering]] - [[Loop Engineering]] - [[DSLs Make LLM Output Reliable]] - [[Claude Fable 5]] - [[Claude Opus 4.8]] - [[GPT-5.5]] - [[AI Agents]] - [[Agentic Engineering]] - [[How Coding Agents Work]] - [[AI Verifiability]] - [[Kimi K3]] - [[Software Architecture]]