The argument in one line

context efficiency > parallelism

Keep frontier intelligence at ambiguity bottlenecks. Push explicit, bounded execution to cheaper workers. Spend heavily on coordination because churn compounds faster than useful work.

Cursor research · Wilson Lin Read the original article ↗
New harness at four hours 73–85% Held-out SQL suite across four model mixes
Reported run cost range $1,339–$10,565 Similar eventual quality, radically different spend
Grok merge conflicts 70k+ → <1k Old harness versus new harness
Swarm architecture and context flow A specification is decomposed by frontier planner agents into narrow tasks for inexpensive workers. Shared design documents, a field guide, version control, and stacked review feed coordination and correction back into the system. Specification intent + constraints Planner agents frontier judgment one context: the tree Worker fleet fast + inexpensive one context: one leaf 69–90%+ tokens System integrated output Shared memory design docs + Field Guide Coordination layer VCS + reconcilers decompose delegate integrate
Specificationintent and constraints
↓
Planner agentsfrontier judgment · one context: the tree
↓
Worker fleetbounded execution · one context: one leaf
↓
Systemreviewed, integrated output

Coordination layer: shared memory, version control, and reconcilers feed corrections back into planning and execution.

Coordination is the product

~1,000 commits / second peak
Split-brain designPlanners own design decisions and cannot delegate the same question into competing subtrees.
Planner contentionShared design documents carry compile-checked references; a reconciler merges contradictory decisions.
Merge conflictsA neutral third-party agent resolves collisions so workers do not absorb one another’s context.
MegafilesWorkers flag bloated files; commits pause while an outside agent decomposes the module.
OssificationFocused core breakage is licensed; compiler failures propagate the rationale to dependent work.
Accumulated errorDecorrelated review lenses stack because review is cheaper than the work being audited.

SQLite test conditions

Input: 835-page SQLite manual
Output: database engine in Rust
Withheld: source, tests, SQLite binary, internet
Grade: fraction of millions of held-out sqllogictest queries answered correctly
Audit: manual review for cheating, shortcuts, and uneven implementation

What changed in the runs

less activity, more progress
Coordination churn under old and new Grok harnesses The old Grok run made 68,000 commits in two hours and accumulated over 70,000 conflicts. The new run made about one seventieth as many early commits and fewer than 1,000 conflicts over four hours. Grok 4.5: coordination churn old harness vs new harness Commits, first 2h Merge conflicts 68,000 ≈970 70,000+ <1,000 Old New
The article interprets the old run’s higher commit rate as thrash, not productivity.
Codebase structure and efficiency under old and new harnesses The old Grok run used 54 Rust crates compared with 9 for the new run. In the Fable mix, both passed the full suite, but the old implementation used 64,305 lines of engine code compared with 9,908. Structure after coordination smaller codebase, equal or better grade Rust crates, Grok Engine LOC, Fable 54 9 64,305 9,908 Old New
Fable: both old and new reached 100%; the new engine used about one-sixth the code.
Contention in the hottest file In the old Grok run the hottest file had 7,771 conflicts and was touched by 1,173 agents. The most contested file in the new run saw 47 conflicts. The hottest file where megafiles turn into collision magnets 7,771 conflicts 47 conflicts Old file touched by 1,173 agents New system blocks commits and decomposes bloated modules.
Quality across model mixes At the four-hour cutoff, new harness configurations scored between 73 and 85 percent, while old harness configurations ranged from 11 to 77 percent. Every new configuration eventually passed 100 percent of the suite. Held-out SQL grade range across four model configurations 4h final old 11–77% new 73–85% all new mixes: 100% 0%100%
The behavioral differences were larger than the score ranges alone suggest.

Model economics: pay for judgment, not repetition

workers consume the tokens
Reported cost comparison for SQLite swarm configurations The Opus 4.8 planner with Composer 2.5 workers cost 1,339 dollars. GPT-5.5 as planner and worker cost 10,565 dollars. GPT-5.5 workers alone cost 9,373 dollars, while the entire Composer worker fleet in the Opus hybrid cost 411 dollars. Total run cost similar quality, different allocation of intelligence Opus 4.8 → Composer 2.5 $1,339 GPT-5.5 → GPT-5.5 $10,565 Worker fleet only Hybrid Composer$411 GPT-5.5 workers$9,373

Allocation rule

Frontier model: original decomposition, architecture, design decisions, hard trade-offs.

Efficient model: explicit leaf tasks after ambiguity has been collapsed.

System spend: review, shared memory, conflict resolution, and structure maintenance.

A cheaper planner is not automatically cheaper overall. The Fable planner used fewer planning tokens but induced several times more worker tokens than Opus.

The unit of work becomes the spec

probabilistic compilation
Intentwhat should exist
Task treeplanner decomposition
Leaf workbounded execution
Systemreviewed integration
Evidence boundary: these are Cursor’s reported experimental results, not an independent replication. The old Grok run was paused before two hours; solo frontier quality was graded only informally.