Claude Formalized Fermat’s Last Theorem. A Small Fable 5.1 Test

A model hands you a convincing mathematical proof. Before putting it into a coding agent’s workflow, you need an answer to a less glamorous question: did it prove the statement you actually asked for? The Fermat’s Last Theorem announcement gives developers a substantial example of what that check involves. It also gives them a misleading place to start if they treat an eleven-day research campaign as a prompt they can reproduce over lunch.

On September 4, 2026, Anthropic reported a complete, computer-checked formalization of Fermat’s Last Theorem in Lean. Claude is Anthropic’s AI model family; this research used an internal model and followed an existing mathematical argument. The new result concerns verification of that argument, rather than discovery of a new proof. For developers evaluating model-generated code or mathematics, the useful next step is a small, fixed theorem with an independently checked result.

Key takeaway

• Anthropic reports an end-to-end Lean formalization following existing work, including the exposition by Darmon, Diamond, and Taylor.
• The campaign used an internal research model described as roughly comparable to Claude Fable 5.1, alongside Prove2Me and a multi-agent setup.
• The published repository checks both proof validity and agreement with Mathlib’s statement of Fermat’s Last Theorem.
• A small theorem can test your generation-and-checking workflow; it cannot establish that you can reproduce the full research project.

What “formalizing Fermat’s Last Theorem” means

Fermat’s Last Theorem says that no positive integers a, b, and c satisfy a^n + b^n = c^n when the integer exponent n is greater than two. Positive matters: allowing zero would admit trivial equalities. The exponent condition matters too: 3² + 4² = 5² is a familiar counterexample when n = 2.

A human mathematical proof can refer to a known result, omit an elementary calculation, or rely on the reader to unpack a definition. Formalization turns that argument into declarations and proof terms that a proof assistant can check. Lean is the proof assistant; Mathlib is the community library of formalized mathematics on which this project builds.

This work is more demanding than translating sentences into another programming language. Missing intermediate steps must become explicit proofs, and the definitions must line up across thousands of dependencies. But it remains a different task from finding a previously unknown argument. Anthropic explicitly makes that distinction in its announcement and credits the human mathematical and open-source work behind the result.

Anthropic’s research explanation identifies verification as the new contribution. Captured September 7, 2026.

The research article reports eleven days, thirteen million lines of Lean, and about six billion output tokens. Anthropic says its generated proof is likely much longer than necessary, whereas Mathlib is concise and reviewed.

Anthropic reports thirteen million lines of Lean and 30,300 verifiable theorems generated in eleven days, with roughly 29,500 used in the final proof.

An internal Claude model, Prove2Me, and collaborating agents

The campaign used a “general-purpose internal research model roughly comparable to Claude Fable 5.1,” according to Anthropic. It ran with a Claude Code-based multi-agent harness and Prove2Me, a collaborative formalization platform.

A public Fable 5.1 API call can generate a candidate proof, but it starts without the campaign’s accumulated theorem library or coordination state. The reported six billion output tokens cover the research campaign, whose internal model has no public API price specified in the announcement.

Anthropic also reports failed attempts before the successful campaign. Agents initially made progress, then lost track of project state and stopped collaborating effectively. Prove2Me supplied the shared project state for the successful attempt.

Prove2Me kept a directed acyclic graph, or DAG: a map of which theorem depends on which earlier theorem, without circular dependencies. Agents could use it to select work that was ready. The platform also separated theorem statements from proofs to improve compilation and maintained natural-language descriptions to help search and reuse.

Prove2Me tracks theorem dependencies, separates statements from proofs, and uses natural-language descriptions to help agents find and reuse results.

A transcript saying “lemma finished” is weaker than a stored theorem, its dependencies, and a successful checker result. When an agent restarts, that recorded state tells it what it can safely build on. Our Claude Agent SDK article discusses the related problem of supervising tool execution and recording outcomes.

Three different checks sit behind “verified”

The official repository README describes three checks: proof validity, agreement with the target statement, and acceptance by a second kernel.

Check	Question it answers	What to inspect
Lean build and axiom report	Does this proof follow from the permitted foundations?	FinalCheck.lean, build result, reported axioms
Comparator	Is the proved statement the intended Mathlib statement, with matching definitions?	verification/comparator/Challenge.lean and checker verdict
Independent kernel	Does another implementation accept the exported proof environment?	nanoda version, patches, and verification output

The default build requires exactly propext, Classical.choice, and Quot.sound, Lean’s three standard axioms. An axiom is an accepted starting assumption. Here the point is to exclude an extra assumption that effectively grants the desired answer, or a proof placeholder such as sorry.

The repository records three checks and discloses the nanoda patches. Captured September 7, 2026.

The comparator checks the target against a challenge expressed using Mathlib. That addresses a failure a compiler cannot diagnose on its own: a model might make a difficult theorem easy by changing its hypothesis, its definition, or its conclusion. A valid proof of a different proposition does not answer your question.

The repository further reports checking with nanoda, an independent Lean kernel written in Rust. Its maintainers disclose four patches: progress output and three changes to speed up definitional-equality search. They state that these do not weaken typing rules. The second implementation adds another check of the exported proof environment.

The README states that the result depends on the correctness of the checking kernels and tools. Human readers still need to understand what statements mean.

Read a theorem’s statement before trusting its name

The public theorem explicitly includes natural numbers, 3 ≤ n, and positive a, b, and c. Those conditions are part of the result, not comments around it. Removing a condition can make a true theorem false; adding one can make the intended challenge much easier.

The same care is needed for intermediate results. The repository’s proof-path document specifies the exact strength of named steps. Its Mazur-related result proves the irreducibility needed for the relevant Frey curves, intermediate mathematical objects constructed in this proof; the document explicitly says it does not prove Mazur’s general rational-isogeny or torsion theorems. These intermediate results apply under narrower conditions than the general classical theorems bearing those names.

PROOF-PATH says the Lean statements take precedence over prose and named results have the strength needed here. Captured September 7, 2026.

For a first experiment, keep the target outside the model’s control. Let the model supply the proof body. Review any requested changes to imports or assumptions separately. If it replies “this works if we assume the conclusion,” you want a failed experiment in the log, not a green check beside a weakened target.

Start with one small Lean theorem

On September 7, 2026, the small-theorem test sent a single request through SandBase to anthropic/claude-fable-5.1. The task was to prove (n + 1) * (n + 1) = n * n + 2 * n + 1 for natural numbers, without Mathlib, added axioms, or unfinished proofs. This tests expansion and arithmetic in a tiny example, not Fermat’s Last Theorem.

The Fable 5.1 model page is the specific entry for that public model. To repeat the small generation test, select anthropic/claude-fable-5.1, set max_tokens to 1800, and send one user message with the original prompt below. The recorded run used SandBase’s MCP sandbase_run tool; use the selected endpoint’s schema for a new API client, rather than assuming all endpoints accept the same format.

Return only complete Lean 4 source code, without Markdown fences or prose. Use Lean 4.33.1 with import Std, no mathlib. Prove theorem add_one_square (n : Nat) : (n + 1) * (n + 1) = n * n + 2 * n + 1. Use only proved lemmas/tactics: no sorry, admit, axiom, unsafe, native_decide, or extra assumptions. Include #print axioms add_one_square after the theorem. Aim for a short proof.

Save the first response unchanged, then run the Lean commands below and record its new charge separately. A rerun can return different code or cost. The API supplies neither the internal research model nor Prove2Me’s accumulated project state, and it does not run the local Lean checker for you.

The returned code was:

theorem add_one_square (n : Nat) : (n + 1) * (n + 1) = n * n + 2 * n + 1 := by
  simp only [Nat.mul_add, Nat.add_mul, Nat.mul_one, Nat.one_mul]
  omega

#print axioms add_one_square

Nat means natural numbers. The simp only line expands the products using the listed identities; omega finishes the remaining natural-number arithmetic. Multiplication by the variable has already been expanded, leaving the same nonlinear term on both sides.

The unmodified file passed on the official Lean 4.33.1 macOS ARM64 binary, with exit code 0. The axiom output was:

'add_one_square' depends on axioms: [propext, Quot.sound]

There was one model request and no repair attempt. The prompt requested import Std; the model omitted it, but this exact file ran successfully in the tested Lean environment without adding the import. The returned billing record was $0.07163. The response did not expose token counts. These are observations from one run, not a success-rate estimate or a model ranking.

To check the same candidate, install Lean using the official setup instructions, save the code as Generated.lean, and select the tested toolchain explicitly:

elan toolchain install leanprover/lean4:v4.33.1
lean +leanprover/lean4:v4.33.1 --version
lean +leanprover/lean4:v4.33.1 Generated.lean

Check the exit code and the axiom output, and compare the theorem header with the intended target. Here the reported dependencies contain no sorryAx, the marker associated with an unfinished proof. For this example, a smaller axiom list than the Fermat project is expected: these are different proofs, and their permitted-dependency checks should be defined for their respective tasks.

Turn the small test into a useful evaluation

Once one candidate compiles, try a modest set of distinct tasks. Ask for a natural-number identity, an implication with a supplied hypothesis, and a short list property. Keep the statement, Lean version, allowed imports, token limit, and retry limit fixed across models. Familiar elementary theorems are useful integration checks but may have appeared in training material; they are poor evidence of novel mathematical discovery.

Record the first response separately from any repaired response. If Lean reports an unknown theorem name, send back that exact diagnostic and allow a bounded retry. Preserve the original attempt. Otherwise a model that needs several repairs looks identical to one that generated valid code immediately.

A useful result row contains the requested model identifier, frozen target, attempt number, compiler exit status, axiom report, elapsed time, and API usage. Record a missing cost as unavailable, rather than estimating it from an unrelated price page. If the endpoint returns a model label, retain that too; the requested label alone is not independent evidence of an underlying checkpoint’s identity.

There are several distinct failure outcomes. Invalid syntax is a generation failure. A valid proof of a changed statement is a target-preservation failure. A remaining sorry is an incomplete proof even if Lean accepts the file with a warning. A timeout is a resource outcome, not evidence that the theorem is false. Separate outcomes make it possible to count syntax failures, changed targets, incomplete proofs, and timeouts independently.

The checker also needs operating limits. Give each run a disposable directory and a time and memory budget. Do not let generated code change the reference statement or the command that judges it. Importing a pre-existing proof of the exact target is library reuse; it can be useful automation, but it tests a different ability from constructing a proof from smaller lemmas.

FAQ

Did Claude discover a new proof of Fermat’s Last Theorem?

No. The September 4 result formalized an existing argument, following the exposition by Darmon, Diamond, and Taylor. Claude supplied Lean code that makes the reasoning machine-checkable. The mathematical proof route predates this project.

Was the eleven-day project run with the public Fable 5.1 model?

Anthropic describes an internal research model roughly comparable to Fable 5.1, supported by a Claude Code-based multi-agent harness and Prove2Me. The separate small-theorem test used the public anthropic/claude-fable-5.1 endpoint through SandBase.

Can a laptop check these proofs?

The small example passed on macOS ARM64 using Lean 4.33.1 without Mathlib. Full-project verification needs considerably more resources: the repository reports a 96-job build taking 5 hours 32 minutes, peaking at 153 GB of memory. The comparator took about fifteen hours, with a recommendation to allow 300 GB of memory. Its environment uses Lean 4.33.1 and Mathlib v4.33.0 pinned by commit. The full build, comparator, and nanoda checks were not rerun in the small test. To explore the complete proof without compiling it, start with the repository’s README, PROOF-PATH.md, and offline HTML theorem pages.

Does a successful Lean command mean the proof is complete?

Not by itself. Lean can accept a file containing sorry, an unfinished proof, with a warning. Inspect the axiom report for sorryAx or unexpected assumptions and compare the target with the requested statement. The small test exited with code 0 and reported only [propext, Quot.sound]; its theorem matched the requested identity.

How much did the Fable 5.1 test cost, and did it need repairs?

The single request cost $0.07163, and its returned code passed without edits or retries. The response did not expose token counts. This is one elementary algebra result, not a measured success rate or an estimate of the Fermat campaign’s cost.

Use the Fable 5.1 model entry to generate a candidate proof, then run Lean against the fixed statement. SandBase supplies model/API access; Lean supplies proof checking.