OProver: Lean 4 Agentic Theorem Proving

• OProver is a unified framework for agentic formal theorem proving in Lean 4 that integrates retrieval, compiler feedback, and iterative repair into its proving policy.
• It employs a bounded multi-round refinement process where failed proofs are revised using retrieved validated proofs and raw compiler diagnostics.
• An iterative training pipeline combining continued pretraining, post-training, and reinforcement learning yields state-of-the-art results on benchmarks like MiniF2F and ProverBench.

OProver is a unified framework for agentic formal theorem proving in Lean 4 that trains a prover to use retrieval, compiler feedback, and iterative proof repair as part of the proving policy rather than as inference-time add-ons. It is built around a bounded multi-round refinement process in which failed proof attempts are revised using retrieved compiler-verified proofs and raw Lean compiler diagnostics, and it is trained by continued pretraining followed by iterative post-training that recirculates newly verified proofs and repair traces back into the corpus and retrieval memory. In its reported 32B configuration, OProver attains the best Pass@32 on MiniF2F, ProverBench, and PutnamBench, and second-best results on MathOlympiad and ProofNet, giving it more top placements than any prior open-weight whole-proof prover (Ma et al., 17 May 2026).

1. Definition and problem setting

OProver addresses a specific train–inference mismatch in Lean theorem proving. The paper’s starting point is that many provers are trained primarily on final compiler-verified proofs, while difficult theorem proving in practice involves repeated failure, retrieval of related proofs, inspection of verifier diagnostics, and iterative repair. OProver is designed to internalize that interaction pattern during training, with the stated goal of turning agentic theorem proving into a learned closed-loop policy rather than an inference wrapper (Ma et al., 17 May 2026).

The framework is explicitly formulated for Lean 4 whole-proof generation. Its central claim is not merely that retrieval or feedback help at test time, but that the policy should be trained on the same interaction structure used during rollout collection and inference. This alignment is presented as the main reason OProver improves over earlier open-weight whole-proof provers.

At a high level, the system treats theorem proving as a bounded multi-round refinement process. The interaction begins with an empty previous proof and empty feedback, then iterates until Lean verifies a proof or a fixed round budget is exhausted. This makes failure recovery part of the learned behavior rather than an external control heuristic.

2. Agentic proving as a bounded refinement policy

At round $t$, OProver represents the proving state as

$X_t = (s,\; \mathcal{R}_t,\; p_{t-1},\; f_{t-1}),$

where $s$ is the target theorem, $\mathcal{R}_t$ is the retrieved proof context, $p_{t-1}$ is the previous proof attempt, and $f_{t-1}$ is Lean compiler feedback from that attempt. The policy samples a revised proof according to

$p_t \sim \pi(\cdot \mid X_t).$

A notable design choice is that the policy conditions only on the most recent attempt and feedback, not on the full transcript. The same compact state is used in rollout collection, supervised fine-tuning, and reinforcement learning, so the training interface is identical to inference (Ma et al., 17 May 2026).

Retrieval and compiler feedback are the two external signals. At each round, OProver retrieves the top-$k$ compiler-verified proofs from a memory $\mathcal{M}$ using a semantic similarity model trained on Lean theorem–proof pairs. The retrieved proofs are intended to provide reusable lemma usage patterns, proof skeletons, and local tactics from nearby formal contexts.

If a proof attempt fails, Lean returns raw textual diagnostics, including syntax errors, type mismatches, unknown identifiers, tactic failures, unsolved goals, and timeout-related messages. OProver passes this raw feedback directly into the next state. The framework explicitly avoids compressing the diagnostics into a hand-built taxonomy, on the grounds that local error text often determines the repair.

This formulation makes OProver a verifier-conditioned policy rather than a pure generator. The model is trained not just to emit a final proof, but to revise an already failed proof in response to precise compiler feedback under retrieved formal context.

3. Training pipeline and optimization objectives

The training pipeline has two stages. The first is continued pretraining on a 65B-token mixture intended to adapt the base model to formal reasoning and long-context mathematics. The mixture is described as roughly 30% Lean-related formal data from OProofs, 20% code from OpenCoder, 40% math data from Nemotron-Math-4-Plus, and 10% long-chain-of-thought data from ProLong-64K. The resulting model is called OProver-Base (Ma et al., 17 May 2026).

The second stage, iterative post-training, is the main novelty. In each iteration, the current prover $\pi_k$ runs multi-round agentic proving rollouts on a theorem pool $X_t = (s,\; \mathcal{R}_t,\; p_{t-1},\; f_{t-1}),$0 while retrieving from the current memory $X_t = (s,\; \mathcal{R}_t,\; p_{t-1},\; f_{t-1}),$1 and being checked by Lean. Newly verified theorem–proof pairs are added to the corpus, successful or partially successful rollouts are decomposed into round-level repair examples for supervised fine-tuning, and unresolved hard theorem groups with non-trivial success rate are used for reinforcement learning. The iterative update rule is

$X_t = (s,\; \mathcal{R}_t,\; p_{t-1},\; f_{t-1}),$2

followed by

$X_t = (s,\; \mathcal{R}_t,\; p_{t-1},\; f_{t-1}),$3

and then GSPO on hard cases $X_t = (s,\; \mathcal{R}_t,\; p_{t-1},\; f_{t-1}),$4.

The supervised component uses round-level repair examples of the form

$X_t = (s,\; \mathcal{R}_t,\; p_{t-1},\; f_{t-1}),$5

which are extracted from successful or partially successful repair trajectories. This directly teaches local recovery behavior rather than only final proof completion.

The reinforcement-learning stage uses Group Sequence Policy Optimization with group-relative advantage normalization. For each theorem, $X_t = (s,\; \mathcal{R}_t,\; p_{t-1},\; f_{t-1}),$6 multi-round rollouts are sampled, each with up to $X_t = (s,\; \mathcal{R}_t,\; p_{t-1},\; f_{t-1}),$7 refinement rounds. The round reward is

$X_t = (s,\; \mathcal{R}_t,\; p_{t-1},\; f_{t-1}),$8

All $X_t = (s,\; \mathcal{R}_t,\; p_{t-1},\; f_{t-1}),$9 rounds for the same theorem are pooled into a single group. The paper emphasizes that this allows learning both from comparisons across independent attempts and from comparisons across successive repair rounds within one rollout.

The reported RL hyperparameters are $s$0 rollouts per theorem, maximum refinement rounds $s$1 for OProver-8B and $s$2 for OProver-32B during RL, with Lean verification using explicit proof reconstruction, a 120-second timeout during RL, and a 240-second timeout during evaluation.

4. OProofs as corpus and process supervision substrate

OProofs is the data engine behind OProver. It is a Lean-specific corpus built from public Lean resources, large-scale proof synthesis with Lean verification, and agentic proving traces generated by OProver itself. Its function is twofold: to supply final proof supervision and to preserve the interaction structure required for repair-oriented training (Ma et al., 17 May 2026).

The reported corpus statistics are large. The abstract gives 1.77M Lean statements and 6.86M compiler-verified proofs. The data statistics section gives the more detailed final figures: approximately 1.77M unique Lean statements, 6.86M compiler-verified proofs, 4.33M proofs with retrieval context, 869K with compiler feedback, 1.07M agentic proving trajectories, 164K trajectories with multi-round repair, and 280K round-level repair examples. The frozen Lean corpus snapshot used in current training is 51.8B tokens. The paper also notes that earlier or approximate counts in prose mention about 1.5M statements and 5.0M proofs, whereas the detailed statistics table gives the larger final figures.

The stored trajectories are not limited to theorem–proof pairs. They preserve retrieved references, failed proof attempts, Lean feedback, and repaired next attempts. In the appendix, a repair instance is constructed from a trajectory $s$3 by taking each local transition $s$4 together with its retrieval context $s$5. Filtering removes empty or malformed previous attempts, very long feedback strings dominated by boilerplate, and near-no-op revisions.

OProofs is also characterized by the supervision dimensions it includes. The comparison described in the paper states that prior public Lean resources generally provide only a subset of formal statements, verified proofs, natural-language rationales, compiler feedback, retrieved proofs, and multi-round repair. OProofs is designed to include all six. This suggests that the corpus is intended not merely as a larger repository, but as a training substrate for interaction-aware proving.

A further structural property is the co-evolution of corpus and retrieval memory. Newly verified proofs generated during iterative post-training are indexed into $s$6, so the retriever improves as the prover improves. The paper presents this reciprocal growth as one of the framework’s central ideas.

5. Benchmark results, ablations, and test-time scaling

Evaluation is reported on five standard Lean theorem-proving benchmarks: MiniF2F with 244 problems, MathOlympiadBench with 360, ProofNet with 186, ProverBench with 325, and PutnamBench with 672. Results are reported primarily as Pass@32, where one OProver sample is a complete multi-round rollout and counts as successful if any attempt in the rollout is Lean-verified (Ma et al., 17 May 2026).

Benchmark	OProver-32B Pass@32
MathOlympiad	22.8%
MiniF2F	93.3%
ProofNet	33.2%
ProverBench	58.2%
PutnamBench	11.3%

These numbers place OProver-32B first on MiniF2F, ProverBench, and PutnamBench, and second on MathOlympiad and ProofNet. The paper states that this gives it more top placements than any prior open-weight whole-proof prover. It further reports that the closest dense competitor by size, Goedel-Prover-V2-32B, trails by 6.3 to 11.2 points depending on the benchmark, and that OProver-32B exceeds the 671B DeepSeek-Prover-V2 on all five benchmarks. The comparison with LongCat-Flash-Prover is used to argue that the gains are not a simple scale effect: OProver-32B is a 32B dense model, whereas LongCat-Flash-Prover is a 560B MoE model with about 27B active parameters per token.

The ablations attribute most of the gain to compiler feedback. For OProver-32B, removing multi-turn compiler feedback reduces Pass@32 from 22.8 to 16.5 on MathOlympiad, from 93.3 to 88.4 on MiniF2F, from 33.2 to 25.8 on ProofNet, from 58.2 to 52.0 on ProverBench, and from 11.3 to 7.0 on PutnamBench. Removing retrieval on top of that causes additional but smaller declines, including MathOlympiad from 16.5 to 14.8 and PutnamBench from 7.0 to 5.9. The paper’s interpretation is that compiler feedback is the dominant contributor, while retrieval provides a complementary grounding signal before refinement begins.

The test-time scaling analysis defines

$s$7

where $s$8 is total budget, $s$9 is refinement depth, and $\mathcal{R}_t$0 is the number of samples per round. For OProver-32B, increasing budget from $\mathcal{R}_t$1 to $\mathcal{R}_t$2 raises MiniF2F from 87.5 to 92.8, MathOlympiad from 15.5 to 22.0, ProofNet from 25.6 to 32.8, ProverBench from 51.3 to 56.9, and PutnamBench from 6.4 to 11.3. The gains are described as steady but subject to diminishing returns. The optimal trade-off between deeper refinement and wider sampling depends on the benchmark: deeper refinement helps up to about $\mathcal{R}_t$3 on easier or moderate tasks, while the hardest PutnamBench typically peaks around $\mathcal{R}_t$4, because excessive refinement reduces exploration too aggressively.

The iterative post-training loop is itself evaluated. On MiniF2F-Test, OProver-8B improves from 79.5 after continued pretraining alone to 86.2, 87.0, and 91.8 after three post-training rounds. OProver-32B improves from 84.7 to 88.1 and then 93.3 over two rounds. This demonstrates that recirculating verified proofs and repair traces into OProofs produces measurable gains across iterations.

6. Position in the literature and ambiguity of the name

Within formal theorem proving, OProver is distinguished by the paper as a system that aligns the training state, rollout interface, supervised repair data, reinforcement-learning objective, and retrieval memory in a single co-evolving framework (Ma et al., 17 May 2026). Earlier systems named in the paper, including LeanDojo/ReProver, DeepSeek-Prover-V1.5, Lean-STaR, Seed-Prover, and LongCat-Flash-Prover, are described as exploiting retrieval, search, verifier feedback, or iterative repair in different ways, but often only partially integrating those capabilities into training. OProver’s specific contribution is to make iterative repair itself part of the learned policy.

Several misconceptions are addressed by the reported evidence. One is that the gains are primarily attributable to model scale; the paper argues against this through the dense-versus-MoE comparisons noted above. Another is that retrieval alone explains the improvement; the ablations instead identify multi-turn compiler feedback as the dominant contributor, with retrieval acting as a complementary signal. A further implication of the results is that the system remains far from saturation on the hardest benchmarks: even with Pass@32, PutnamBench remains at 11.3%.

The name “OProver” is also ambiguous across the theorem-proving literature. In "Towards Operation Proof Obligation Generation for VDM" (Battle et al., 15 Jun 2025), the term refers to operation proof-obligation generation machinery for explicit operation bodies in the VDM toolchain, rather than to a Lean 4 theorem prover. In "Open Geometry Prover Community Project" (Baeta et al., 2022), “OProver” appears in the context of the Open Geometry Prover Community Project, an umbrella framework for geometry automated theorem provers rather than a single Lean-based agentic proving model. In current formal theorem-proving usage, however, the unqualified title “OProver” most directly denotes the Lean 4 agentic framework introduced in 2026 (Ma et al., 17 May 2026).