Builds an LLM agent framework that refactors Lean 4 proofs for length, compilation cost, and Lean/Mathlib version compatibility, verified by the Lean compiler.
Abstract
We present Lean Refactor, a plug-and-play retrieval-augmented agentic framework for multi-objective, controllable, and version-robust refactoring of Lean proofs. LLM-generated proofs are notoriously correct-but-verbose and brittle across library versions, yet existing refactoring works overlook three practical challenges: 1) Lean refactoring is natively multi-objective (proof length, compilation cost, and version compatibility are often in tension); 2) Lean repositories have fragile compatibility, whereas LLM releases are unaware of Lean/Mathlib versions; 3) Training-based pipelines require repeated fine-tuning with each new LLM release, scaling neither with model churn nor with Lean's release cycle. Lean Refactor steers a frozen agentic LLM with retrievals from a curated database of multi-objective refactoring strategies, each densely annotated with metadata such as supported Lean/Mathlib versions and expected compilation-cost reduction. Experiments show over $70\%$ token-level compression on competition benchmarks, over $20\%$ on research repositories, and up to $60\%$ compilation-time reduction, outperforming prior work and Claude Code. Version-filtered retrieval further improves compression on the target Lean version, and refactored miniF2F proofs exhibit stronger zero-shot version transfer to future Lean releases than their unrefactored counterparts.
Problem
LLM-generated Lean proofs are often correct but verbose, expensive to compile, and brittle across Lean/Mathlib versions. Existing refactoring approaches optimize a single objective, ignore version drift, and require retraining whenever a new LLM is released.
Approach
Raw long–short proof pairs are distilled into a strategy bank of reusable refactoring strategies. Each strategy is annotated with metadata such as supported Lean/Mathlib versions and expected compilation-cost reduction. A trained retrieval model maps target proofs, grounded with dependency annotations, to relevant strategies, and a multi-objective rerank-and-filter step applies user-specified trade-offs. A training-free planner/refactorer/debugger loop, built on frozen frontier LLMs and with the compiler in the loop, then produces the refactored proofs.
Figure 4 : Overview of Lean Refactor framework. 1. We first summarize raw long-short proof pairs sourced from diverse Lean code sources into well-structured reusable strategies, and more importantly, we annotate each strategy with code refactoring metadata, including compilation time cost and version compatibility (Section 3.1 ). 2. We then train a strategy retrieval model that maps Lean code (thaFigure 5 : Multi-objective Lean proof refactoring. A single strategy bank adapts to diverse user objectives at inference without retraining. Top: for shortest proofs, top- K strategies by cosine similarity are used directly. Middle: to balance faster compilation, candidates are reranked by annotated compile-cost reduction. Bottom: for a target toolchain (e.g., v4.16.0), incompatible strategies are
Results
Token-level compression exceeds 70% on competition benchmarks (miniF2F, PutnamBench, Putnam 2025) and 20% on research repositories (Analysis, FLT, PFR, PhysLean), with up to 60% compilation-time reduction. The method outperforms ProofOptimizer and Claude Code. Version-filtered retrieval improves compression on the target Lean version, and refactored miniF2F proofs transfer better to future Lean releases than unrefactored ones.
(a) miniF2F Improvements(a) Improvements on Analysis Dataset
Method
miniF2F
PutnamBench
Putnam 2025
ProofOptimizer
87.90
57.20
–
Base Agent
79.75
41.15
68.18
Lean Refactor w/o Retrieval
83.44
62.03
75.22
Lean Refactor
88.40
70.38
79.27
Token-level compression (%) on competition benchmarks
Version
Lean Refactor
ProofOptimizer
Original
v4.20.1
194
194
194
v4.22.0
189
188
187
v4.26.0
168
162
141
v4.29.0
166
161
140
miniF2F proofs compiling under later Lean versions