OpenProver: LLM-Driven Theorem Proving
- OpenProver is an open-source system for LLM-driven automated theorem proving with integrated Lean 4 verification, enabling reliable and scalable formal proofs.
- It employs a unique Planner-Worker-Verifier architecture along with a Whiteboard and Repository to manage state and intermediate proof results.
- Evaluation on the ProofNet benchmark shows significant performance gains over linear rollouts, underscoring the advantages of agentic decomposition.
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 (Kripner et al., 10 Jul 2026). 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 (Kripner et al., 10 Jul 2026).
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 (Kripner et al., 10 Jul 2026). 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 (Kripner et al., 10 Jul 2026). 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 (Kripner et al., 10 Jul 2026). 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 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 (Kripner et al., 10 Jul 2026). 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 (Kripner et al., 10 Jul 2026). 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 (Ma et al., 17 May 2026). 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 (Perháč et al., 9 May 2025).
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 (Baeta et al., 2022). 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 (Kripner et al., 10 Jul 2026). 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.