Cursor's agent swarm economics: why frontier planners and cheap workers beat solo GPT bills

Introduction

I have been telling teams to stop paying frontier prices for classification and boilerplate for months (routing note, Gemini Flash checklist). Cursor just published the cleanest public numbers I have seen that make the same point at swarm scale.

The Cursor post is not a product launch deck. It is a research write-up: new coordination harness, same SQLite-from-documentation task, four model mixes, held-out sqllogictest grading. Read it for the failure modes (split-brain planners, megafiles, merge conflict thrash). Steal the economics for your own graphs.

What Cursor actually measured

Task: implement SQLite from the 835-page manual in Rust. No source, no tests handed to the agents, no internet. Grade later against sqllogictest. Compare old swarm vs new swarm across:

• GPT-5.5 as both planner and worker
• Grok 4.5 as both planner and worker
• Opus 4.8 planner with Composer 2.5 workers
• Fable 5 planner with Composer 2.5 workers

New harness won on quality in every mix. By four hours, new runs sat between 73% and 85% while old runs ranged 11% to 77%. Every new configuration eventually reached 100% of the suite. The interesting variance is money and coordination, not the final percent.

Coordination beats raw model heroics

Old Grok run: ~68k commits in two hours, 70k+ merge conflicts, paused early. New run: under a thousand conflicts across four hours. Old package sprawl hit 54 crates with three SQL packages; new settled on nine. Lines of engine code collapsed dramatically under the new harness for the same eventual pass rate. That is the same lesson as my Claude Code graph engineering roadmap: topology and contracts beat stuffing more intelligence into one context window.

The economics that should change your routing table

Workers carried at least 69% of tokens (over 90% in most runs). Dollars flipped because planner tokens are expensive. That is the entire routing thesis in one paragraph.

Few moments in a large task genuinely require frontier intelligence. Once a frontier planner collapses ambiguity into explicit instructions, cheaper models follow.

How I map this onto production agent graphs

Rules I write into the engagement playbook

• Default leaf workers to Composer 2.5 / Flash / Haiku-class models unless the leaf fails eval twice.
• Keep Sonnet/Opus/Fable on planning, ambiguous design, and security-sensitive synthesis.
• Do not "upgrade the whole swarm" because one worker flake annoyed someone on Slack.
• Attribute cost by role in the spend dashboard, not by IDE brand.
• Pair planner output with verifiers (maker≠verifier) so cheap workers cannot silently invent a second architecture.

Where Fable as planner can still lose

Cursor's Fable hybrid shows a trap I already warn about after Fable redeployment: a stronger planner that uses fewer planning tokens can still lose on total bill if workers thrash. Measure cost per completed task, not planner vanity metrics. If worker token volume explodes, fix the contracts and Field-Guide-style shared context before you buy a smarter planner.

Failure modes to copy into your runbooks

Cursor lists coordination bugs that show up the moment you leave single-agent demos:

• Split-brain design: two planners invent incompatible approaches. Fix by forcing design decisions up into the planner, not down into leaves.
• Planner contention: back-and-forth file wars. Fix with shared decision docs and compile-checked references.
• Merge conflict thrash: workers overwrite each other. Fix with a neutral merge agent, not more worker IQ.
• Megafiles: everyone touches the same hot file. Fix by blocking growth and forcing decomposition.
• Ossification: agents refuse to touch core code. Fix by licensing intentional breakage with explanatory comments.

If you are on Claude Code dynamic workflows, these map cleanly onto fan-out, barriers, and verifier nodes in the 14-step roadmap. Same physics, different product skin.

A one-week adoption plan for a mid-market eng org

1. 01
   Day 1: tag roles in telemetry

   Add planner_role / worker_role / verifier_role labels to whatever you already ship into the spend dashboard. If you cannot see the split, you cannot manage the split.
2. 02
   Day 2: pick two workflows

   Choose one research/audit style graph and one implementation graph. Do not boil the ocean. Instrument both end to end.
3. 03
   Day 3–4: rewrite planner prompts as contracts

   Force design decisions into the planner output: interfaces, file ownership, non-goals. Workers get schemas, not vibes. This is where most hybrid savings actually come from.
4. 04
   Day 5: add a cheap verifier lane

   Independent tests or a rival-model review on the merge edge. Cursor's stacked review lenses are the research version of maker≠verifier.
5. 05
   Day 6–7: compare cost per completed task

   Frontier-everywhere baseline vs hybrid. Keep the winner. Document the conflict rate so finance does not only see token charts.

If you already use Cursor Router Cost/Balance/Intelligence modes, align them with these roles. Cost mode for leaf classification and boilerplate. Intelligence for planners. Do not let Auto silently promote every worker call to frontier because the prompt was vague. Vague prompts are a planner bug.

How this pairs with Claude Code graphs

On Claude Code, the workflow script is the cheap coordinator (zero model tokens for loops). Subagents are the workers. A Sonnet or Opus call that writes the script and the contracts is the planner. That mapping is why I keep pointing people at the graph engineering note instead of buying another orchestration SaaS when the bottleneck is topology, not vendor logos.

What not to do with these numbers

• Copy the dollar figures into a CFO slide as your expected production cost. This was a research SQLite rebuild, not your CRM migration.
• Replace all Claude API traffic with Composer because "workers are cheap." Planner quality still mattered in their hybrids.
• Ignore Cursor Router's Cost/Balance/Intelligence modes (July 22 changelog). IDE routing and swarm routing should agree.
• Skip review lenses. Cursor spent heavily on stacked review because review is cheaper than rework. So should you.

Conclusion

The swarm post is permission to do what good systems engineers already suspected: put expensive judgment where ambiguity lives, put cheap execution where the contracts are sharp, and measure both. If your July invoice still looks like "frontier model on every tool call," you are funding someone else's research budget with your roadmap.

Sources: Cursor, "Agent swarms and the new model economics" at Cursor changelog; Composer 2.5 pricing context at Cursor changelog.