Cursor Agent Swarms

Canonical version: Cursor Agent Swarms.

In July 2026 Cursor published the numbers behind its agent swarm work, and it is the most useful public document on 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:

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:

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 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

About Sébastien

Ready to get to the next level?