---
title: Subgoal Cache for Parallel Proof Search
url: https://www.emergentmind.com/topics/subgoal-cache-for-parallel-proof-search
type: topic
---

# Subgoal Cache for Parallel Proof Search

A subgoal cache for parallel proof search is a mechanism that enables efficient reuse of intermediate proof states and subgoal results among multiple branches or agents searching for proofs in parallel. In contemporary automated theorem proving systems built on proof assistants such as Lean 4 and large language model (LLM)-based planners, subgoal caches address the substantial overhead caused by redundant proof state reconstruction and redundant work across concurrent proof search agents. These caches can take the form of proof-state snapshot storage, as in Lean 4’s snapshotting approach [2605.25556], or shared subgoal-to-proof-term hashes in hierarchical multi-agent planners such as BFS-Prover-V2 [2509.06493]. Both approaches enable scalable, parallel, and portfolio-based tactic search by drastically reducing recomputation.

## 1. Motivation and Problem Statement

Parallel proof search, especially in the context of Draft-Sketch-Prove (DSP) pipelines and multi-agent tree search, typically entails significant per-branch overhead. In systems such as Lean 4, each search branch traditionally reconstructs the entire proof state by repetitively re-elaborating the theorem (import loading and theorem-body elaboration). For Lean 4 with Mathlib, this incurs import loading times of approximately 60 seconds per branch and theorem-body elaboration delays of 18–735 seconds per branch, often constituting over 99% of total per-branch wall time [2605.25556]. In planner-based multi-agent provers, the absence of cache mechanisms for subgoal results leads to redundant searches when distinct agents independently attempt to solve identical subgoals [2509.06493]. Thus, the inefficiency stems from a mismatch: proof search branches fork at the logical level but reconstruct the computational state from scratch.

## 2. Data Structures and Algorithms

### Snapshots in Lean 4

Lean 4’s subgoal cache is realized through *proof-state snapshotting*. The server maintains, for each open file, a `FileWorker` which constructs a chain of `Snapshot` objects during elaboration. Each `Snapshot` encodes:
- An immutable Environment containing all loaded constants and type-class instances (~2–4 GB)
- The current `MetavarContext` (mutable, ~KB) tracking open metavariable assignments
- The current `LocalContext` (local hypotheses and bindings) [2605.25556]

Three JSON-RPC primitives support snapshot operations:
1. `$/lean/dspSnapshotPing` checks server snapshot support.
2. `$/lean/dspSnapshotCapture`(uri, position) records a snapshot at a specific source location (typically a sorry-hole).
3. `$/lean/dspSnapshotBranch`(snapshotId, [tactic, ...]) forks the captured state by copying only the lightweight `MetavarContext` and shares the Environment by reference; the requested tactics are run in parallel on the cloned states.

The forking operation cost is $O(|\text{MetavarContext}|)$, avoiding redundant import loading and theorem elaboration per branch.

### Shared Subgoal Cache in BFS-Prover-V2

BFS-Prover-V2’s subgoal cache is a concurrent hash map:
- Key: `SubgoalKey = hash(normalize(q))` where $q$ is a Lean proposition normalized via alpha-renaming and canonical serialization.
- Value: `CacheEntry = { status ∈ {PENDING, PROVING, PROVEN}, proofTree, proofTerm, version }` with fine-grained concurrency control.
- Lookup retrieves proven proof terms if valid for the current planner version; insertion occurs after an agent finds a proof.
- Entries are versioned to handle dynamic planner replanning (invalidating or evicting stale subgoals).

```plaintext
Cache: SubgoalKey ↦ CacheEntry
```
Concurrent access is managed by locking individual buckets or using a lock-free hash map, and atomic compare-and-swap ensures only one agent declares a subgoal as PROVEN. On cache hits, proof terms are type-checked and immediately reused; otherwise, parallel agents race to resolve and populate the cache [2509.06493].

## 3. Theoretical Cost Models and Speedup

### Lean 4’s Snapshotting

Let $H$ = number of sorry holes, $C$ = tactic portfolio size, $n = H \times C$, $T_\mathrm{load}$ = import time, $T_\mathrm{body}$ = theorem-body elaboration time, and $T_\mathrm{tactic}$ = average tactic runtime.

**Naive fallback (no cache):**
$$
T_\mathrm{fallback}(H, C) = n \left(T_\mathrm{load} + T_\mathrm{body}\right)
$$

**Snapshot-based search:**
$$
T_\mathrm{native}(H, C) = T_\mathrm{load} + T_\mathrm{body} + n T_\mathrm{tactic}
$$

**Asymptotic speedup:**
$$
S(n) = \frac{T_\mathrm{fallback}(H, C)}{T_\mathrm{native}(H, C)} \approx \frac{n (T_\mathrm{load} + T_\mathrm{body})}{T_\mathrm{elab}}
$$
where $T_\mathrm{elab} = T_\mathrm{load} + T_\mathrm{body}$ and $T_\mathrm{tactic} \ll T_\mathrm{elab}$. Thus, speedup is roughly linear in the number of branches $n$ until hardware bottlenecks arise [2605.25556].

### BFS-Prover-V2

The cache enables avoidance of repeated search for recurrent subgoals. Empirically, cache hit rates of 40–50% and overall wall-clock speedup of approximately 30–60% are reported, with parallel agents maximizing effective throughput [2509.06493].

## 4. Implementation Strategies

### Lean 4 Snapshotting

Implementation consists of a minimal patch (~<200 LOC) to `Lean.Server.FileWorker`:
- Registers RPC handlers at startup
- The client orchestrator identifies sorry-holes in the proof sketch, captures snapshot IDs, batches tactic trials per hole using `dspSnapshotBranch`, and collects results.

The mechanism is orthogonal to pre-existing import-level caching (as in Kimina Lean Server): import-level caches avoid only import loading per branch, but do not circumvent theorem elaboration overhead [2605.25556].

### BFS-Prover-V2

Each subgoal is registered in the shared subgoal cache with status=PENDING upon planner decomposition. Parallel prover agents consult the cache before commencing search; on misses, they perform best-first search and atomically insert successful proofs. Agents abort duplicate subgoal search upon cache update. Dynamic replanning increments a global cache version, evicting all old entries.

## 5. Empirical Performance and Scaling

### Lean 4 Snapshotting

Benchmarks on 48 miniF2F-v2 problems (MacBook Pro M-series, 8 GB RAM) demonstrate:
- Full DSP pipeline: 5.6–50× wall-time speedup (mean 14×, median 9.7×).
- For H=5 holes (35 branches): 132.8 s native vs 2641.4 s fallback (≈19.9×)
- Per-branch overhead reduction >99.9%; actual tactic execution is negligible compared to startup cost.

**Representative results:**

| Theorem          | Holes $H$ | Native (s) | Fallback (s) | Speedup |
|------------------|-----------|------------|--------------|---------|
| mathd_nt_345     | 5         | 132.8      | 2641.4       | 19.9×   |
| mathd_alg_478    | 4         | 119.9      | 1579.6       | 13.2×   |
| Prove-only $H=5$ | 5         | 141        | 4436         | 29.8×   |

Speedup scales quasi-linearly with number of parallel branches, limited by available CPU and memory [2605.25556].

### BFS-Prover-V2

With subgoal caching and hierarchical planning, BFS-Prover-V2 increases MiniF2F pass rate from 86.1% (monolithic) to 95.1% (with planner + subgoal cache). Anecdotal evidence indicates ≈2× runtime improvement per theorem on ProofNet, with overall cache hit rates of 40–50%. The subgoal cache supports up to 8 concurrent agents efficiently [2509.06493].

## 6. Interactions, Limitations, and Comparison

Subgoal caches are generally orthogonal and complementary to other caching and parallelism layers:
- Lean’s `SavedState` is intra-branch backtracking; snapshotting is for inter-branch forking.
- Parallel compilation and white-box state factorization (e.g., Pantograph, LeanTree) are unrelated to branch-for-branch startup cost.
- For Lean 4, combining both import-level and snapshot caching is projected to yield >100× speedups for large portfolios [2605.25556].

Key limitations include:
- Both mechanisms require patched binaries or orchestrators (Lean’s patched LSP, BFS-Prover-V2’s cache management).
- The caches do not enhance proof accuracy or search quality—acceleration derives solely from elimination of redundant computation.
- Hardware scaling limits for larger agent counts or environments exceeding RAM are unquantified in the present evaluations.

In summary, subgoal caching—either through proof-state snapshots or shared concurrent subgoal caches—transforms the cost structure of parallel proof search by elevating reuse of intermediate states and results. It enables portfolio-based and multi-agent techniques to scale effectively, moving bottlenecks from startup overhead to actual tactic evaluation or proof construction [2605.25556][2509.06493].

Source: https://www.emergentmind.com/topics/subgoal-cache-for-parallel-proof-search