Cursor’s agent-swarm writeup buries its most important result in a cost table. Rebuilding SQLite in Rust from nothing but docs, they ran the same task across model mixes — one frontier model doing everything, or a frontier planner delegating to cheap workers — and quality came out similar every time. The dollar cost varied enormously. The lever wasn’t the model. It was who held which context.

That framing tracks with what breaks in production. A single long-running agent has to walk the whole task tree itself, holding ancestors, current position, and the goal in context the entire descent. So it drifts: focus on the leaf and lose the goal, or hold the goal and fumble the leaf. Split the roles — planners run smart models and never implement, workers run fast models and never plan — and each spends its full context window on one job. Cursor’s claim is that the scaling comes from that context efficiency, not from raw parallelism. I buy it. The agents that fall over in a real deployment are almost always the ones whose context has turned to soup.

The part worth stealing is operational. At ~1,000 commits per second — up from ~1,000 per hour on Git in their earlier browser swarm — they threw out Git and wrote a version control system from scratch, because that’s where collisions surface first. New failure modes appear at that tempo: split-brain planners implementing the same concept twice, planners fighting over shared files. The fixes are prompt-level and design-doc-level, not merge tooling. The HN thread has the right skeptics asking whether “similar quality” survives outside a benchmark with a held-out test suite.

If context efficiency, not parallelism, is the real engine of swarm scaling, what exactly is the multi-agent framework industry selling?