MerLean-Prover: End-to-End Lean 4 Prover

Updated 4 July 2026

MerLean-Prover is an end-to-end Lean 4 theorem prover that transforms 'sorry' placeholders into kernel-checkable proofs using a recursive, plan-centered harness.
It employs three agent types—Planning, Check, and Lean—to iteratively revise proof plans and validate proofs via Lean's build process.
Demonstrating strong performance, it solves 10/23 on FormalQualBench and 12/12 on Putnam2025, outperforming previous open-source baselines.

MerLean-Prover is an end-to-end Lean 4 theorem prover that replaces sorry declarations with kernel-checkable proofs by means of a recursive looping harness whose unit of revision is the proof plan itself. It is built from three agent types—Planning, Check, and Lean—and is notable for achieving strong results without fine-tuning, without a custom RL objective, and without theorem-specific scaffolding. On FormalQualBench, a benchmark of 23 PhD-qualifying-exam theorems, it solves 10/23, surpassing the strongest published open-source baseline, OpenGauss, at 8/23; on Putnam2025, the same harness closes 12/12 with substantially lower total wall-clock than the next-best system that closes the full set (Li et al., 26 May 2026).

1. Definition and task setting

MerLean-Prover addresses a concrete Lean 4 task: given a .lean file containing one or more theorems whose bodies are sorry, it must replace those placeholders with proofs that preserve the original theorem signatures and pass the Lean kernel. A declaration such as

1 2	theorem T : P := by sorry

is therefore treated not as a finished theorem but as an unfinished proof obligation whose body must be rewritten into kernel-validated Lean code (Li et al., 26 May 2026).

The system’s success criterion is stricter than simple compilation. A problem counts as solved only if the produced Lean builds cleanly, preserves the original theorem signature, and passes a transitive #print axioms audit with sorryAx excluded and only {propext, Quot.sound, Classical.choice} permitted. The paper also requires that there be no sorry, admit, or unauthorized axiom anywhere in the transitive proof closure. This places MerLean-Prover squarely in the end-to-end theorem-proving setting rather than in a weaker code-generation or draft-assistance regime (Li et al., 26 May 2026).

A central conceptual choice is that the system does not repeatedly attack the target theorem in isolation. Instead, it externalizes structure into a mutable proof plan. This suggests a shift from proof-script repair to plan repair: when a proof attempt fails, the primary object of revision is not merely the current Lean code but the decomposition of the theorem into helper statements.

2. Plan-centered architecture

The global state of MerLean-Prover is a shared proof plan, conceptually a topologically sorted sequence of statements

$s_1 \to s_2 \to \cdots \to s_N^{\star},$

where $s_N^{\star}$ is the target theorem. Each node stores an informal description, a Lean identifier, dependencies, and a status such as open, in-progress, or formalized. For the target theorem, the plan also stores an anchor: the original Lean declaration with its sorry body, which records the exact signature that must be preserved (Li et al., 26 May 2026).

The agent architecture is divided into three authority domains. The Planning Agent may edit the proof plan but never the Lean source directly. The Lean Agent may edit the Lean code but does not edit the plan. The Check Agent is read-only and answers narrowly scoped yes/no questions. This separation is a design invariant of the harness, and the paper treats it as central to reducing context pressure and constraint pressure in long-horizon proving (Li et al., 26 May 2026).

The Check Agent appears in three variants. The Math check asks whether a statement is mathematically correct as written. The Decomposition check asks whether a statement that appears sound but remains hard should be split into smaller sub-statements. The Faithfulness check asks whether a clean-build Lean file still proves the original anchored statement, rather than a weakened or drifted variant. Any failure from these checks triggers replanning rather than merely another local proof edit (Li et al., 26 May 2026).

This architecture makes the proof plan the sole global object shared across invocations. A plausible implication is that MerLean-Prover treats global theorem-proving constraints as harness logic rather than as prompt burden.

3. Recursive outer loop and Lean interaction

The recursive loop begins by generating or updating a proof plan. The system then traverses statements in dependency order. For each statement $s_i$ , the Lean Agent writes or repairs Lean code for the corresponding theorem or lemma, and the harness runs lake build. If the build succeeds, the Faithfulness check is applied. If it passes, the node is marked formalized and the traversal advances; if it fails, the Planning Agent revises the plan and traversal restarts from the top of the revised plan. If the Lean Agent repeatedly fails to complete a node, the system invokes the Math and Decomposition checks to determine whether the statement is wrong or merely too coarse (Li et al., 26 May 2026).

The recursion is therefore plan-level. A failed node can be replaced by several helper nodes, downstream nodes are invalidated, and the system restarts from the revised topological order. The paper describes the resulting dependency structures as “proof cones”: many small helper lemmas at the bottom feeding a few intermediate lemmas and finally the main theorem (Li et al., 26 May 2026).

Lean is used as the definitive oracle throughout. The harness maintains a Lean project, edits .lean files, and runs lake build after each Lean Agent step. The resulting errors—parser failures, type mismatches, tactic failures, and similar diagnostics—become the immediate feedback loop for the next Lean Agent action. A clean build is still insufficient: faithfulness to the anchor and the transitive axiom audit are checked separately (Li et al., 26 May 2026).

The Burnside example in the paper illustrates the output style of successful nodes. The target theorem is preserved verbatim, while helper lemmas produced by the revised plan provide the missing structure:

/-- Burnside's theorem on transitive permutation groups of prime degree:
a transitive permutation group of prime degree is either 2-transitive,
or it has a normal regular subgroup. -/
theorem MainTheorem {α : Type*} [Fintype α] {G : Subgroup (Equiv.Perm α)}
(htrans : IsPretransitive G α) (hp : (Fintype.card α).Prime) :
IsMultiplyPretransitive G α 2 ∨ ∃ N : Subgroup G, N.Normal ∧
IsPretransitive N α ∧ ∀ a : α, MulAction.stabilizer N a = ⊥ := by
  classical
  rcases Classical.em (IsMultiplyPretransitive G α 2) with h2 | hNot2
  · exact Or.inl h2
  · haveI : IsPretransitive G α := htrans
    exact Or.inr (burnside_dichotomy_core hp hNot2)

A companion helper theorem, burnside_dichotomy_core, is then proved in a separate auxiliary file and imported into the final proof (Li et al., 26 May 2026).

4. Empirical performance and transfer across model sizes

The main evaluation on FormalQualBench uses 23 graduate-level theorems of PhD qualifying-exam difficulty. Under a 4-hour wall-clock budget, MerLean-Prover solves 10/23; 9 of those solves occur within 4 hours, and one additional theorem, Runge’s theorem, is closed in 4h40m. OpenGauss, identified as the strongest prior open-source baseline in the comparison, solves 8/23. Other listed baselines are lower: Aristotle at 6/23, Claude Code (Skills) at 5, Codex at 5, opencode (Opus) at 5, Claude Code at 4, Claude Code (MCP) at 3, and Codex (Skills + MCP) at 3 (Li et al., 26 May 2026).

On the Putnam 2025 slice of PutnamBench, MerLean-Prover solves 12/12. Axiom and Numina-Lean-Agent also close all 12 problems, but MerLean-Prover does so with much lower total wall-clock: 789 minutes versus 2,577 for Axiom and 3,889 for Numina-Lean-Agent. The paper further reports that MerLean-Prover is the fastest system on 8 of the 12 problems (Li et al., 26 May 2026).

The following table summarizes the headline benchmark results.

Benchmark	MerLean-Prover	Comparison
FormalQualBench	10/23	OpenGauss 8/23
Putnam2025	12/12	Axiom 12/12; NLA 12/12
Putnam2025 total wall-clock	789 min	Axiom 2,577; NLA 3,889

The paper also reports a stability study over four FormalQualBench problems across eight runs each. All 32 runs produce clean proofs. For problem ID 1, the reported time is $3.83 \pm 0.39$ hours, with plan size $16.1 \pm 3.4$ statements and $14.9 \pm 3.5$ minutes per statement. This indicates moderate variation rather than brittle one-off success (Li et al., 26 May 2026).

Transfer to smaller models is an explicit part of the evaluation. Using the same harness, Sonnet closes all four tested FormalQualBench problems, and Haiku closes the two short ones. The same architecture and prompts are retained, with only the model changed. This suggests that the harness itself contributes materially to performance, although the paper also notes a model-capability floor: weaker models may require larger plans and longer runtimes (Li et al., 26 May 2026).

5. Position within agentic Lean theorem proving

MerLean-Prover belongs to a broader 2025–2026 line of agentic and verifier-integrated Lean systems, but its design emphasis is distinctive. In contrast to Prover Agent, which coordinates an informal reasoning LLM, a formal prover model, Lean 4, and an autoformalizer while generating auxiliary lemmas, MerLean-Prover uses no fine-tuning and no theorem-specific scaffolding; its central abstraction is a recursive proof-plan harness rather than a specialized prover stack (Baba et al., 24 Jun 2025, Li et al., 26 May 2026).

It also differs from verifier-integrated RL systems such as Leanabell-Prover-V2, which directly optimize multi-turn prover trajectories with Lean 4 feedback, and from retrieval-augmented stepwise provers such as REAL-Prover, which combine a tactic-generating model with premise selection and best-first search. MerLean-Prover instead externalizes decomposition into an editable proof plan and enforces correctness, decomposition, and faithfulness via separate check roles (Ji et al., 11 Jul 2025, Shen et al., 27 May 2025, Li et al., 26 May 2026).

The name also sits alongside MerLean, a distinct paper-scale autoformalization framework for quantum computation. MerLean extracts mathematical statements from LaTeX source files, formalizes them into verified Lean 4 code built on Mathlib, and translates the result back into human-readable LaTeX. Across three theoretical quantum computing papers it produces 2,050 Lean declarations from 114 statements and achieves end-to-end formalization on all three papers. MerLean-Prover, by contrast, is not an autoformalization pipeline but an end-to-end harness for replacing sorry with kernel-checkable proofs in existing Lean 4 developments (Ren et al., 18 Feb 2026).

Within this landscape, MerLean-Prover can be understood as a plan-centered theorem-proving harness. This suggests a complementary relation to data-centric systems such as LeanNavigator, which expand Lean proof corpora by mining state-transition graphs, and to proof-optimization agents such as ImProver, which rewrite existing proofs for criteria like length or readability. A plausible implication is that these systems could supply training data or post-processing layers around a MerLean-Prover-style harness (Yin et al., 16 Feb 2025, Ahuja et al., 2024).

6. Limitations, costs, and outlook

The paper identifies four principal limitations. First, MerLean-Prover depends on a strong base model: Haiku succeeds only on the shorter tested problems, indicating that the recursive harness is not by itself sufficient below a certain capability threshold. Second, the system relies on Mathlib coverage; missing lemmas or awkward library organization can trigger over-decomposition or outright failure. Third, the harness is expensive, because recursive replanning, repeated builds, and repeated reading and rewriting of the proof plan produce high token usage. Fourth, some runs exhibit plan explosion or poor decompositions, yielding unusually large proof plans and long runtimes (Li et al., 26 May 2026).

These limitations interact with one of the system’s central empirical claims: harness design is a central factor in end-to-end Lean 4 theorem proving, alongside raw model capability. The paper’s own interpretation is that a relatively simple harness can already be effective. The experimental evidence for that claim is the combination of 10/23 on FormalQualBench, 12/12 on Putnam2025, and transfer to smaller models without changing the architecture (Li et al., 26 May 2026).

The proposed future directions are correspondingly pragmatic. The authors highlight engineering optimizations such as reducing redundant compile attempts, avoiding excessive rereading of large proof plans, and improving caching. They also suggest pairing the harness with open-source Lean-specific models and using repeated decomposition failures as a signal of missing or poorly documented Mathlib lemmas. This suggests that MerLean-Prover is both a theorem-proving system and a methodology for structuring Lean interaction: the plan, the agent boundaries, and the recursive revision policy are the main intellectual contributions, while the specific backbone model remains swappable (Li et al., 26 May 2026).