Anthropic's new Fermat formalization drew 480 points and 314 comments on Hacker News within hours, while the repository was recorded at 130 GitHub stars on the day it was created. Those are attention signals, not mathematical validation. The number developers should sit with is 230 GB: that is the peak memory Anthropic reports for the comparator run used to recheck the finished proof.
The research announcement says Claude produced a complete computer-checked proof of Fermat's Last Theorem in 11 days. It is a striking compression of labor, yet the public artifact also makes the costs unusually visible: 13 million lines of Lean, about six billion output tokens, and verification jobs built for machines far larger than a typical workstation.
What Claude actually produced
Fermat's Last Theorem says that positive integers cannot satisfy a^n + b^n = c^n when n is greater than two. Andrew Wiles, with Richard Taylor, completed the accepted human proof in the 1990s. Anthropic's work encodes an existing route through that mathematics in Lean 4 so a small proof-checking kernel can verify every formal step. The company describes it as the first complete computer-checked formalization, rather than a new proof strategy for the theorem, in its account of the project.
The public Lean repository exposes the top-level claim in a form that developers can read without knowing the deeper number theory:
theorem fermat_last_theorem (n : ℕ) (hn : 3 ≤ n)
(a b c : ℕ) (ha : 0 < a) (hb : 0 < b) (hc : 0 < c) :
a ^ n + b ^ n ≠ c ^ n
That declaration matters because a proof assistant checks a precise type, not the informal reputation of a theorem. Anthropic's final check derives Mathlib's own FermatLastTheorem statement from this declaration. It also fails the build unless the result depends on exactly three standard Lean axioms: propext, Classical.choice, and Quot.sound. The repository documentation says the package contains no sorry, added axiom, native_decide, unsafe escape, or external implementation in the proof modules.
The harness carried the long project
Dozens of agents worked through a Claude Code multi-agent harness, using a general-purpose internal research model that Anthropic compares with Claude Fable 5.1. According to the company's report, early attempts broke down when agents lost track of project state and stopped coordinating. Those failed branches still account for roughly 7 percent of the non-boilerplate lines in the final repository.
The successful run used Prove2Me, a collaboration system developed by Tianyi Peng and other researchers. It keeps theorem statements in a directed graph, separates statements from proof files, and lets agents search for results they can reuse. The Prove2Me paper explains why this structure exists: large Lean projects can serialize around a merge queue, and a proof edit can trigger compilation across downstream dependencies. The platform makes individual statements immutable objects with separately submitted proofs.
That division of labor is as informative as the model result. The agents generated Lean at huge scale, but the harness decided what work was available, preserved dependencies, and kept completed results findable. Anthropic reports that the run used about six billion output tokens. A developer evaluating the result should therefore treat the orchestration system, pinned Lean environment, and model allocation as parts of the experiment described in the research post.
Scale here is a search record as much as a source-code metric. The same post reports 30,300 theorems completed during the run and about 29,500 used in the final proof. It puts the 13 million lines at more than five times Mathlib's size, while noting that Mathlib is concise and reviewed. The excess points to breadth and duplication; it does not make every generated declaration a library-quality abstraction.
Kernel checks still leave a human audit surface
Anthropic reports three levels of technical verification in the repository README. A clean lake build checked all 60,475 modules with Lean 4.33.1 and Mathlib 4.33.0. Lean's comparator then replayed the package and confirmed that the public statement matched the challenge statement. Nanoda, a second Lean kernel written in Rust, accepted an export containing 1,052,234 declarations without errors. Anthropic applied four patches to Nanoda, which it says changed progress reporting and sped up equality search without changing typing rules.
Reproducing those checks is a serious systems job. Anthropic's build took 5 hours 32 minutes with 96 jobs, peaked at 153 GB of memory, and used about 67 GB under .lake, plus roughly 220 GB of temporary C files. The comparator ran for 14 hours 46 minutes on one core and peaked at 230 GB, with the README advising 300 GB of available memory. Exporting the environment for Nanoda produced a 37.8 GB file. These figures come from Anthropic's own run and are documented as reference requirements, not minimums guaranteed for every machine, in the reproduction instructions.
A kernel can prove that a term has the type it claims. It cannot decide whether every human label attached to an intermediate theorem conveys the intended mathematics. The repository warns that machine-generated names can disagree with their statements and says the statement wins in that case. The Prove2Me paper frames the same issue as semantic faithfulness: a formally valid statement can still omit a hypothesis or encode the wrong idea, so humans audit the goal, definitions, and milestone lemmas.
Anthropic narrowed that risk at the top. The FLT statement uses Lean's natural numbers and ordinary operations, while the comparator checks those definitions against stock Mathlib. The project also publishes PROOF-PATH.md, which maps named mathematical steps to Lean theorems. That makes review possible without pretending 13 million generated lines are pleasant source material, a limitation the repository itself states plainly.
Open code does not make this a drop-in library
The proof is released under Apache 2.0, but Anthropic labels it a research artifact that will not be maintained and is not accepting contributions. Its offline documentation bundle is about 390 MB and includes pages for 29,511 theorems and 1,450 definition modules. The generated English summaries help navigation; the Lean statements remain authoritative.
The code also rests on years of human work. Anthropic credits the Imperial College London FLT project led by Kevin Buzzard, the flt-regular project, Lean, and Mathlib. The attribution notes identify 106 files containing material from the first two projects and 23 files that reproduce Mathlib text. Anthropic's agents assembled and extended that base; they did not begin with an empty theorem library.
That provenance affects what can happen next. The artifact proves that a very large generated development can pass pinned kernels, but its size and maintenance status may limit direct adoption. Reusable definitions and lemmas would need review, cleanup, and likely upstream work before other Lean projects could depend on them comfortably. The research announcement concedes that its proof is probably much longer than necessary.
The next evidence to watch is independent reproduction on the pinned toolchain, followed by outside review of the audited statements and the route recorded in PROOF-PATH.md. Compression will matter too: a smaller proof, or reusable pieces accepted into maintained libraries, would say more about day-to-day mathematical tooling than another increase in generated line count.
Reviewers can separate semantic audit from compute-heavy replay. The top statement, compatibility definitions, and proof path can be inspected first. Kernel builds and the longer comparator or Nanoda runs can follow on suitable hardware. The repository pins versions and supplies scripts for each check, so a failed reproduction can be traced to a specific stage.
For now, the public repository gives researchers enough material to test the claim, provided they can supply the compute and the human reading time.