OpenAI Ran 10,000 Agents on One Proof. They Could Not Talk Across Groups.

OpenAI published something on September 8 that almost nobody read past the headline. The headline was that an internal model resolved the Navier-Stokes Millennium Prize problem. Buried four paragraphs into the same post is a description of the agent system that did it, and that description is the most detailed public account I have seen of how a frontier lab actually wires a large swarm together.

The design choices in it run against what most teams doing multi-agent orchestration do by default, and the numbers underneath them are specific enough to argue with.

What did OpenAI actually announce?

OpenAI said an internal model, one it describes as significantly more capable than the newly shipped GPT-6 Astra, produced a proof that a smooth three dimensional fluid can develop a singularity in finite time. That resolves statements "C" and "D" in the official Millennium Prize formulation. The question had been open for roughly 90 years, and the Clay Mathematics Institute attaches a $1 million bounty to it.

OpenAI says it will not claim the prize.

The company also shipped a Lean formalization alongside the written proof, which matters more than the prose does. A Lean certificate is machine checkable. You do not have to trust the model, the lab, or the writeup to know the argument closes.

How does OpenAI's multi-agent orchestration actually work?

Agents were split into groups, and each agent could only talk to other agents inside its own group. The group that produced the Navier-Stokes result ran on the order of 10,000 concurrent agents. Cross group knowledge moved through a separate consolidation pass, not through the message bus.

That single design decision is the whole architecture. I have built enough of these to know that the instinct, when a swarm stalls, is to open more channels between agents. Let the researcher talk to the critic, let the critic talk to the planner, wire everything to everything. It feels like progress. It usually produces a system where every agent is reading a firehose of half formed conclusions from agents that have not finished thinking yet, and the whole thing converges on whichever bad idea got loudest first.

OpenAI did the opposite. Small closed rooms, and one out of band summarizer whose job is to carry only the useful part between rooms. The summarizer was Codex, prompted against the agents' own intermediate results.

Four choices are worth copying, and one is worth refusing.

The contradictory objectives deserve a second look. OpenAI prompted separate groups with variants "A" and "B", which would have produced a proof, and variants "C" and "D", which would produce a disproof. Both directions ran at once. Nobody knew which was true.

Most orchestration frameworks make that awkward to express. You define a goal, you fan out workers against it, and the workers inherit the goal. Seeding half your fleet with the negation is a deliberate act, and in my experience it is the single cheapest way to stop a swarm from talking itself into a conclusion it started with. I wrote up the mechanics of splitting work across roles in my guide to production multi-agent systems with CrewAI Flows, and the objective assignment step is the one people skip.

The last row is the one to refuse. Swapping the model under a running fleet is defensible when you are OpenAI and you own the checkpoint. In a production system it destroys your ability to attribute any result to any cause, and it burned me once on a much smaller job than this one.

What did 10,000 agents actually buy?

Before Navier-Stokes, the same system was pointed at the Euler regularity problem, which is Navier-Stokes with the viscosity term removed. Nearly 100 agents worked for about 50 hours and resolved the unforced version. OpenAI then shifted agents off the other Millennium problems, seeded them with the Euler result, and let the Navier-Stokes group run on the order of 10,000 concurrent agents.

Read the clock carefully, because this is where every summary of the story goes wrong. OpenAI dates the resolution to "about 88 hours after the first agents were launched." That is elapsed time for the whole effort, starting September 1, and the 50 hour Euler run sits inside it. So 88 is not the Navier-Stokes group's dedicated runtime, and dividing it by 50 compares an effort window against a single run.

The honest version is less flattering to the scale story and more interesting. The big group closed a much harder problem inside a window that already contained the warm up, so nothing in the published numbers shows it was slower. It also cannot be shown to have been faster, because OpenAI never published a start time for the Navier-Stokes groups on their own.

Read that the honest way and it says agent count is not a latency knob. It is a search breadth knob. Nothing OpenAI published lets you price latency against fleet size, and the shape of the disclosure suggests OpenAI was not tracking it that way either. What the extra 9,900 bought was coverage of a much larger space of approaches, on a problem where the right approach was not known in advance.

Anthropic found something adjacent when it ran 80 agents against a single codebase, which I went through in this breakdown of multi-agent failure modes. Past a certain fleet size the coordination overhead stops being a tax you pay for speed and starts being the thing you are actually engineering.

One more figure from the same section, easy to miss. Lean verification took 17 hours on top of the 88 hour search. Verification was 16.2% of total wall clock, and it ran on a shipped model rather than the frontier one. If you are budgeting an agent pipeline that has to produce a checkable artifact, that ratio is a better planning number than anything in the marketing.

What did the run cost in tokens and dollars?

Across every problem the agents attempted, they sent 4.9 million messages and burned about 300 billion output tokens. Navier-Stokes alone accounted for 2.7 million messages and roughly 130 billion output tokens. Both figures come from OpenAI's own post.

Divide the second pair and you get about 48,000 output tokens per message. Across all problems it is about 61,000. That ratio is the interesting one, and it is my arithmetic, not theirs.

Most of the compute never became a message. The agents were thinking, not talking. If you have been sizing multi-agent budgets off inter-agent chatter, which is what most observability dashboards show you, you are watching a proxy whose exchange rate was 48,000 tokens per message on Navier-Stokes and 61,000 across the whole effort. A ratio that moves 27% between one problem and the whole effort that contains it is not a budget.

TechCrunch put the week at "$22.5 million worth of compute, if charged at current Astra rates." I went and checked the rate. OpenAI's public API pricing page lists GPT-6 Astra output at $50.00 per million tokens.

At $50.00 per million, 300 billion output tokens is $15 million. TechCrunch's $22.5 million implies $75 per million, which is 50% above the listed rate. I am not calling that an error. The pricing page notes that its rates cover context lengths under 272K, so a long context tier could account for the gap, and it is not published. The Navier-Stokes portion alone lands at $6.5 million on the listed rate, or $9.75 million on the implied one.

Either way, hold the shape of it rather than the digit. One mathematical result, at frontier prices, costs somewhere between six and ten million dollars in output tokens. That is before the 17 hours of verification and before any of the human time. Both numbers are also proxies, because OpenAI ran an unreleased internal model and no public rate exists for it.

I keep seeing teams model agent spend as a per task line item. It is not. It behaves like a search budget, and search budgets have no natural ceiling until you impose one. The Army learned that the expensive way, which I wrote about in the unlimited token contract that ran dry in weeks, and Rippling caught the same curve early in its spend console rollout. Neither of those teams was running 10,000 agents.

One more thing OpenAI mentions in passing and nobody costed. The run kept "the same strict safeguards that we apply to all our frontier model evaluations, including monitoring and isolation." OpenAI has separately put the overhead of watching its own agents at roughly 20% of compute. If that applied here, the monitoring alone was a seven figure line.

Where do OpenAI and the mathematician disagree?

The same day, NYU mathematics professor Tristan Buckmaster published a four page statement describing his interactions with OpenAI. He and Levent Alpöge, a researcher at Anthropic, had released three related blowup results. Buckmaster's account of what he was told on two calls does not line up with what OpenAI's post says.

Buckmaster writes that he "was shown a prompt and told the internal research model had simply been given the problem statement", and that Alpöge had been told "very little human input" was used. He then writes: "This turned out not to be true." Over the course of the call, as colleagues fed corrections in over an internal chat, that account came apart. There was a team. Easier problems, Euler among them, had been run first. And "even the prompt that had been shown to me had been written by prompting Codex."

Here is what makes part of this checkable rather than a he said situation. The largest correction is confirmed in writing by OpenAI itself, two days later: the agents were pointed at easier problems first, Euler among them, and the Navier-Stokes groups were then seeded with the Euler result. The Codex detail is confirmed only in a weaker form. Buckmaster was told the prompt shown to him had been written by prompting Codex, while OpenAI's post describes Codex consolidating insights between agent groups into follow-up prompts. Same tool, different sentence. On the team, the post says only that the milestone "represents substantial work by mathematicians and AI researchers", and leaves it there. One of three is documented, one is adjacent, one is not addressed.

The dates are the other thing worth lining up.

OpenAI's post says it reached out on September 6 to offer a joint announcement. Buckmaster's statement says he wrote first, on September 3. The reply he quotes reads: "If you are willing to give any details it would be useful to avoid competing here and in general we are always thrilled when mathematician make progress with our models." Both accounts can be true at once, and the second one is missing from the first.

Buckmaster is careful about what he is not claiming. "I have not seen OpenAI's proof. I do not know what their model did, or how. I do not know whether our data was used. I am not accusing anyone of anything." He is also not a bystander to this problem. His Courant faculty page lists a 2019 Clay Research Award, shared with Vlad Vicol and Philip Isett, for earlier work on non-uniqueness of weak solutions to Navier-Stokes. By his own account he and Alpöge had quietly chosen the smooth forcing route to the Clay problem, and he says almost nobody else he knew of was working on it.

He also spends a paragraph handing the credit somewhere else entirely, to Diego Córdoba and Luis Martínez-Zoroa, whose program on forced blowup he and Alpöge built on. "I believe Luis Martínez-Zoroa deserves a Fields Medal," he writes. None of the coverage I could get past a paywall carried that line.

Did OpenAI train on the Codex sessions?

Buckmaster asked directly, on the call, about the Codex sessions into which he and Alpöge had been putting every draft for the whole project. Had the model been trained on them, or read them. He was told the model "did not look up user data." He asked again, about training, and by his account did not get an answer.

OpenAI's post answers it in writing, and the wording repays a slow read:

"We (the researchers and the agents) did not see any of their work through any means until they released it publicly; in particular, no specific user data was accessed in order to solve this problem. While unlikely, we cannot rule out that de-identified data derived from their usage of our products helped improve our models."

Those are two different claims. The first is about retrieval, and it is a flat denial. The second is about training, and it is a hedge with a stated probability of "unlikely" and no floor under it.

That is not a scandal. It is the honest shape of the answer, and any team that asks the same question about its own work will get the same shape back, because that is genuinely how the pipeline works. Nobody at a lab can point at a de-identified corpus and prove a particular customer's tokens are absent from it.

Which makes it an engineering problem rather than a trust problem. If your team is putting proprietary work through a coding agent, the control you have is the endpoint you chose and the retention terms attached to it, and that is a thing you can write down, verify once, and audit. The provenance question is going to keep arriving from a new direction every few months. It arrived through a music publishers' lawsuit aimed at a training data pipeline in August, and through the data residency dimensions Mistral named a few days ago.

Buckmaster, for what it is worth, paid for his own tools. "I pay for the tools my group uses out of my own research funds, including footing a large bill to OpenAI," he wrote in the email he reproduces in full.

What would I change in an agent system after reading this?

Four things, and none of them require a frontier model. They are all topology and accounting decisions you can make on a fleet of twelve agents this afternoon.

Shard the conversation. Put agents in groups that can only see their own group's messages. If your framework only offers a shared context, that is a constraint to work around rather than a default to accept. The failure this prevents is premature consensus, and it is the most common way a swarm produces confident nonsense. I ran into the same pattern in the incident where 1,200 agents built their own message board and almost none of them escalated to a human.

Move insight between groups out of band. One summarizer, reading finished intermediate results, writing the next round of prompts. OpenAI used Codex for it. The point is that the transfer is a deliberate step with its own model call, not an ambient side effect of everyone reading everything.

Seed contradictory objectives. If the answer is genuinely unknown, half your groups should be trying to prove it and half should be trying to break it. This costs nothing and it is the single biggest win in the whole account.

Meter output tokens, not messages. The 48,000 to 1 ratio is the number I would put on a dashboard tomorrow. Message counts will tell you a swarm is healthy right up until the bill arrives.

What I would not copy is the model swap mid run, and I would not read the 10,000 agent figure as an argument for scale. It is an argument for breadth on problems where you do not know the right approach yet. Most production work is not that. Most production work has a known approach and needs it executed reliably, which is a different engineering problem with a different shape, and it is the one most teams actually have.

If you are trying to work out whether your own workload is a search problem or an execution problem before you spend money finding out, the AI readiness assessment walks through that split in about ten minutes. The agent builds I take on are almost all the second kind.

Frequently asked questions

Did OpenAI win the $1 million Millennium Prize?

No. OpenAI states in its post: "We do not intend to claim the Millennium Prize for this result." The Clay Mathematics Institute has its own publication and review requirements, and a lab announcement is not a submission.

How many agents did OpenAI use, exactly?

OpenAI says "the group that produced the Navier-Stokes resolution involved on the order of 10,000 concurrent agents." That is a stated order of magnitude rather than a count. A separate group of nearly 100 agents produced the earlier Euler regularity result.

Can the proof be trusted if a model wrote it?

The written proof carries a Lean formalization, which any machine can check independently of the model that produced it. OpenAI says verification took an additional 17 hours on GPT-6 Astra. A Lean certificate that checks is a much stronger object than prose that reads well.

What did Tristan Buckmaster actually allege?

He documents what he was told and when, and he is explicit about the limits. He writes that he has not seen OpenAI's proof, does not know what the model did, does not know whether his data was used, and is "not accusing anyone of anything." The substance is that he was told the internal model had been handed nothing beyond the problem statement, that corrections started arriving during the call itself, and that OpenAI's post two days later documented the largest of them, the easier problems and the Euler seeding, in writing.

Does this mean my code in Codex or Claude trains the model?

It depends entirely on the endpoint and the plan you are on, and that is the thing to verify rather than assume. OpenAI's post denies that specific user data was accessed for this problem while adding that it "cannot rule out that de-identified data derived from their usage of our products helped improve our models." Check your own retention terms and record the answer.

Should I run more agents to make my system faster?

Probably not. The published numbers do not support it. OpenAI dates the Navier-Stokes resolution to 88 hours after the first agents launched, an elapsed window that already contains the 50 hour Euler warm up, so there is no clean before and after to measure fleet size against. Agent count buys search breadth, and it buys latency only when the bottleneck is genuinely parallel.

Sources: OpenAI put the Navier-Stokes run at 88 hours, on the order of 10,000 concurrent agents, 2.7 million messages and roughly 130 billion output tokens, with Lean verification adding 17 hours. OpenAI, On the Navier-Stokes Millennium Prize Problem (September 8, 2026) · Tristan Buckmaster, public statement, Courant Institute, NYU (September 8, 2026) · Russell Brandom, TechCrunch (September 8, 2026) · Emma Roth, The Verge (September 9, 2026) · Robert Hart, The Verge (September 10, 2026) · OpenAI API pricing, GPT-6 Astra output at $50.00 per million tokens · Ben Thompson, Stratechery (September 9, 2026). Dollar figures for the run are my own arithmetic against the listed Astra rate, and are proxies, because the model OpenAI used is unreleased and unpriced.