---
title: 'OpenProver: LLM-Driven Theorem Proving'
url: https://www.emergentmind.com/topics/openprover
type: topic
---

# OpenProver: LLM-Driven Theorem Proving

Searching arXiv for the primary OpenProver paper and closely related systems to ground the article with current identifiers.
Searching arXiv for "OpenProver Lean 4 agentic interactive theorem proving".
OpenProver is an open-source system for LLM-driven automated theorem proving with integrated Lean 4 formal verification, designed simultaneously for reproducible research and for interactive human-guided proof search [2607.09217]. It uses a Planner-Worker-Verifier architecture inspired by recent ATP agentic systems such as Aletheia, maintains a compact Whiteboard scratchpad together with an unbounded Repository of intermediate findings, and supports both fully autonomous proof search and an interactive terminal interface in which a human operator can monitor and steer the process. Within the system, Lean 4 serves as the formal verifier for both final proofs and intermediate results, so the central output is not merely a natural-language argument but a Lean-checked proof in which `sorry` is replaced by proof terms or tactics.

## 1. Definition and system scope

OpenProver addresses two linked problems. The first is reliability: LLM-generated mathematical proofs in natural language are often brittle and difficult to check rigorously. The second is scalable reasoning: single-pass or linear chain-of-thought ATP is limited by context length and by the absence of structured exploration. OpenProver answers these problems by combining agentic decomposition with Lean 4 verification, so that proof search can branch across parallel Workers while intermediate and final Lean snippets are formally checked [2607.09217].

The system takes as input `THEOREM.MD` and, optionally, `THEOREM.LEAN`; the Lean file may contain theorem statements with `sorry`. Its outputs are `PROOF.MD`, `DISCUSSION.MD`, and optionally `PROOF.LEAN`. At initialization, the Whiteboard `W` is empty, the Repository `R` is empty, and the history `H` is an empty list. The main loop repeatedly executes `PLANNERSTEP(W, R, H)` until the token budget is exhausted or `PROOF.MD` has been produced; it may then continue until `PROOF.LEAN` is produced.

A common misconception is that OpenProver is purely an autonomous prover. In fact, the system is explicitly dual-use: autonomous mode is used for reproducible evaluation, whereas interactive mode makes human intervention a first-class part of the proof-search process. Another misconception is that OpenProver is merely a front-end to Lean. Its design is instead that of an agentic ATP system in which Lean is a verifier and mathematical environment, while planning, decomposition, storage, and interaction are handled by a separate multi-agent scaffold.

## 2. Planner-Worker-Verifier architecture

The core architecture has three agent roles: a single Planner, multiple parallel Workers, and independent Verifiers [2607.09217]. The Planner is the global orchestrator. At each Planner step it receives the current Whiteboard `W`, the Repository summary `R'`, the history `H`, and the theorem statement `T`. It then produces a chain-of-thought reasoning trace, a free-form output, and a list of actions `a1, ..., ak`; those actions are run in parallel, and their outputs are appended to the history.

Workers execute specific mathematical tasks assigned by the Planner. A Worker may be asked to prove a lemma under stated assumptions, explore a special case, search for counterexamples, or formalize a natural-language proof in Lean. Workers do not observe the Planner’s chain-of-thought or other Workers’ outputs; they see only the plaintext task description and any enabled tools. Their outputs can include natural-language reasoning, Lean snippets, or tool calls such as `lean_verify`, `lean_search`, and `lean_store`.

Verifiers check Worker outputs independently and return natural-language feedback indicating whether a proposed lemma or proof seems correct, plausible, or flawed. The separation between Workers and Verifiers is intended to reduce the tendency to follow a flawed line of thought simply because it was already proposed. Verifier feedback is appended to the global history and conditions later Planner decisions.

The Planner’s action vocabulary is fixed and explicit:

| Action | Function |
|---|---|
| `spawn` | Create parallel Workers with assigned tasks |
| `read_items` | Fetch Repository items by slug |
| `write_items` | Create, update, or delete Markdown or Lean items |
| `read_theorem` | Re-read theorem statement |
| `write_whiteboard` | Update the Whiteboard |
| `submit_proof` | Submit an informal proof |
| `submit_lean_proof` | Submit a Lean proof |
| `literature_search` | Search online literature, not available in isolation mode |

This architecture is linear at the level of Planner steps but parallel at the Worker level. A plausible implication is that OpenProver treats long-horizon reasoning as state management rather than as a single long prompt.

## 3. Whiteboard, Repository, and Lean-mediated state

The Whiteboard is a single compact Markdown file that functions as short-term working memory [2607.09217]. The Planner prompt encourages it to contain the current proof plan, a high-level summary of explored and failed attempts, ideas to revisit later, and brief observations. Because the Whiteboard is always fed to the Planner, it is intentionally compact; detailed artifacts are offloaded elsewhere.

That “elsewhere” is the Repository, an unbounded collection of items managed by `write_items` and `read_items`. Each item is either a Markdown file or a Lean file and is referenced by a slug together with a one-line summary. The Repository summary, not the full Repository contents, is shown to the Planner at every step. This provides a long-horizon memory mechanism without requiring the full accumulated material to remain in the prompt.

OpenProver’s Lean interaction is mediated by three tools. `lean_verify` checks Lean snippets, `lean_search` searches Mathlib via LeanExplore, and `lean_store` maintains a cumulative local Lean context consisting of imports, definitions, and lemmas. Only Lean snippets that pass verification are stored as “Lean Items” in the Repository. If verification fails, Lean errors and warnings are fed back into the Planner’s context. This makes Lean 4 part of the inner loop rather than a final post hoc checker.

The Repository therefore contains both informal and formal intermediate objects. Markdown items may store informal proofs, literature summaries, failed attempts, or auxiliary notes, whereas Lean items store verified formal fragments. This suggests a deliberate separation between speculative mathematical exploration and machine-checked accumulation.

## 4. Autonomous and interactive proof search

OpenProver supports two operating modes: autonomous mode and manual mode [2607.09217]. In autonomous mode, Planner actions are executed automatically; this is the mode used in the evaluation experiments. In manual mode, before each set of Planner actions is executed, the human operator can accept or reject the actions and optionally provide textual feedback; the Planner is then re-run with that feedback incorporated into its context.

The interactive terminal user interface exposes streaming outputs of all agents. A human operator can observe the Planner’s reasoning and actions, watch Workers’ ongoing attempts and Lean tool usage, inspect Verifiers’ feedback, and browse previous Planner steps together with their Whiteboard states and action outputs. The operator can also interrupt Workers mid-run or interrupt the Planner to provide guidance such as “Focus more on the case where \(f\) is differentiable” or “Try using integration by parts.”

The proof-generation workflow is correspondingly staged. The Planner typically begins by reading the theorem, writing an initial plan to the Whiteboard, and spawning Workers to attack sub-goals or auxiliary lemmas. Workers may call `lean_verify`, `lean_search`, and `lean_store` while exploring candidate formalizations. Verifiers then assess the outputs, after which the Planner updates the Whiteboard, stores intermediate results in the Repository, and launches further Workers. When an informal proof is sufficiently detailed, the Planner may call `submit_proof` to produce `PROOF.MD`, and then attempt a formalization via `submit_lean_proof` to produce `PROOF.LEAN`.

One limitation is stated explicitly by the authors: formalization is often more challenging than the informal proof search. This means that OpenProver’s difficulty is not exhausted by discovering a convincing argument; converting that argument into Lean syntax and Mathlib-compatible proof structure can itself dominate the workload.

## 5. Evaluation on ProofNet

OpenProver is evaluated on ProofNet, a benchmark for autoformalizing and formally proving undergraduate-level mathematics, using 185 formal theorems in autonomous mode with a token budget of 100k tokens per problem [2607.09217]. The evaluation compares OpenProver against a simple linear rollout baseline in which a single linear conversation is unrolled with the same token budget and the same underlying model, but without the Planner-Worker-Verifier architecture, Whiteboard, or Repository state management.

Two models were tested: Kimi K2.5 and Leanstral. Success is defined as formal proof completion in Lean within the token budget.

| Model | Linear Rollout | OpenProver |
|---|---:|---:|
| Kimi-K2.5 | 36.8% | 57.3% |
| Leanstral | 21.1% | 28.1% |

These results show that, under the reported setup, the system architecture materially affects theorem-proving performance. Because the baseline can still call Lean arbitrarily often, the comparison does not isolate Lean access as the source of the gain. Instead, the gain is associated with agentic decomposition, persistent state via Whiteboard and Repository, and Planner-mediated coordination of parallel Workers.

The paper presents these experiments primarily as a showcase of the quantitative ablation experiments enabled by automatic formal verification. A plausible implication is that OpenProver is intended not only as a prover but also as an experimental platform for studying prompt design, worker allocation, Whiteboard policies, and model choice under a fixed Lean-checked objective.

## 6. Position in the broader landscape, naming, and limitations

OpenProver occupies a specific position within the Lean 4 ecosystem. It is an open-source Planner-Worker-Verifier system with an interactive terminal interface and Lean-checked intermediate artifacts [2607.09217]. This distinguishes it from OProver, which is an open-weight, whole-proof formal theorem prover for Lean 4 trained through continued pretraining and iterative post-training on OProofs and multi-round repair trajectories [2605.17283]. It also distinguishes it from OnlineProver, a web-based educational proof assistant for natural deduction in propositional logic and first-order logic whose primary audience is first-year undergraduates rather than Lean users [2505.05987].

The name also risks confusion with the Open Geometry Prover Community Project, which is an umbrella framework for integrating geometry automated theorem provers under a common API and command-line front end rather than a Lean-based agentic ATP system [2201.01375]. In other words, “OpenProver” in the 2026 Lean 4 sense denotes a specific open-source agentic theorem-proving system, not a generic label for open theorem proving.

Within the broader ATP landscape described in the paper, OpenProver is situated between autonomous mathematical-reasoning systems such as Aletheia and interactive theorem-proving tools such as OpenGauss, but with formal verification via Lean 4 as a central component [2607.09217]. The paper also points toward future directions: stronger RLVR-trained reasoning models, more sophisticated Planner strategies, possible self-improvement through verifiable rewards in the style of Feedback Descent or AlphaEvolve, richer human interaction, extension to other proof assistants, and systematic benchmarking beyond ProofNet.

The system’s principal limitations are also clear. Performance depends on the underlying LLM; token budgets remain finite; very large or deep proofs may exceed practical budgets; and the architecture is currently Lean 4-specific. Most importantly, the authors emphasize that formalization is often harder than informal proof search. That observation places OpenProver squarely in the tradition of formal mathematics systems for which the decisive bottleneck is not merely producing plausible reasoning, but producing reasoning that survives kernel-level verification.

Source: https://www.emergentmind.com/topics/openprover