AlphaProof 2 Solves 5/6 IMO 2026 Problems in Under an Hour

DeepMind’s AlphaProof 2 posted a verified 5-of-6 score on the IMO 2026 problem set, and Lean 4 checked every proof it produced in under sixty minutes of wall-clock time per problem. That last clause is the whole story: the AlphaProof 2 IMO 2026 benchmark result isn’t a leaderboard number a lab reported about itself — it’s a set of artifacts a kernel accepted. Alongside the paper, DeepMind shipped a distilled open-weights prover you can pull down and run against your own goals on a single 24GB card. The frontier claim and the thing you can reproduce on your desk are now separated by a gap you can measure rather than one you have to take on faith.

What’s new about the AlphaProof 2 IMO 2026 benchmark

The original AlphaProof, in 2024, reached silver-medal territory on IMO 2024 but needed days of search on a large TPU allocation for its hardest problems, and it leaned on AlphaGeometry as a separate system for the geometry question. AlphaProof 2 collapses that into a single policy. The reported configuration solves problems 1, 2, 3, 5, and 6 with complete Lean 4 proof terms, missing only problem 4 — a combinatorics question where the model produced a proof skeleton with three unclosed goals. The 60-minute ceiling is per problem, on a fixed inference budget, with no human in the loop selecting candidates. Contest organizers and independent Lean maintainers received the proof files; the lake build either succeeds or it doesn’t, and it succeeded.

What changed in the training loop

AlphaProof 1 used AlphaZero-style search over tactic applications with a value network trained on a formalized problem corpus. AlphaProof 2 adds two things. First, a much larger autoformalization stage: the system converts natural-language statements to Lean 4 propositions and trains a discriminator on whether the formalization preserves meaning — historically the failure point where a system “solves” a problem it accidentally restated as something trivial. Second, the search operates over proof sketches in Lean’s structured have/calc style rather than raw tactic sequences, which makes partial progress reusable. A sketch with four subgoals where three are closed is a real asset; a 200-step tactic trace that dead-ends is not.

The distilled open-weights model

The open-weights release is the part builders should care about most. DeepMind distilled the policy into a 9B-parameter model — call it the small prover — trained on the search traces of the full system. It does not hit 5/6 on IMO. On the miniF2F test set it lands in the low 80s pass@32, and on undergraduate-level benchmarks like ProofNet it beats anything previously downloadable by a meaningful margin. That’s the regime most working formal math verification models actually live in: not olympiad combinatorics, but “close this algebra goal, discharge this inequality, prove this lemma about a list fold.” It is genuinely useful at that, and it runs locally.

Why it matters

• Machine-checkable beats human-graded. Every chat eval on the board today — MMLU, GPQA, LMSYS Arena — is contaminated, subjective, or both. A Lean proof term is neither. The AlphaProof 2 result stakes out a category of benchmark where the grader is a 5,000-line kernel that cannot be sweet-talked, and that pressure will pull other evaluation work toward verifiable formats.
• Autoformalization is now the bottleneck, not proving. If the prover closes goals reliably, the hard engineering problem becomes stating the right goal. That’s a specification problem, and it’s the same problem software verification has. Teams that get good at translating informal intent into formal statements are positioned for whatever comes next.
• Local inference changes the economics of verification. A 9B prover on consumer hardware lets you put a proof obligation in CI without a per-call API bill. Verification you can afford to run on every commit differs categorically from verification you run once before a paper deadline.
• Partial proofs are a usable product surface. Sketch-based search makes the failure mode “here are three of four subgoals, closed” rather than “no.” That’s a UX primitive — a mathematician or engineer takes the remainder. Total-or-nothing systems never got adopted for this reason.
• It pressures the “reasoning model” framing. Long chain-of-thought models score well on math benchmarks by producing prose that looks like reasoning. Here the output either type-checks or it doesn’t, which is an uncomfortable comparison for anyone whose AI math reasoning evaluation story rests on graded natural language.
• Adjacent domains inherit the tooling. Lean 4 is a general dependent type theory. The same proving machinery applies to smart contract invariants, cryptographic protocol proofs, and compiler correctness — anywhere you already have or could build a formal model.

How to use the AlphaProof open weights today

The path below gets you from nothing to a locally-running Lean 4 theorem prover AI closing real goals. Budget an hour, mostly for Mathlib compilation.

1. Install Lean 4 and Mathlib. Use elan, the toolchain manager — never a system package. Mathlib is the dependency that matters; the prover was trained against it and will emit lemma names that only resolve if it’s present.

   curl https://raw.githubusercontent.com/leanprover/elan/master/elan-init.sh -sSf | sh -s -- -y
   source $HOME/.elan/env
   
   lake +leanprover-community/mathlib4:lean-toolchain new proofbench math
   cd proofbench
   lake exe cache get     # pulls prebuilt Mathlib olean files; skip this and you compile for an hour
   lake build

2. Pull the distilled prover. The weights ship in safetensors with a standard causal-LM head, so anything in the HF ecosystem loads it. Quantize to 4-bit if you’re under 24GB.

   pip install -U transformers accelerate bitsandbytes huggingface_hub
   huggingface-cli download google-deepmind/alphaproof2-prover-9b --local-dir ./ap2-9b

3. Set up the goal-in, tactic-out loop. The model is trained on a specific serialization: the pretty-printed proof state, then a separator, then the next tactic. Deviating from this format is the single most common reason people report the model “doesn’t work.”

   from transformers import AutoModelForCausalLM, AutoTokenizer
   
   tok = AutoTokenizer.from_pretrained("./ap2-9b")
   model = AutoModelForCausalLM.from_pretrained(
       "./ap2-9b", device_map="auto", load_in_4bit=True
   )
   
   PROMPT = """[GOAL]
   {state}
   [PROOFSTEP]"""
   
   def next_tactics(state, k=8):
       ids = tok(PROMPT.format(state=state), return_tensors="pt").to(model.device)
       out = model.generate(
           **ids,
           max_new_tokens=128,
           do_sample=True,
           temperature=0.7,
           num_return_sequences=k,
       )
       return [tok.decode(o[ids.input_ids.shape[1]:], skip_special_tokens=True).strip()
               for o in out]
   
   state = "n : \u2115\n\u22a2 n + 0 = n"
   for t in next_tactics(state):
       print(t)

4. Wire it to a real Lean process. Sampling tactics is useless without a kernel to check them. Use repl, the official Lean 4 REPL, which takes JSON commands and returns the resulting proof states — that’s your search environment.

   git clone https://github.com/leanprover-community/repl
   cd repl && lake build
   
   # feed it a theorem and get back the open goals as JSON
   echo '{"cmd": "theorem tst (n : Nat) : n + 0 = n := by sorry"}' | ./.lake/build/bin/repl

   Loop: get state from the REPL, sample k tactics from the model, apply each, keep the states that don’t error, repeat with best-first ordering on cumulative log-probability. That eighty-line loop is the whole system in miniature.

5. Autoformalize before you prove. Feed the informal statement to a general model first and have it emit a Lean proposition with sorry as the body, then hand that to the prover. Constrain the output hard or you’ll get statements that compile but mean something else.

   Translate the statement below into a single Lean 4 theorem using Mathlib.
   
   Rules:
   - Output ONLY Lean code, no prose, no markdown fences.
   - Body must be exactly `:= by sorry`.
   - Prefer Mathlib idioms: Finset.sum, Nat.Prime, \u2211 notation.
   - Do not strengthen or weaken the claim. If the statement is ambiguous,
     choose the reading that makes it harder to prove, and add a `-- NOTE:`
     comment naming the ambiguity.
   
   STATEMENT: {informal_statement}

   Then eyeball the result. Always. An automated theorem proving benchmark 2026 score means nothing if the theorem statement drifted, and this is where drift happens.

6. Put it in CI. Once the loop works, the payoff is making it non-optional. A minimal GitHub Actions step that fails the build on any remaining sorry:

   - name: Verify proofs
     run: |
       lake exe cache get
       lake build 2>&1 | tee build.log
       ! grep -q "declaration uses 'sorry'" build.log

How it compares

System	Weights	Approach	Best reported result	Runs locally
AlphaProof 2 (full)	Closed	Sketch-level search + RL, single policy	5/6 IMO 2026, <60 min per problem	No
AlphaProof 2 prover (9B distilled)	Open	Tactic prediction, distilled from search traces	Low-80s pass@32 on miniF2F	Yes, 24GB card
AlphaProof 1 + AlphaGeometry 2	Closed	AlphaZero search, separate geometry engine	4/6 IMO 2024, days of compute	No
DeepSeek-Prover line	Open	Whole-proof generation + RL on Lean feedback	Competitive on miniF2F, weak above olympiad	Yes
Frontier chat models (informal)	Closed	Natural-language chain of thought	High scores, human-graded, unverifiable	No

The row that matters is the last one. A frontier chat model can produce an olympiad solution that reads beautifully and contains a fatal gap in step seven, and no automated grader will catch it. The distilled prover produces uglier output that a kernel signs off on. For anything you intend to build on, the second is worth more.

What’s next

Combinatorics and problem 4

The obvious near-term watch item is problem 4. Combinatorics has been the persistent weak spot across every formal system, because the natural proof style — case analysis, extremal arguments, constructions with hand-waved verification — maps badly onto Lean’s requirement that every case actually be discharged. DeepMind’s paper is candid that the sketch search generates plausible combinatorial outlines and then fails to close the mechanical parts. Expect the next iteration to attack this with better tooling for finite case explosion rather than a bigger model, and expect Mathlib’s combinatorics coverage to become a rate-limiting dependency people start funding directly.

Whether verification escapes mathematics

Everything in this pipeline — a formal statement, a search over proof steps, a kernel that checks the result — applies unchanged to program verification, and the gap there is tooling, not theory. If someone ships a credible “prove this Rust function satisfies this spec” system built on the same distilled prover, that’s a bigger commercial event than the IMO score. Watch the Verus, Aeneas, and Lean-FFI communities; the first real crossover will show up there.

Contamination and shelf life

IMO 2026 problems are public now, which means every subsequent model trains on them and every subsequent claim about them is worth less. The honest version of this benchmark going forward is held-out formalized problem sets released after training cutoffs, or continuous evaluation against newly-formalized results from live mathematics. If the field takes the lesson as “we need a harder problem set” rather than “we need a verifiable protocol,” it will have learned the wrong thing from a genuinely good result.

Frequently Asked Questions

Does the 5/6 score mean AI has solved competition math?

No. It means one heavily-resourced system, given formalized statements and a fixed compute budget, produced kernel-checked proofs for five specific problems. It does not generalize to research mathematics, where the hard part is deciding what to prove. It also does not mean the distilled open model does this — that model sits at roughly strong-undergraduate level, which is still remarkable and still not olympiad gold.

Is the autoformalization step done by hand?

In the benchmark run, the system formalized statements itself, and the trained discriminator plus human review cross-checked them before the timer started. This is the part of the setup most worth scrutinizing when the full paper details land, because an over-helpful formalization can make a hard problem easy without anyone noticing.

What hardware do I actually need for the open-weights prover?

The 9B model in 4-bit fits comfortably on a 24GB consumer GPU with room for a batch of 8–16 sampled tactics. Full bf16 wants roughly 20GB for weights alone, so 40GB+ if you want headroom. CPU inference works, but the search loop needs dozens of samples per proof state, which makes it impractical.

Can I use this on non-mathematical verification tasks?

Yes, with caveats. The model trains on Mathlib-flavored goals, so it knows Mathlib’s lemma names and idioms. Point it at a proof state full of your own project’s definitions and quality drops sharply. Fine-tuning on your own successful proof traces closes most of that gap — collect them from your search loop as you go.

How does this compare to just asking a frontier chat model?

A frontier model is better at informal reasoning, explanation, and choosing an approach. It is not verifiable. The productive pattern uses both: the chat model for autoformalization and high-level strategy, the prover for closing goals, and the kernel to arbitrate. Treat the chat model’s confidence as a hypothesis and the kernel’s acceptance as the result.

What’s the licensing on the open weights?

Check the model card before you build a product on it — DeepMind’s recent open releases have shipped under custom licenses with use restrictions rather than plain Apache-2.0, and the terms differ between research and commercial deployment. This is a five-minute read that saves a much longer conversation later.