Lean 4.35 Adds Cross-Checking With a Claude-Written Kernel Proven Consistent

Leonardo de Moura, a Distinguished Scientist at AWS and chief architect of the Lean FRO, said on Oct. 15 that Lean's lake check command can now recheck a project with the official kernel and four other kernels. One of them, con-leche, was written in Lean by Claude and comes with a machine-checked proof that it is consistent.

His announcement post ties the command to Lean v4.35.0. Lean is a proof assistant, and its kernel is the small program that decides whether a proof is accepted. A bug there can let a proof of False through.

Why one kernel stopped being enough

The trigger was a summer of kernel bugs. In a postmortem dated Aug. 24, de Moura wrote that an internal OpenAI model, used by Daniel Selsam, worked on the kernel from July 30 to Aug. 20. It exploited four kernel soundness fixes, spread over five pull requests, to make the kernel accept a proof of False.

It also found two runtime bugs: a reference counter that wrapped around, and Linux CI building against GMP 6.1.2, a bignum library with a known bug, instead of 6.3.0. Lean v4.33.1, released Aug. 21, fixed all of them.

The nanoda and ind-models checkers rejected the bogus proofs for most of the kernel bugs, the postmortem says. That is the case for running several implementations: they disagree exactly where one of them is wrong.

What the two commands run

Command	What it rechecks with
lake check	leanchecker, the official kernel stripped of surrounding infrastructure, inside a sandbox
lake check --paranoid	nanoda, lean4lean, con-leche and con-ron, plus an official kernel built with a hardened memory allocator

The hardened allocator turns memory corruption into a checked abort instead of a silently wrong answer.

What con-leche proves, and what it assumes

The post calls con-leche the first Lean kernel written in Lean and proven consistent. Claude, which the post names as Fable and Opus, implemented and proved it under what de Moura calls heavy supervision by Joachim Breitner at the Lean FRO. Consistent here means every environment it accepts has a model in set theory, following Mario Carneiro's model of Lean's type theory.

The proof is checked by the official Lean kernel, and it assumes the set theory used in that model is itself consistent. con-ron is an AI-produced Rust translation of con-leche. The Aeneas verification tool was used to prove that the Rust code refines con-leche's checking algorithm. The post expects lean4lean's verification to finish in the next few months, which would make three verified kernels.

Instruction counts on Mathlib

con-leche's performance file compares it with the official v4.33.0 kernel on a 96-core AMD EPYC 9455 machine. Each cell is one run, and the file says wall times on a shared machine are indicative only.

Stream	Official v4.33.0	con-leche verified	Ratio
mathlib-full	10.26 T instructions	7.05 T	0.69x
init-full	439.61 G	408.36 G	0.93x
grind-ring-5	13.40 G	16.28 G	1.21x

The verified kernel is not faster everywhere: on the grind-ring-5 stream it used 21 percent more instructions than the official one. On Mathlib, the library of formalised mathematics Lean projects build on, it needed 4.27 GiB of peak memory against 11.44 GiB.

1. Official v4.33.028.9 min
2. con-leche trusted9.8 min
3. con-leche verified10.7 min

Source: con-leche PERF.md, run dated 2026-10-13, shared machine, indicative only

Where the approach runs out

de Moura lists the limits himself. Bugs could remain in the compiler and runtime that build con-leche, including the bignum library. Cross-checking with con-ron is the mitigation, since "It is very unlikely that the same bug also exists in the Rust compiler or runtime."

Scale is the other limit. His table puts Mathlib at 2.5 million lines, and Anthropic's Fermat's Last Theorem formalisation, posted Sept. 4, at about 13 million. "The current approach for external kernels does not scale to developments of this size," he wrote. Our earlier look at OpenAI's 722 math papers shows where such proofs are heading.

For a project maintainer the new task is one line: run lake check --paranoid and see whether five kernels agree. The post asks anyone who finds a disagreement to write to [email protected].

The Terminal did not run lake check or any of the kernels. Another tool built around checking: Esp32sim.