Claude did not discover Fermat’s Last Theorem or replace Andrew Wiles’s proof. Anthropic says it used an internal model to turn an existing proof into Lean code that a checker can validate. The useful story is what that validation establishes, and what it leaves outside the machine.
Anthropic disclosed the work on September 4. Its research account describes an 11-day effort using roughly six billion output tokens. The mathematical starting point was the Darmon, Diamond, and Taylor exposition of Wiles’s work. Human-written mathematical libraries and human direction remained part of the setup. The model was an internal research system described as roughly comparable to Fable 5.1, not a claim that a public chat session can repeat the run.
Formalizing a proof is not finding a new proof
Think of the distinction as two different questions. Does a mathematical argument exist? Can each required step be expressed precisely enough that a formal system accepts it? Fermat’s Last Theorem was already proved. This project addresses the second question at a scale that makes it worth examining.
That difference also changes the headline you should trust. “AI solves an unsolved problem” would be wrong here. “AI helps produce a machine-checked formalization” is narrower, but it points to a useful kind of automation: taking a difficult body of existing work and producing a checkable artifact. Our Claude science evidence guide applies a similar separation between an impressive result and the claim the evidence actually supports.
Start with the statement, then inspect the checker
The public Lean repository includes a comparison against the Mathlib theorem statement and a final proof check. Its environment pins Lean and Mathlib versions. The final check lists the standard axioms propext, Classical.choice, and Quot.sound. These are declared foundations, not a claim of assumption-free mathematics.
A successful build alone is too weak a reporting standard. A program can check a proposition that sounds similar to the intended one but differs in a definition or a missing condition. The first question is therefore semantic: is this the theorem we meant? Only then does a passed checker tell the reader something useful.
A verification checklist that travels beyond mathematics
| Check | Evidence to request | What it does not establish |
|---|---|---|
| Intended statement | Exact formal proposition and comparison to the target | That a familiar theorem name has the right definition |
| Proof acceptance | Checker output with declared assumptions | That no assumption or trusted component exists |
| Reproduction | Pinned dependencies and an executable build path | That every laptop can complete the job cheaply |
| Human interpretation | Readable mapping from the argument to the artifact | That generated summaries are mathematically authoritative |
| Reuse | Documented interfaces and maintained library components | That a one-off research artifact is production-ready |
The same ordering helps when reviewing an AI-generated test suite or data pipeline. First establish what the test is meant to prove. Then inspect what actually runs. Finally ask whether the next person can reproduce the result without the original author explaining every hidden assumption.
What the outside check adds
Mathematician Kevin Buzzard reports compiling the artifact and checking the comparison. He used computing resources provided by Anthropic. His account supplies expert scrutiny outside the author team, but it is not evidence that the work required no external infrastructure. He also distinguishes this result from the ongoing work of building a maintainable mathematical library.
That is a useful disagreement to preserve rather than flatten into a winner-and-loser story. A large checked object and a collection of clear, reusable components serve different readers. If you are funding formalization, define which one you need before picking a success metric.
The reusable agent lesson is shared state
Anthropic describes early attempts losing track of work. Its Prove2Me system instead tracked theorem dependencies and proof state, separating statements from proofs. That is a narrower engineering lesson than “add more agents.” The work needed a common record of what was settled, what depended on it, and what still failed.
For an engineering team, I would copy that discipline before copying the scale. Give each subtask an explicit acceptance condition. Keep a machine-readable status outside the conversation. Make failed checks visible to downstream work. A model producing more text is not progress if the dependency that blocks the release remains unresolved.
A small trial is more useful than chasing the token total
Choose one existing specification your team already understands. Freeze the expected statement and tool versions. Ask an agent to produce a checkable artifact, then have another person inspect both the statement and the checker output. Record setup time, failed attempts, manual changes, and the effort needed to rerun the result from a clean environment.
This is a proposed trial, not a test Musthave.ai has performed. Its purpose is to expose the human work around verification. Do not price Anthropic’s internal run by multiplying its output-token count by a public API rate: the research model, execution setup, and workload are not an ordinary public API invoice. If your separate project uses the released model, our Fable 5.1 API migration guide covers the actual integration changes.
My verdict: ask for the artifact, not the victory lap
The most interesting part is that the claim comes with something inspectable. I would judge the result through the exact theorem, checker, assumptions, and reproduction path. Then I would make a separate decision about whether the artifact is readable and reusable enough for my project. Those are different purchases.
What would your team need to inspect before calling an AI-generated result verified?
Checked September 4, 2026. Research figures are Anthropic-reported; Buzzard’s checks are attributed to his account. Musthave.ai has not independently rebuilt the Lean artifact. The review framework and trial design are editorial analysis.
