Cursor's Agent Swarm: The Real Cost Math of Splitting Planner and Executor Models

When Cursor published results from its new agent swarm, the headline was capability: 80% of a held-out SQL test suite passed in four hours, where the old single-agent system stalled before hour two. But underneath the capability story is a pricing story. The swarm works by splitting roles, a planner on the strongest model and a fleet of executors on fast, cheap models, and that split changes your token bill in ways worth modeling before you copy the pattern.

What Cursor's Agent Swarm Actually Does

The architecture decomposes a task into a tree. A single planner node, running the strongest available model, reads the goal and emits a structured plan: a set of subtasks, each small enough for a cheaper model to execute independently. Dozens of executor nodes then pick up leaves of that tree in parallel, each running a fast, low-cost model. Cursor reported peak throughput of roughly 1,000 commits per second, so high that the team built a dedicated version-control system from scratch just to absorb the write volume. The same swarm has been pointed at building browsers, fixing bugs, and generating billions of tokens of synthetic training data. Running the SQL test with Grok 4.5 (in $2/M, out $6/M), it cleared 80% of the suite in four hours.

The Core Economics of Role-Splitting

The reason to split roles is that planning and execution have different value-per-token. Planning is where expensive reasoning earns its keep: one good plan steers hundreds of downstream calls. Execution is mechanical, write this function, run this query, patch this file, and a mid-tier model handles it at a fraction of the price. Paying premium rates for every mechanical step is the waste the swarm removes. The whole question is whether the coordination overhead the swarm adds is smaller than the premium-token spend it removes.

Worked Token Math

Take a task that cleanly decomposes into 40 subtasks. Here is a swarm built with an Opus 4.8 planner (in $5/M, out $25/M) and a Haiku 4.5 executor fleet (in $1/M, out $5/M), against the same job run monolithically on Opus 4.8 alone.

Component	Tokens	Cost
Planner: 1 call, Opus 4.8	50K in / 10K out	$0.50
Executors: 40 calls, Haiku 4.5	20K in / 5K out each	$1.80
Swarm subtotal	—	$2.30
Monolithic agent, Opus 4.8	800K in / 200K out	$9.00

The planner costs 50K in at $5/M ($0.25) plus 10K out at $25/M ($0.25), so $0.50. Each executor is 20K in at $1/M ($0.02) plus 5K out at $5/M ($0.025), so $0.045; times 40 is $1.80. The monolith accumulates every subtask in one growing context window, so its input balloons: 800K in at $5/M is $4.00 and 200K out at $25/M is $5.00, for $9.00. The swarm lands near $2.30 versus $9.00, about 74% cheaper, because the expensive model only touches the plan and the growing-context penalty is spread across many short executor contexts instead of one giant one. Swap the planner to Grok 4.5 (in $2/M, out $6/M) and that call drops to $0.16, pulling the swarm down to roughly $1.96.

When the Overhead Eats the Savings

That $2.30 figure is the best case: a task that decomposes cleanly and executors that rarely fail. Three costs erode it.

• Coordination tokens. The planner re-reads executor outputs to stitch results, and each executor carries boilerplate: system prompt, tool schemas, shared context. A 3K-token preamble paid across 40 calls is 120K input tokens you buy just to set the table.
• Re-planning. If early executors reveal the plan was wrong, the planner runs again, another premium call, sometimes several.
• Failed branches. Executors that produce broken code get retried or discarded. Discarded work is tokens you paid for and threw away.

Stack these up on a poorly-decomposed task and a swarm can cost more than the monolith it replaced. The 1,000-commits-per-second infrastructure Cursor had to build is itself a signal: coordinating a swarm at scale is an engineering cost, not a free lunch.

The 80% Problem

The 80% pass rate should anchor your budget. The other 20% does not vanish; it converts into retry tokens, a premium-model rerun, or human review time. If a swarm run costs $2.30 in tokens but one in five outputs needs a developer to inspect and fix, the loaded cost of that human minute usually dwarfs the token savings. The swarm is cheapest when executor errors are cheap to catch automatically, a failing test, a compile error, a schema mismatch, because then the retry loop stays inside the cheap tier instead of escalating to a person.

Applying This to Your Own Budget

Before rebuilding your pipeline as a swarm, check three things about your workload:

1. Does the task decompose into independent subtasks? If subtasks depend on each other's output, coordination overhead climbs fast.
2. Are executor failures cheaply detectable? Automated verification keeps retries in the cheap tier instead of on a human.
3. Is your premium spend actually dominated by mechanical work? If most of your tokens already go to reasoning, splitting saves little.

When all three hold, the planner-executor split is one of the largest structural savings available in 2026, routinely halving a monolithic premium bill or better. When they do not, you are paying coordination tax for no gain. Model both shapes for your own subtask count and token sizes in the AI cost calculator before you commit to the architecture.