Keep the Proof State Live: Snapshotting for Efficient Tactic Search in Lean 4

Abstract: Automated theorem proving systems built on Lean 4 increasingly rely on parallel tactic search over partially specified proofs, such as those generated by Draft-Sketch-Prove (DSP) pipelines. In current systems, each search branch reconstructs a proof state by re-running elaboration, leading to substantial per-branch overhead. In Lean 4 with Mathlib, this cost has two components: (1) import loading, which deserializes pre-compiled libraries (~60 s per branch); and (2) theorem-body elaboration, which re-checks the theorem context up to the target goal (estimated 18-735 s depending on proof complexity). Together, these account for >99% of per-branch wall time, making portfolio-based search impractical at scale. We observe that this overhead arises from a mismatch between the structure of proof search and its execution model: branching is implemented via repeated reconstruction of proof states rather than direct reuse. To address this, we introduce proof-state snapshotting, which captures the elaborated proof state once and reuses it across branches via a small extension to the Lean 4 language server. Across 48 miniF2F-v2 problems (45 prove-phase benchmarks and 3 full end-to-end runs), our approach achieves a 5.6-50x wall-time speedup over the standard fallback (average 14x, median 9.7x). Speedup increases with the number of proof branches. Our method is orthogonal to import-level caching (e.g., Kimina Lean Server), which avoids import loading but not theorem-body elaboration. The patched Lean binary and the Snapshot-DSP pipeline will be released as open source upon publication.

• The paper demonstrates a snapshotting mechanism that captures and reuses the elaborated proof state, drastically reducing the per-branch overhead from import loading and theorem-body elaboration.
• Experimental results reveal speedups of 5.6× to 50×, with benchmarks showing a 19.9× reduction in runtime over the fallback strategy.
• The technique integrates via Lean 4 LSP extensions into the DSP pipeline, enabling scalable, parallel tactic search on commodity hardware with minimal memory footprint.

Proof-State Snapshotting for Scalable Portfolio-Based Tactic Search in Lean 4

Motivation and Problem Formulation

Automated theorem proving in Lean 4 increasingly leverages portfolio-based tactic search over LLM-generated partial proofs, particularly in Draft–Sketch–Prove (DSP) pipelines. However, each search branch triggers expensive reconstruction of the proof state via import loading and theorem-body re-elaboration. Specifically, import loading of Mathlib incurs ~60 s per branch, while theorem-body elaboration ranges from 18 s to 735 s depending on theorem complexity. Across candidate branches, this yields prohibitive $O(N)$ overhead, dominating wall time and limiting practical parallelism to the number of available workers ($W \ll N$ given RAM constraints). The net effect is that $>$99% of per-branch runtime is spent on elaboration, crippling the scalability of portfolio-based search strategies at DSP scale.

Proof-State Snapshotting: Architectural Advances

The paper introduces proof-state snapshotting, a principled mechanism for capturing the elaborated proof state post-import and theorem-body elaboration, and reusing it across search branches. This is realized via dedicated Lean 4 language server (LSP) extensions—dspSnapshotPing, dspSnapshotCapture, and dspSnapshotBranch—that expose internal snapshot objects (Environment, MetavarContext, and LocalContext) as externally forkable handles.

The critical technical insight is that the Environment (~2–4 GB) is immutable and can be shared by reference between branches, while MetavarContext (~KB per branch) is the only mutable component and is efficiently copied. Therefore, the branching overhead is negligible: RAM ceases to be a bottleneck, allowing all $N$ branches to run in parallel regardless of $N$, with minimal memory footprint. Tactic execution itself is lightweight (typically a few ms to 500 ms; 95th percentile 289 ms), further confirming that startup cost was formerly dominated by elaboration.

Figure 1: Architectural comparison—(a) fallback strategy with per-branch reloading and elaboration, (b) snapshot-based approach enabling parallel branch dispatch from a single elaborated proof state.

Experimental Results

Snapshotting achieves substantial acceleration—5.6–50$\times$ wall-time speedup (average 14$\times$, median 9.7$\times$)—across 48 miniF2F-v2 problems, with speedup scaling monotonically with branch count and sorry-hole count. Wall-time breakdown reveals that more than 99% of legacy per-branch cost is attributed to import and elaboration overhead, entirely eliminated by proof-state snapshotting. Import-level caching techniques such as Kimina Lean Server (Santos et al., 29 Apr 2025) mitigate import, but not theorem-body elaboration, yielding only modest speedup ($\sim$1.1–5$\times$). The snapshot solution is orthogonal and complementary, unlocking deeper scaling by eradicating both major sources of overhead.

A representative benchmark shows that a five-hole theorem, with a portfolio of seven tactics (35 branches), takes approximately 132.8 s using snapshots, compared to 2,641.4 s using the fallback, a 19.9$W \ll N$0 reduction. The advantage widens with problem complexity and branch multiplicity, reaching projected speedups greater than 100$W \ll N$1 in persistent-server batch settings.

Implementation, Reuse, and Integration

Snapshot primitives are implemented as LSP extensions registered at server boot, integrated seamlessly with the DSP pipeline orchestrated via Python. When the orchestrator detects snapshot support, it proceeds to capture and reuse proof state for parallel tactic execution; otherwise, it falls back to legacy lake build (full rebuild per branch). The system requires only a patched Lean binary, distributed via elan, and does not modify user-facing Lean code or tactic specifications.

The method is agnostic to the specific tactic portfolio and compatible with standard tactics (e.g., aesop, norm_num, ring, linarith, omega, simp, decide), easily extendable to alternative or custom tactics.

Comparison with Related Approaches

• Import-Level Caching (Kimina): Kimina caches after import, sharing Environment between theorems but not between branches. It achieves a maximum 1.94$W \ll N$2 speedup (Santos et al., 29 Apr 2025), whereas snapshotting eliminates both import and elaboration, offering 5.6–50$W \ll N$3 speedup.
• Large-Scale Parallel Search (Aristotle, Pantograph): Systems such as Aristotle (Achim et al., 1 Oct 2025) rely on compressed state serialization and stateless backends, but do not exploit elaboration-level snapshotting. Pantograph (Aniva et al., 2024) exposes proof state as structured data but dispatches tactics sequentially.
• Intra-Branch Backtracking (Aesop, SavedState): Aesop [3573105.3575671] leverages SavedState for intra-branch backtracking; snapshotting is complementary, facilitating inter-branch parallel fork-and-check.

Practical and Theoretical Implications

Proof-state snapshotting addresses a critical scalability barrier in LLM-guided Lean 4 theorem proving. It transforms parallel tactic search from an $W \ll N$4 to an $W \ll N$5 operation with respect to elaboration, enabling practical deployment of DSP-scale pipelines (hundreds of branches per theorem) on commodity hardware. The approach is general, requiring only minimal server patches, and can be adopted in formal mathematics, verification, and AI-driven proof search systems.

Snapshotting is a clear demonstration of how exposing internal proof state as a first-class, forkable entity fundamentally reshapes the interface between theorem prover internals and AI orchestrators. It defies traditional architecture assumptions (e.g., human-in-the-loop editing) and opens the door for persistent-server, batch-mode operation, further synergizing with import-level caching to maximize throughput.

The mechanism motivates future developments—native upstream support in Lean, persistent-server variants combining Level 1+2 optimizations, adaptive tactic portfolios, distributed orchestration, and deeper state-aware LLM guidance. It also raises foundational questions regarding proof assistant design: should branching, parallelism, and state reuse be first-class primitives for AI-guided proof search?

Limitations and Future Work

The acceleration is purely infrastructural; it does not advance proof discovery or sketch quality. It is contingent on a patched Lean binary, and currently restarts the LSP server per theorem (not yet amortizing import loading across batches). Results are measured on MacOS/Apple M-series hardware; scaling on heterogeneous clusters and deeper miniF2F/IMO-level benchmarks is yet to be established.

Persistent-server variants and native integration with import-level caching (e.g., Kimina) are promising avenues. Further interface generalization, upstreaming, and hardware characterization will be needed to realize the full potential.

Conclusion

Proof-state snapshotting is a systematic solution to a dominant bottleneck in Lean 4 DSP-style tactic search, offering order-of-magnitude speedups with minimal architectural intrusion. By exposing elaboration-level snapshots as forkable handles via server-side extension, it eliminates the per-branch overhead previously required for parallel search. The approach is broadly compatible, practically adoptable, and generalizable, setting a precedent for AI-oriented interfaces in formal theorem proving. The implications for scaling and integration with persistent-server and multi-theorem batch modes are substantial, promising further acceleration and enabling large-scale AI-guided proof search architectures.