Cursor's agent swarm data says cheap models do most of the coding once a frontier model plans it
Cursor's swarm architecture splits planning from execution, and the reported result is that smaller, cheaper models handle the bulk of coding work acceptably provided a frontier model decomposes the task first. It is the strongest commercial evidence yet that capability and cost can be decoupled by structure rather than by scale.
For three years the answer to "which model should I use" has been a single choice applied to a whole workload. The swarm result says that was always the wrong shape of question: the right unit is the step, not the session.
The division of labour is where the value sits. Decomposition — reading a codebase, deciding what to change, sequencing the changes, anticipating what breaks — is the part that rewards frontier capability. Execution — writing the edit that was specified, running the test, formatting the diff — is the part that mostly rewards not being wrong. Those have very different price curves, and until now they were purchased at the same price.
This is the same conclusion NVIDIA reached from the other direction. Switchyard's escalation router starts cheap and promotes only on sustained difficulty, and Nemotron 3.5 Lightning exists specifically to be the cheap worker. A tool vendor and a chip vendor arriving at identical architecture in the same week is a strong signal that the architecture is correct rather than fashionable.
The uncomfortable implication is for the frontier labs' revenue mix. If the frontier model becomes a planner invoked once per task rather than a worker invoked once per step, token volume at the top of the market falls even as the amount of work done rises.
The Decoder — Cursor's agent swarm suggests cheaper models can handle most coding when frontier models plan the work → · explainX.ai — Grok Bot Beta: 74 Game Assets Generated in 2 Hours →