Claude’s Fermat Formalization Reality Check: 13M Lean Lines, 6B Tokens and What Was Actually Verified
Anthropic’s Claude-driven system produced a 13-million-line Lean formalization of Fermat’s Last Theorem in 11 days. The public artifact checks, but the exact internal model, true cost and full generation process remain unreproduced.
Claude’s Fermat Formalization Reality Check: 13M Lean Lines, 6B Tokens and What Was Actually Verified
Anthropic published a striking result on September 4, 2026: a Claude-driven multi-agent system produced an end-to-end Lean formalization of Fermat’s Last Theorem (FLT) in about 11 days. The released artifact is enormous—about 13 million lines of Lean—and Anthropic says the run proved roughly 30,300 theorem statements, with about 29,500 used in the final dependency tree, while consuming about six billion model output tokens.
The headline is real, but it needs careful labeling. This was not a new proof of Fermat’s Last Theorem, and the model used was not publicly identified as Claude Fable 5.1. Anthropic describes the model only as a general-purpose internal research model “roughly comparable” to Fable 5.1. That distinction matters for reproducibility, pricing, benchmark comparisons and claims about what a currently available Claude model can do.
What was actually proved
The released repository states a standard natural-number version of FLT in Lean 4: for natural numbers a, b, c greater than zero and exponent n >= 3, a^n + b^n cannot equal c^n.
The artifact is pinned to Lean 4.33.1 and Mathlib v4.33.0. Its default verification target checks that the final theorem depends on exactly Lean’s three standard axioms used by this development—propext, Classical.choice, and Quot.sound—and contains no unproved sorry placeholders in the proof package. The repository also states that it contains no added axiom, native_decide, unsafe, extern, implemented_by, partial def or runtime #eval shortcuts.
Anthropic’s repository reports three verification layers:
- A from-scratch Lean build checked 60,475 modules through the Lean kernel.
- The Lean
comparatortool replayed the result against a challenge statement written from stock Mathlib definitions and returned a successful verdict. nanoda, an independently implemented Lean kernel written in Rust, accepted an exported environment containing 1,052,234 declarations with no errors. Anthropic says it applied four small performance/progress patches to nanoda, none of which changes the typing rules.
This is stronger evidence than a typical vendor benchmark screenshot because the complete artifact is public and the final theorem can be replayed by other people. It is still useful to distinguish artifact verification from reproducing the 11-day generation process. The public evidence supports that the released Lean object checks; it does not provide a frozen public endpoint, immutable model snapshot, exact prompts, full input-token count, hardware ledger or a turnkey replay of the agent campaign.
Independent review is unusually substantive
Kevin Buzzard, who leads the long-running Imperial College London FLT formalization project, did more than comment on the announcement. In a September 4 post, he said he compiled Anthropic’s code base and ran the comparator himself, and that it checked out. He measured the repository at more than 13.4 million lines and described the compile as nearly 20 times slower than Mathlib on a 96-core machine.
Buzzard also addressed a concrete concern raised in the discussion: could an AI have exploited a proof-checker bug or hidden a malicious non-mathematical shortcut in such a huge repository? He said he manually inspected the non-definition/non-proof code surface and carefully reviewed the roughly 100 lines that did not fit the ordinary mathematical categories, concluding that they were benign convenience tooling. That does not make every dependency formally immune to future kernel bugs, but it is meaningful independent scrutiny beyond Anthropic’s own release notes.
His interpretation is also more nuanced than “AI solved Fermat.” Mathematically, he says the formalization adds essentially no new mathematics because it faithfully follows established literature. What excites him is the autoformalization capability: if thousands of pages of sophisticated number theory can be translated into machine-checkable form at this speed, formal verification could become practical for modern mathematical literature and peer review.
The scaffold was part of the result
Anthropic reports that earlier Claude attempts made progress and then failed because the agents lost track of project state and stopped collaborating effectively. About 7% of the non-boilerplate lines in the final proof came from those failed attempts.
The successful run changed the system design. Anthropic switched to Prove2Me, an open collaborative formalization platform developed by Tianyi Peng and collaborators. Prove2Me maintains a directed acyclic graph of theorem statements, separates statements from proof files, and stores natural-language descriptions so agents can search for and reuse already-proved results. Anthropic paired this with a Claude Code-based multi-agent harness.
That is an important evaluation lesson. The result measures an internal model + Claude Code multi-agent harness + Prove2Me collaboration protocol + Lean/Mathlib toolchain + existing human formalizations, not a raw model in isolation. Treating it as a single-number Fable 5.1 capability claim would erase the system components that Anthropic itself says made the difference.
The Prove2Me paper explains why this architecture matters. A proof kernel certifies that a term proves a formal statement, but it does not automatically certify that every generated statement faithfully captures the intended informal mathematics. The paper notes recent evidence that automatic statement-faithfulness auditing remains imperfect. Prove2Me therefore keeps a smaller human-audited mission core—goal statements, definitions and milestone lemmas—while allowing agents to generate intermediate lemmas underneath that audited surface.
Six billion output tokens: cost needs a model-identity warning
Anthropic reports approximately six billion output tokens for the FLT campaign. The exact internal research model has no public API ID, price sheet, context specification or latency profile in the evidence checked here. Therefore, the actual cost of this run is not publicly established.
A useful but explicitly hypothetical comparison is the public Claude Fable 5.1 rate. Anthropic currently lists Fable 5.1 at $10 per million input tokens and $50 per million output tokens, with a 1M-token context window and 128K maximum output. Multiplying six billion output tokens by the public $50/M output rate gives a $300,000 output-only list-price equivalent. That is not the project’s actual bill or Anthropic’s compute cost: the run used an internal research model, input tokens are not included in that simple calculation, caching and batching can change economics, and internal infrastructure costs do not equal retail API prices.
The public Fable 5.1 specification is therefore context, not identity evidence.
Why SWE-bench scores do not belong on this result
SWE-bench Verified and SWE-bench Pro are software-engineering benchmarks. Neither is an appropriate substitute for this formal-mathematics result, and the FLT campaign does not publish an exact score for either.
More importantly, the internal research model is not exposed with a reproducible public revision. Even if Fable 5.1 has published coding scores elsewhere, those scores should not be imported into the FLT result as if the same checkpoint and harness produced both. The correct comparison unit here is the full formalization system and its released proof artifact.
For future evaluations, a useful formal-math benchmark report should preserve at least: exact model snapshot or provider fingerprint, harness commit, Prove2Me revision, Lean and Mathlib versions, mission definition, number of agents, retry policy, input/output token counts, wall-clock time, hardware or provider tier, total cost, success criteria, and independent replay status.
What the public reaction actually says
Anthropic’s launch post on X amplified the “largest Lean proof” claim, but the most technically useful public feedback I found came from the people inspecting the artifact rather than from social-media sentiment.
Buzzard’s September 4 review is strongly positive about the autoformalization implications while explicitly saying the work does not add new mathematics. The comment thread under his post is mixed: participants debate how to interpret the six-billion-token cost, whether proof-assistant bugs could be exploited, and whether a gigantic machine-generated formalization is a substitute for a short, readable modern proof. Buzzard’s response is effectively “both can matter”: the machine proof checks, while the human-oriented project still has value for readability, library engineering and modern exposition.
That disagreement is useful evidence, not noise. It shows why “computer-checked” and “human-understandable” are different quality dimensions.
Practical takeaway
The most defensible conclusion is not that Claude “solved” Fermat’s Last Theorem. Wiles and the mathematical community already solved it. The milestone is that an AI-agent system appears to have compressed a formalization task expected to take years into days while leaving behind a public artifact that can be independently checked.
The strongest evidence is the released Lean repository, the pinned verification stack and Buzzard’s independent compile/comparator review. The biggest unknowns are the exact internal model revision, true run cost, full generation transcript and whether another team can reproduce the same 11-day process with a public model and frozen harness.
For AI evaluation, this is a reminder that some of the most important capability advances will not fit neatly into one benchmark score. Harness design, persistent shared state, formal verification and reusable intermediate work can change what an agent system can accomplish. Future comparisons should measure the whole system—and label each part precisely.
This article is built from the source material below. Open the originals for full context and the latest updates.