Claude proved Fermat’s Last Theorem in 11 days. Nobody can read the result

Anthropic said on 4 September 2026 that its AI wrote a full proof of Fermat's Last Theorem in 11 days. The proof is mathematically correct, yet completely unreadable by human eyes and surprisingly expensive for even modern machines to verify

Tianyi Peng builds tools that let AI systems write mathematical proofs a computer can check. He runs a group at Columbia University and is also a researcher at Anthropic. Years ago, when he was still an undergraduate, his adviser wanted to include results from Peng's thesis in a Nature paper. First he asked one question: was Peng sure the proof was correct?

Peng's answer was honest. "I'm 99% sure, but it's hard to be 100% certain about a proof this long." The result did not make it into the paper.

His current work exists to close that gap. Mathematical proofs are usually written for other mathematicians, so they skip steps a trained reader is expected to fill in. Formalization removes that assumption. It means writing out every step, then having a program check them. The main program for this is Lean, a proof assistant that checks whether each step follows from the rules it has been given.

Peng wanted to know whether Claude could do that for Fermat's Last Theorem. The claim itself is short: no three positive whole numbers a, b and c satisfy aⁿ + bⁿ = cⁿ when n is greater than 2. Pierre de Fermat scribbled it in the margin of a book around 1637. Nobody managed to prove it for more than 350 years.

It took 11 days. Anthropic published the result on September 4: 29,511 theorems in the final proof, and about 13.5 million lines of Lean. At 02:00:57 UTC on August 18, the top-level entry for the theorem changed to "Proved."

The run was largely autonomous, but not unattended. Peng stepped in now and then with directions like "Jacobian as a scheme sounds high priority." Anthropic released parts of Claude's reasoning logs, and the Lean repository is public. The full list of those interventions is not.

Andrew Wiles finally proved the theorem in 1995, in 129 pages. About two months into refereeing, a reviewer found a critical gap. Wiles spent roughly a year repairing it and came close to giving up.

The proof contains no new mathematics

Anthropic is explicit about what did and did not happen. Claude did not discover a new proof. The mathematics follows Andrew Wiles's proof through the streamlined account developed by Darmon, Diamond, and Taylor. The novelty is in verification. Think of a calculator checking a multiplication: it did not find the result, but it can confirm that the steps lead to it.

That still leaves two substantial claims. First, according to Claude's own assessment, Fermat's Last Theorem was the one remaining item on the "100 theorems" list, a list the formalization community tracks, without a complete formal proof. It now has one. Second, Kevin Buzzard, who inspected the result, argued that AI-generated formalizations are now reliable enough to build on.

He went further. Techniques like these could reduce the burden on referees and make it practical to rigorously check mathematics produced by large language models, work that is currently expensive and heavily dependent on human labor. The claim deserves weight, because it points the other way: perhaps formalization does not merely move the verification burden. Perhaps it can shrink it.

Buzzard's own Imperial College London FLT project makes the difference clearer. The project is funded to 2029, and its current phase stops short of the axioms. Instead it reduces Fermat's Last Theorem to deep results known by the late 1980s and temporarily assumes them. The first-phase plan alone runs to 86 pages.

Axioms are the handful of assumptions a system takes without proof. Lean has three. Everything in Mathlib, the shared library nearly every Lean proof draws on, is built on those three.

Claude's proof goes all the way down to them, by an older route, formalizing the hard intermediate results only at the strength the argument needs. Both projects are checked by the same program against the same three axioms. What separates them is form. Claude's own assessment, published by Anthropic, puts it this way: "Ours is a finished proof delivered as 60,474 almost entirely machine-written files. Theirs is an unfinished library written for people to read, reuse and maintain."

One more qualification. Claude did not start from an empty repository. The project's NOTICE file credits three Apache-2.0 sources, including Buzzard's Imperial project and Mathlib, and ATTRIBUTION.md identifies 106 files containing material derived from them. "Imperial spent five years while Claude did it in 11 days" would be the wrong comparison.

The "Proved" mark on the platform was not an end-to-end check

Prove2Me checked cards separately. A card is one theorem stored with the imports it needs, so Lean can compile it on its own. When one card depends on another, it uses that card's statement without rebuilding its proof. The kernel, the small part of Lean that actually accepts or rejects proofs, had checked every piece. It had not checked all 29,511 pieces assembled into one project.

The morning after the root card closed, the team recompiled all 29,511 cards from source outside Prove2Me. A day later they built the whole tree as one Lean project. That build fails unless the final result depends on exactly the three standard axioms, and unless not a single sorry remains, the placeholder Lean accepts for a proof you have not written yet.

comparator, version 4.33.0, then checked the submission against a separate file stating Fermat's Last Theorem using Mathlib alone. It confirmed that the final statement and every constant in it matched that file exactly, then replayed the whole proof through the kernel, Mathlib included. The final line was Your solution is okay!

nanoda, version 0.4.13, is a Lean kernel rewritten independently in Rust. Rather than asking Lean's own kernel whether the proof holds, it implements the checking rules again from scratch. It accepted 1,052,234 declarations with no errors.

A declaration is any single named thing Lean has to accept: a definition, a theorem, a small lemma nobody will ever read.

That is roughly thirty-six declarations for every named theorem in the proof, and each one had to check. Nanoda ran with four small patches for progress output and speed, none of which, according to the repository, changed a typing rule.

About 25 minutes after the final open statement was proved, Claude wrote its own status note:

Until the re-check reads clean the honest sentence is "proved on prove2me, pending the independent re-check" rather than "FLT is formalized".

The first attempt collapsed on coordination

The first attempts failed. Anthropic says the agents made early progress, then lost track of the state of the project and stopped working together effectively. Some of that work survived: about 7% of the non-boilerplate lines in the final proof came from those failed attempts. Boilerplate is the repeated setup code that appears across many files, so the 7% measures mathematical content.

Anthropic published a failure rate it could have kept to itself.

The blog does not give a detailed post-mortem of why that run failed. The Prove2Me paper, whose authors include Peng, describes the general failure mode the platform was built to avoid. The obvious way to parallelize a Lean proof is to leave sorry holes throughout a shared project and send agents out to fill them.

Change a lemma, one of the smaller results proved on the way to a bigger one, and everything standing on it may need to compile again. On something the size of Mathlib, a one-line edit can cost hours.

Sharing the files creates another problem. If several agents edit the same files, their contributions start depending on one another. Git can manage this, and large Lean projects use pull requests for exactly that reason. But somebody still has to review and merge them. The Prove2Me paper calls that merge queue an empirical bottleneck for large agent swarms. A system that begins with decentralized workers ends up waiting on a person at the point where their work has to come together.

Conflict also takes a more mathematical form. Two agents can formalize the same intended lemma in incompatible ways, and work done on top of one version is then useless to the other. The same lemma gets proved twice. Worse, if one formalization quietly drifts from what the source mathematics intended, every proof that imports it inherits the mistake. Lean can still verify the chain perfectly. It is verifying the chain it was given.

Isolation is what made the agents work

Prove2Me separated a theorem's statement from its proof.

It is a small change on paper, and everything else in the platform depends on it. A statement, once accepted, never changes, so an agent can attack it without disturbing anyone else's work, and the card carries its own imports, so it compiles alone.

The payoff is proof-sketches. A proof-sketch proves a theorem by importing others, including ones nobody has proved yet. A card can reduce a hard theorem to three smaller ones and be accepted while all three are still open. Those three become separate jobs, and an agent can take one without ever downloading the theorem above it. When the children are proved, the parent completes on its own. The same split then repeats downward to the leaves. That is how one theorem becomes 29,511.

Agents also began correcting each other. In one mission an agent built a proof-sketch on a theorem it called gotsman_linial. A second agent came along and disproved it. The first then produced gotsman_linial_with_zero, supplying the boundary condition it had missed, and that corrected version closed the whole branch.

Two mechanisms keep parallel work from turning into duplicate work. Each mission has milestones, chosen by the human who proposed it: an authoritative sentence copied from the source, paired with one approved Lean version of it. Independent attempts converge on that one statement. And every proved theorem enters a shared library, Formalpedia, which any later proof in any mission can import. Agents must attach a plain-language description to each statement, and search reads those descriptions. The harness tells them to look before they invent.

A harness is the scaffolding around a model: the tools, the rules, the instructions that decide what it can see and what it may do. Same model, different harness, different result. Most of this story lives in that gap.

Humans stopped reading proofs. They audit a mission's core, the goal, its definitions and its milestones, and nothing beneath it. An auditor agent sees only the Lean statement and translates it back into ordinary mathematics, so the human reads two sentences of plain mathematics. Trust now rests on the kernel accepting proofs of statements a human actually read.

Two in five statements in the proof repeat one already written elsewhere

Claude's own explanation is that each card was proved in isolation, which is why the proof repeats itself so heavily. Of the theorem statements in the proof files, roughly 40% duplicate one written word for word somewhere else. About one in five lines are verbatim copies of declarations found in another file. One basic lemma was redefined in more than 300 files. Mathlib avoids this because the people writing it read each other's code, while an agent working on one card had no reason to look at another.

The isolation shows up in the environment around the proofs too. About 31% of the bytes are generated preamble: the setup block at the start of each file that fixes what the checker is allowed to use automatically. Heartbeats tell Lean how much work it may spend on a step before giving up. Around 11,700 files raise that limit, sometimes to 2,000 times Lean's default and sometimes without a limit at all, on a package default already twenty times higher.

Mathlib, at the same commit, has five.

Then came a routine upgrade. Lean 4.30 moved to Lean 4.33, together with the matching Mathlib version. 7,620 of the 29,511 proof files changed, and 5,672 of them, nearly a fifth of all proof files, had to be repaired individually. A dependency update had reached into thousands of supposedly isolated units.

The repository does not pretend this is polished library code. Its own description is "Research artifact. Not maintained and not accepting contributions." The files were "written to be checked rather than read." Comments were removed before release. More than 900 files exceed Mathlib's 1,500-line limit; Mathlib itself has two. ATTRIBUTION.md also identifies 22 modules that reprove, locally, lemmas already available in Mathlib.

The largest duplication figures here come from Claude auditing its own output and were published by Anthropic, without independent reproduction. Only the 22 modules in ATTRIBUTION.md come from the repository's own records.

Checking it once costs about a day and 300 GB of memory

The repository tells you how to check the proof yourself. Inside verification/ are two scripts that download and build pinned versions of the independent checkers. The process works on Linux and macOS. Windows is excluded for a mundane reason: some paths in the generated tree are too long.

Running it is the harder part. Anthropic's full build used 96 parallel jobs, took 5 hours 32 minutes, and peaked at 153 GB of memory. Most jobs needed around 5 GB; a few individual modules reached 36 GB.

Then comparator replayed the proof through the kernel: 14 hours 46 minutes, peaking at 230 GB of memory. The README recommends giving it 300 GB. More hardware does not help much with the time, because almost all of that replay runs on a single core. Nanoda adds another stage. Producing its 37.8 GB export took about an hour and roughly 90 GB of memory; checking it took around half an hour with 16 threads and about 40 GB.

A well-specified laptop has 16 GB. The check needs three hundred.

Add the published components and the verification run comes to roughly 22 hours, on a machine with 96 cores available and hundreds of gigabytes of memory. Anthropic did not publish that total; it is arithmetic on the times it did publish, and nobody outside Anthropic has reproduced them.

Claude's agents spent 11 days producing the proof. Checking it once takes about a day.

And hardware only buys part of the verification. The repository says:

What no tool can check is that each intermediate theorem means what its name suggests; that is for the reader to judge.

The warning bites here because the theorem names are machine generated. If a name and its formal statement disagree, the statement is what was proved. Reading the label is not enough.

The verification burden did not disappear. Some of it changed currency, from referee hours into memory and core-hours. The compute is expensive, but it is automatic and it scales. The rest still requires someone to read mathematical statements and decide whether they mean what the proof claims they mean.

Your agents can each pass and still fail together

If your swarm produces work in isolated units and each unit passes its own checks, nobody has necessarily checked the thing they make together. Prove2Me's card-level "Proved" marks had exactly that limitation. In your own setup it looks less dramatic: twenty agents change twenty files, twenty test suites come back green, and nobody runs the repository with all twenty changes present.

Isolation also makes duplication easy to hide. Agents can solve the same problem several times without noticing, because each local solution works. Your artifact keeps growing while its useful content stalls. The two-in-five figure exists only because somebody counted after the fact.

Agentic work is still worth the trade. Claude's FLT run succeeded because the team let thousands of pieces progress without waiting for one another. It just means a green local check carries less weight than it used to, and you have to build the checking somewhere else. Six checks from this project that I would carry into an agent pipeline:

1. Fix the audit surface before the run, not after it. Decide which statements a human will actually inspect.
2. Rebuild the artifact as one piece, outside the platform that produced it.
3. Run the result through a second checker written independently of the first.
4. Measure how much of the output repeats itself before you call the result a library.
5. Upgrade part of the toolchain before you depend on the artifact, then count what breaks.
6. Write the honest status sentence, including what has not been checked yet.

Resources and further reading

• Anthropic, Formalizing Fermat's Last Theorem, 4 September 2026
• Claude's reasoning excerpts, verification account and self-assessment (PDF)
• The proof repository: anthropics/fermats-last-theorem
• Chen, Marwaha, Lu, Yuen and Peng, Prove2Me: An Open Collaborative Platform for Scaling Math Formalization, arXiv, August 2026
• Kevin Buzzard's Imperial College London FLT project
• leanprover/comparator and nanoda, the two independent checkers

All Infographics and diagrams in this article are created by GPT image 2.0

Thanks For Reading!

💡 Curious for more? I regularly publish new AI projects on GitHub. If AI chatter is your guilty pleasure, join the convo on Reddit.

You can also connect with me on LinkedIn for more professional insights and updates. Don't forget to follow me on Instagram for behind-the-scenes AI content and daily inspiration!