OpenAI's Navier-Stokes proof says m + 4, its Lean code m + 5

OpenAI's agents took 88 hours to produce a proof of the Navier-Stokes problem. A team of mathematicians then spent about two weeks finding one place where the machine-checked version says something different from the written one, New Scientist reports. The team, led by Anders Hansen at the University of Cambridge, does not say the proof is wrong. It says the Lean code and the paper do not match.

At a glance

• Anders Hansen's team at Cambridge says the Lean code OpenAI published as a formalisation of its written proof diverges from the text, but it does not call either version wrong.
• In Lemma 8.6 the written proof needs a certain value to stay below m + 4, where m is a whole number. The Lean code only asks for below m + 5, a weaker claim.
• OpenAI says it knows about the mismatch and considers neither proof invalid. Only some of the 722 papers it just released come with Lean proofs, and those haven't been checked by hand.

If you haven't been following: the Navier-Stokes equations describe how fluids flow. According to BougainWell, the open question is whether a 3D incompressible fluid can reach infinite speed at a point in finite time, even though viscosity smooths the flow. BougainWell also notes that Jean Leray proved in 1934 that solutions exist in a weaker, generalised sense. In 2000 the Clay Mathematics Institute made the problem one of seven Millennium Prize Problems, each with a $1 million award.

OpenAI published the proof on 8 September, once in prose and once in Lean

On 8 September, OpenAI announced that it had solved the Navier-Stokes problem, one of the best-known open problems in mathematics. It published the proof twice. One version is in natural language, the mix of English and symbols a human mathematician writes. The other is in Lean, a language in which a computer can mechanically check that every logical step holds.

According to Discoverai, OpenAI began testing an internal model on the open Millennium problems on September 1. The Navier-Stokes effort used about 2.7 million agent messages and 130 billion output tokens. Discoverai says that after about 88 hours of agent work, GPT-6 Astra spent another 17 hours on Lean formalization and verification. The release was a 166-page paper plus a public Lean repository.

The paper claims alternatives C and D of Fefferman's official problem description through a forced construction. As alphaXiv describes it, the force is smooth and is chosen as part of the construction, and the paper does not claim blowup for the unforced equations. On GitHub, OpenAI describes the code like this:

This repository contains Lean 4 formalizations of the results presented in [the paper] ‘Finite time blowup for Navier–Stokes’

Lemma 8.6 asks for m + 4 in the paper and m + 5 in the code

The team's claim rests on Lemma 8.6. In the natural-language proof, an equation there requires a certain value to stay below m + 4, where m is a whole number. In the Lean proof, the equivalent value only has to stay below m + 5, which is a weaker statement.

New Scientist gives a simple illustration. Solve x + 3 = 6 and you get x = 3. You can prove that x is less than 4, and you can also prove that x is less than 5. Both statements are true, but the second allows more possible answers, so it says less.

Hansen is careful about what this means. “We are not saying that the natural-language proof is wrong,” he says. “Nor do we say that it is correct.” Both versions could be valid solutions, just as Pythagoras's theorem has hundreds of proofs. The objection is that OpenAI presents the two as the same proof.

Fabian Circelli, a team member who is also at Cambridge, says formalisation is “trying to replace peer review”. The team's paper shows, he argues, that this kind of AI auto-formalisation cannot do the job of human eyes on a proof.

Finding one real discrepancy took about two weeks

New Scientist calls the search slightly surreal. The team asked ChatGPT to flag possible discrepancies between the paper and the Lean code, then checked each suggestion by hand. Many turned out to be consistent after all. “Going through all of these things manually was a nightmare,” Hansen says.

In all, it took about two weeks to pin down one true divergence. OpenAI said its agents spent 88 hours generating the proofs. “OpenAI boast about how quickly they were able to generate this result, but that's only part of the process,” says team member Alexander Bastounis at King's College London.

Hansen points to a wider cost. Every proof produced this way “will have to be read by humans, and this creates an enormous extra burden on mathematicians.” OpenAI released 722 papers this week. Only some come with Lean proofs, and those have not been checked by hand either.

Why would a model change the maths to make Lean compile?

Compiling is the goal it is given. Hansen explains that the model has to produce Lean code that compiles, meaning the code is fully self-consistent and raises no error. When a section won't compile, the model looks for a workaround, even if that drifts away from the written argument. “It is trying to help me, but by doing that, it is not helping,” he says.

Picture a translator who only gets paid when the text passes a grammar checker. When a sentence won't fit, they quietly write a slightly different one that does. The result reads cleanly, and nobody notices unless they compare it with the original line by line.

Kevin Buzzard at Imperial College London separates a theorem's statement from its proof. Once you trust the statement written in Lean, a proof that compiles is true. But that tells you nothing about the PDF. “I am confident that the Navier-Stokes problem has been correctly resolved,” he says. “I am far less confident that the proof described in the PDF is correct.”

The reporting doesn't say how many other places the two versions differ. The team confirmed one divergence after two weeks of work, in one paper out of 722, and Discoverai stresses that publication is not acceptance by mathematicians or the Clay Institute. In our view, the weak point is the GitHub description. It calls the code a formalisation of the paper's results, yet by Buzzard's account a compiling proof cannot vouch for the PDF.

Who reads the 722 papers

OpenAI told New Scientist it will fix errors in the natural-language proof as they are found and keep formalising the 722 papers. It has given no timeline. Hansen hopes the company takes the team's work “very seriously” and wants more work on robust auto-formalisation. Asked whether the field has a solution yet, he says “Not yet”. A controlled method will come, he says, but “the optimal and the ultimate way of doing this is completely unknown.”