Preface¶

In July 2026, Cursor announced the architecture and benchmark results of its upgraded Agent Swarm for Cursor 3 on its official blog Agent swarms and the new model economics. This system splits AI coding work into two roles:
- Planner: Uses cutting-edge large models for task decomposition and design decisions
- Worker: Uses faster, cheaper models to write code

When working together, in a closed-book test of “rewriting a complete database engine in Rust from scratch using only the SQLite manual”, all four controlled comparison configurations finally achieved 100% pass rate on the hidden sqllogictest test set. The cheapest configuration (Opus 4.8 for planning + Composer 2.5 for execution) cost a total of approximately \(1,339**, while a single GPT-5.5 model handling the entire task cost approximately **\)10,565 for the same workload.

Media often summarizes this gap as “about 15 times” — this number comes from an informal benchmark comparison (Fable 5 single model cost ~$20,057 ÷ $1,339). The range given by Cursor itself in the four controlled comparisons is about 7.9 times; if only comparing the token costs of the Worker layer, GPT-5.5 running only as a Worker cost $9,373, while the Opus + Composer hybrid setup’s Worker fleet cost only $411, a gap of about 22 times. Below we will sort out the architecture principles, benchmark details, and cost arithmetic based on official first-hand information, to help readers judge whether this layered architecture is worth referencing in their own engineering projects.

Contextual Dilemma of Single-Agent Systems¶

Cursor naturally models large software tasks as a tree: the root node is the overall goal, which is recursively split downward into smaller and smaller subtasks. If a single Agent completes the entire tree alone, it must remember “global goals, current path, and leaf node details” in its context window, and it is prone to drift during long-running operations: either focusing only on immediate implementation and losing architectural consistency, or clinging too tightly to the big picture and suffering a decline in local code quality.

The solution of Agent Swarm is straightforward:
- Planner: Only responsible for splitting and delegating tasks, does not write implementation code, so its context window is not filled with low-level details.
- Worker: Only executes assigned narrow tasks, does not do planning, so all its context window is reserved for the current piece of work.

Cursor believes that the scalability of Swarm mainly comes from this contextual efficiency, not just “running multiple Agents in parallel”. This echoes economist Coase’s论述 on “why firms exist”: coordination costs grow faster than the workload itself, so systems will naturally layer, rather than letting everyone communicate directly one-on-one.

SQLite to Rust: How the Closed-Book Benchmark Works¶

To verify the new architecture, Cursor had the new and old generations of Swarm tackle the same problem:

Only provide 835 pages of the official SQLite manual, require implementing a complete database engine in Rust; do not provide SQLite source code, test suites, binaries, or internet access.

The scoring used SQLite’s sqllogictest — which contains millions of SQL statements and their standard answers, used for cross-engine query result comparison. The Swarm did not know in advance that this test set existed; after completion, Cursor also manually reviewed for cheating and whether the code was only written to cover the test cases.

The four controlled model configurations are as follows:
1. GPT-5.5 serving as both Planner and Worker (cutting-edge single-model run)
2. Grok 4.5 serving as both Planner and Worker (lower-cost cutting-edge single-model run)
3. Opus 4.8 for planning + Composer 2.5 for execution
4. Fable 5 for planning + Composer 2.5 for execution

The new harness outperformed the old version in every configuration. After four hours, the new system had a pass rate of about 73%–85%, while the old system only had 11%–77%; the old Grok run was even paused after two hours due to merge conflicts getting out of control. In the end, all four new configurations achieved 100% pass rate.

The gap in code volume was also significant. Taking the Opus-related comparison as an example: the old harness was approximately 19,013 lines with 97% accuracy; the new harness was 4,645 lines with 100% accuracy, reducing code volume by about 85%. The old Grok run generated approximately 68,000 commits (about 70 times that of the new system) within two hours, but accumulated over 70,000 merge conflicts; the new system had fewer than 1,000 conflicts throughout the process. The old version split the project into 54 Rust crates (including 3 duplicate SQL packages), while the new version stabilized at 9 crates.

Cost Arithmetic: 7.9x, 15x, and 22x¶

First, look at the total cost of the four official controlled comparison configurations (all achieving 100% pass rate):

$10,565 ÷ $1,339 ≈ 7.9x — this is the most straightforward “total cost multiple” in the official controlled comparison.

The Worker layer accounts for the majority of the cost: Workers produced at least 69% of the tokens in each run, and most runs exceeded 90%. In the GPT-5.5 single-model run, the Worker alone cost approximately \(9,373**; in the Opus planning + Composer execution setup, the entire Worker fleet cost approximately **\)411. $9,373 ÷ $411 ≈ 22.8x — this reflects the leverage of “switching cheap models for the execution layer”, rather than the overall total cost.

The widely reported ~15x figure usually comes from dividing the informal run of Fable 5 single model (marked informal run for cost calibration, not part of the controlled comparison by Cursor, costing ~$20,057) by $1,339. The arithmetic checks out, but the control group is not in the official scoring matrix, so the口径 needs to be clarified when citing this number.

Composer 2.5, as the Worker model, has a pricing of \(0.50 / million tokens** for input and **\)2.50 / million tokens for output. Cursor founder Michael Truell stated that it is based on Kimi K2.5, with performance claimed to be close to Opus 4.7 / GPT-5.5 — this claim has not been independently verified by third-party public benchmarks. In the Opus + Composer hybrid run, Opus as the Planner only produced a small number of tokens, but accounted for approximately two-thirds of the total cost; Composer handled the vast majority of tokens, accounting for only about one-third — which demonstrates the division of labor logic that “only a few moments require cutting-edge judgment, and most execution can be offloaded to cheap models”.

1000 commits/s: Coordination Engineering is the Hidden Hero¶

The old browser-based Swarm had a peak of approximately 1000 commits/hour on Git; the new self-developed VCS has a peak of approximately 1000 commits/second. All changes are aggregated through the VCS, where conflicts are first exposed, and various coordination mechanisms are implemented at this layer.

Cursor documented several failure modes that are amplified under high concurrency and their countermeasures:
1. Split-brain: Two Planners are unaware of each other and each implement the same concept independently. Countermeasure: Planners make their own design decisions and ensure that delegated subtrees do not repeatedly decide the same issues; share design documents and compile-time references to bind decisions to code.
2. Merge conflicts: Workers are not good at merging, and easily overwrite or abandon changes. Countermeasure: Assign neutral third-party Agents to specifically arbitrate conflicts.
3. Megafiles: Multiple Workers push code to the same file, causing explosion of diff/merge costs. Countermeasure: Workers can flag bloated files, and external Agents split them into smaller modules.
4. Ossification: Agents learn to “not touch core code”. Countermeasure: Allow justified out-of-bounds modifications, with compilation errors driving downstream Agents to follow up with adjustments.
5. Field Guide: A self-maintained knowledge document with a line count limit, injected at the start of each session, similar to ant colony Stigmergy (environmental trace coordination).

There are also multiple Review Lens superimposed code reviews — different models and different information granularities review code in parallel, similar to multi-sensor fusion in autonomous driving, using relatively cheap review computing power to improve overall quality.

From Vibe Coding to “Spec as Prompt”¶

Cursor elevates the work unit of Swarm to the Spec (specification) level: in the Autocomplete era, code was completed line by line; in the Agent era, it was done by file/function; in the Swarm era, it takes intent description as input. This experiment only provided 835 pages of manual prose, and the output was a runnable database — the scarce resource has shifted from “whether you can write loops” to “whether you can clearly express your intent”.

This forms an interesting contrast with the popularity of Vibe Coding: individual developers use natural language to quickly iterate prototypes; Swarm extends the same idea to industrial-grade parallelism and cost optimization — cutting-edge models only appear in decomposition and key trade-off decisions, while the rest is handed over to “adequate Workers” like Composer. Cursor compares Swarm to a probabilistic compiler: the Planner reduces goals into a task tree, then gradually lowers it into executable work; unlike deterministic compilers, there is uncertainty at every step, and the aforementioned VCS, Review, and Field Guide mechanisms are used to reduce semantic drift.

The open source repository github.com/cursor/minisqlite released the code for the Opus 4.8 single-model run (not the cheapest hybrid run mentioned above), for the community to review the quality on their own.

Take a Calm View: Bright Benchmarks, But Early for Production¶

Important caveats to note:
- This is a self-developed system on a self-developed benchmark by Cursor, which has commercial motivation for demonstration; closed-book rewriting of SQLite is very different from daily business codebases.
- External research cited by Cursor points out that 68% of production AI Agents stagnate within 10 steps — today’s cost advantages are mainly reflected in controlled long-task experiments, and cannot be automatically extrapolated to ordinary CRUD maintenance.
- Although Fable 5 as a Planner used fewer planning tokens, its Worker consumption was much higher than the Opus Planner configuration, resulting in higher total cost — this shows that “a stronger/cheaper Planner does not necessarily mean lower total cost”, and Worker efficiency is strongly coupled with planning quality.
- The hybrid architecture relies extremely highly on Spec quality: once the Planner makes a wrong decomposition or the design document has contradictions, cheap Workers will only efficiently write wrong code.

Conclusion¶

Cursor 3’s Agent Swarm uses the Planner/Worker layered architecture to answer an engineering economics question: only a few moments in large tasks truly require cutting-edge models, but the execution layer that produces the most tokens can be replaced with cheap models. In the SQLite→Rust closed-book test, the new harness comprehensively outperformed the old version in accuracy, code volume, and conflict rate; the controlled total cost dropped from approximately $10,565 to $1,339 (about 7.9x), and the Worker layer alone could drop from $9,373 to $411 (about 22x). The “15x” figure exists as a publicity口径, but readers should distinguish the three calculation methods: total bill, Worker bill, and informal comparison.

For ordinary developers, the more realistic short-term gains may be the multi-Agent parallel orchestration in the Cursor 3 product and high-performance-cost-ratio Workers like Composer 2.5; in the long term, it is worth thinking about: can your team write requirements into clear enough Specs like the SQLite manual, so that Planners can make proper splits and Workers can write stable code. The layered architecture saves not only API bills, but also the cognitive and collaboration costs brought by merge conflicts and redundant crates — this may be more worthy of bringing into the next architecture review than the multiples in the headline.