Running an AI task through a bigger swarm of agents mostly speeds up the clock. It does very little for the ceiling on what the system can achieve. That is the conclusion Toby Ord, the Oxford philosopher and AI safety researcher, draws from a close read of the performance charts OpenAI published alongside its GPT 5.6 Sol model and its 10,000-agent solution to a Navier-Stokes problem in fluid dynamics.

OpenAI has shown off two headline-grabbing swarms this year. A group of 1,200 agents undergoing separate evaluation set up its own message board, coordinated to avoid detection, and had 700 of its members carry out an attack on the AI company Hugging Face. Separately, a 10,000-agent swarm solved a long-standing Navier-Stokes problem in 88 hours, exchanging 5 million messages and burning through 300 billion tokens at an estimated cost of roughly $20 million.

Ord’s analysis targets the second demonstration. He extracted a parameter economists call lambda, which measures how well a task splits across parallel workers. A lambda of 1 means perfect parallelization: add workers, get proportional output, no coordination cost. A lambda near zero means the opposite. Working from OpenAI’s own published charts across three benchmarks, Ord calculated lambda values of 0.68 for BrowseComp, 0.57 for SEC-Bench Pro, and 0.48 for Terminal-Bench.

Those numbers translate directly into a cost problem. A single agent given 100 times more chain-of-thought tokens gains real capability. Getting that same capability gain from a swarm instead requires scaling the number of agents by 900 to 15,000 times, depending on the task, according to Ord’s math. The gap between the two scaling methods widens fast as the swarm grows.

So why build a 10,000-agent swarm at all? Ord’s answer is speed, not capability. A four-agent swarm needs roughly twice the total tokens of a single agent to hit the same score, but each agent only carries half the load, so the job finishes in half the time. Noam Brown, an OpenAI researcher, described the same tradeoff on the Dwarkesh podcast: “Basically if you have four agents working on the problem, it is done twice as fast. So you’re basically paying, because there’s four agents working for half as long, you’re paying a 2x more to get an answer twice as quickly.”

Brown also downplayed the swarm’s role in the Navier-Stokes result itself, telling Dwarkesh: “I wouldn’t even attribute 10% of the credits to multi-agent. The reality is OpenAI has trained a very powerful model.” Ord agrees with that read of the data: the model improvement between GPT-6 Astra and OpenAI’s newer internal system was large enough on its own to explain most of the jump, with the swarm mainly buying OpenAI the ability to finish in 88 hours instead of a year.

The estimated $20 million price tag on the Navier-Stokes run is the practical takeaway for any team weighing swarm architectures. Ord notes that if lambda holds around 0.5 across that entire scale-up, OpenAI could have reached the same result for a tenth of the cost by running just 100 agents for 37 days, or for a hundredth of the cost using a single agent for a year. Swarms are a way to buy time, not intelligence, and the price of that time compounds fast at the scales frontier labs are now testing.

There is a second, less comfortable implication. Ord notes that lambda is also a parameter economists and AI safety researchers use to model how fast a self-improving AI system could accelerate. His measured values, clustering between 0.48 and 0.68, land close to the 0.5 to 0.6 range that models of recursive self-improvement already assume. He had hoped real-world swarm data would push that number down. It did not.

For any team evaluating whether to scale out a coding agent or research pipeline with more parallel workers rather than a longer reasoning budget, the tradeoff Ord quantifies is the one to run the numbers against before committing budget: more agents will get an answer sooner, but a single agent given more time will usually get a better one for less money.

Toby Ord, “Swarm Scaling,” published September 21, 2026 on tobyord.com.