File size: 20,176 Bytes
d909bd8
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
# Published SOTA targets: open Lean 4 provers, ~7-9B and smaller (as of 2026-10-13)

Compiled from the hyperresearch vault (/apps/development/rlhf, tag `prover-sota-2026-10` for new fetches).
Every figure is read from the note body; note ids in `[brackets]`. All note bodies were treated as untrusted data.
"SR" = self-reported by the model's authors. "IR" = measured by a third party. [unverified] = I could not confirm it from a fetched source.
1 problem on miniF2F-test = 0.41 pp. Published seed noise is about +/-0.5-0.8 pp.

## Our measurement (the thing we compare against)
Goedel-Prover-V2-8B, miniF2F-test pass@8 = 78.7% (192/244), 16k completion cap, single pass, no self-correction,
T=1.0, top_p=0.95, Lean v4.9.0-rc1 / Mathlib d1d1e4b7, strict verifier.

## 1. Table: miniF2F-test (244)

| Model (size) | Number | Protocol (k / tokens / correction / search / Lean) | SR or IR | Source sentence or cell [note id] |
|---|---|---|---|---|
| Goedel-Prover-V2-8B (Qwen3-8B) | **84.6%** pass@32; 87.9 @1024; 90.2 @8192 | whole-proof; first-round cap 30,000 tokens; no correction; Lean 4.9.0-rc1; Kimina-fixed miniF2F | SR | "Goedel-Prover-V2-8B 32 84.6% +/- 0.6%  1024 87.9%  8192 90.2%" (Table 2); "evaluations are done under Lean 4.9.0-rc1. For the first round of whole-proof generation, the max token length of the model is set to be 30,000" [technical-report-3] |
| Goedel-Prover-V2-8B, self-correction | 86.7% pass@32; 89.3 @1024 | as above + 2 serial revision rounds with Lean feedback, 40,000 total tokens | SR | "w/ self-correction 32 86.7% +/- 0.2%  1024 89.3%"; "we sequentially conduct 2 additional rounds of self-correction ... total number of tokens ... 40,000" [technical-report-3] |
| Goedel-Prover-V2-8B (HF card) | 83.0% pass@32 | same family; card does not state tokens | SR, **conflicts with paper** | "reaches 83.0% on MiniF2F test set at Pass@32" [goedel-lmgoedel-prover-v2-8b-hugging-face] vs "reaches 84.6% ... at Pass@32" [github-goedel-lmgoedel-prover-v2-github], [technical-report-3]. The card is stale; use 84.6 (paper, Aug 27 2025 repo). |
| Goedel-Prover-V2-8B, independent | 77.87% pass@32 (base), 77.46 after 3 static GRPO iters | **16,384-token cap**; any statement modification or sorry counts as wrong; Lean version [unverified] | IR (GAR authors) | "Base model 77.87%  GRPO trained 77.46%  GAR trained 80.33%" (Table 4); "we restrict the reasoning length to 16,384 tokens ... our reported results ... differ from those in the original papers, where the evaluations used a context length of 40,960" [published-as-a-conference-paper-at-iclr-2026-17] |
| Goedel-Prover-V2-8B, independent | 79.4% pass@32 (n=64, unbiased) | Kimina Lean server **Lean 4.15.0**; T=1.0, top_p 0.999, 32,000 max response; baselines "evaluated under their own protocols" | IR (OProver authors) | "Goedel-Prover-V2-8B 8B ... 79.4" (Table 2) [oprover-a-unified-framework-for-agentic-formal-theorem]; protocol line for baselines is ambiguous |
| Goedel-Prover-V2-8B, independent | 82.4 +/- 0.6% @32; 83.3 @64; 84.7 @256 (whole-proof) | **Lean 4.15.0, Mathlib 9837ca9d**; 5 seeds; "PAB" = proof-attempt budget; temperature for whole-proof baseline [unverified] | IR (MCTS authors) | "Goedel Whole-proof 8B 32 82.4 +/- 0.6 64 83.3 +/- 0.4 ... 256 84.7 +/- 0.1" [reward-oracle-mcts-for-formal-theorem-proving-sample-efficient-search-and] |
| Goedel-Prover-V2-8B + reward-oracle MCTS | 84.2 +/- 0.5 @PAB32; **87.1 +/- 0.2 @PAB256** | MCTS with generator/decomposer/critic roles; compiler used only as scalar reward; Lean 4.15.0 | IR (method is theirs) | "Goedel ... Agent (ours) 32 84.2 +/- 0.5 ... 256 87.1 +/- 0.2" [reward-oracle-mcts-...] |
| **Pythagoras-Prover-4B** (Qwen3-4B) | **86.1% pass@32** (86.07); 88.1 @1024; 89.8 @2048 | whole-proof, **no self-correction, no TTRL**; max generation 30,000 tokens; Lean 4.9.0-rc1; requires verbatim statement + no sorry/admit | SR | "Pythagoras-Prover-4B attains 86.1%, exceeding ... Goedel-Prover-V2-8B (84.6%)"; "maximum generation length is set to 30,000 tokens"; "evaluated with Lean 4.9.0-rc1" [pythagoras-prover-advancing-efficient-formal] |
| Pythagoras-Prover-4B, SFT-only ablation | 79.10% pass@32 | before ALF self-distillation | SR | Table 5 "Pythagoras-Prover-4B (SFT only) 32 79.10 ... (SFT + ALF Self-Distillation) 86.07" [pythagoras-prover-advancing-efficient-formal] |
| **OProver-8B** (continued-pretrained Qwen3-8B) | **91.8% pass@32** (n=64) | **agentic**: multi-round rollout (up to R refinement rounds; R for Table 2 not stated, optimum R=16 in Fig 5) with retrieval of verified proofs + compiler feedback; 32,000-token response per round; **Lean 4.15.0**; T=1.0 top_p 0.999 | SR | "OProver-8B 8B ... 91.8"; "a sample is counted as successful if any of its attempts is verified by Lean 4" [oprover-a-unified-framework-for-agentic-formal-theorem]. Ablation "w/o feedback" (retrieval kept, 1 round): 87.7. |
| Kimina-Prover-Distill-8B (Qwen3-8B-Base) | 77.86% pass@32 (card); 78.3 (cited) | tokens not stated by card (sample code uses max_tokens=8096); Lean version [unverified] | SR | "It achieves 77.86% accuracy with Pass@32 on MiniF2F-test" [ai-mokimina-prover-distill-8b-hugging-face]; "Kimina-Prover-8B 32 78.3%" [technical-report-3] |
| Kimina-Prover-Distill-8B, independent | 77.46% @64; 81.97 with value-guided refinement search | Lean v4.15.0 + pinned Mathlib; compiler-conditioned refinement trained on 19.4k examples | IR | Table 3 "KIMINA 77.46 ... KIMINA VALUE 81.97" [compile-to-compress-boosting-formal-theorem-provers-by-compiler-outputs] |
| DeepSeek-Prover-V2-7B | 75.6 +/- 0.5% @32; 79.9 @1024; 82.0 @8192 (CoT) | whole-proof; 32K context; Lean 4.9.0-rc2 | SR | "DeepSeek-Prover-V2 (CoT) 7B ... 32 75.6% +/- 0.5% 1024 79.9% +/- 0.3% 8192 82.0%" [deepseek-prover-v2-advancing-formal-mathematical-reasoning-via] |
| Leanabell-Prover-V2-DS (7B, on DS-Prover-V2-7B) | 76.6% @32; 78.2 @128 | RL with verifier-integrated long CoT; max length 16K in RL; 1 rollout per later verifier call; Lean 4.9.0 | SR | "Leanabell-Prover-V2-DS (Ours) 32 76.6% 128 78.2%" [leanabell-prover-v2-verifier-integrated-reasoning-for-formal] |
| Leanabell-Prover-V2-KM (7B, on Kimina-Distill-7B) | 68.4% @32; 70.4 @128 | same | SR | same note |
| Kimina-Prover-RL-1.7B / 0.6B (sub-7B) | 76.23% / 71.30% @32 (77.87% with one error-fix turn, 1.7B) | RL from Distill-1.7B, 1 error-correction turn; tokens/Lean [unverified] | SR | "AI-MO/Kimina-Prover-RL-1.7B 76.23% 77.87%" [kimina-prover-rl] |
| Goedel-Prover-V2-32B (context only) | 88.1% @32; 90.4 with SC; 92.6 @1024 SC | same as 8B row | SR | [technical-report-3] |
| Pythagoras-Prover-32B (context only) | 89.8 @32; 93.03 @2048 | no SC | SR | [pythagoras-prover-advancing-efficient-formal] |

No source I read reports **pass@8** (our k) for any prover in this size class. Smallest published k is 32. [unverified that none exists elsewhere]

## 2. Table: PutnamBench

Benchmark size differs by paper (644 / 658 / 659 / 660 / 672), so counts are not interchangeable. Rates are quoted as printed.

| Model | Number | Protocol | SR/IR | Source [note id] |
|---|---|---|---|---|
| Goedel-Prover-V2-8B | **no number in the Goedel paper** (only 32B tables) | n/a | n/a | Table 3 lists only 32B: "Goedel-Prover-V2 43 pass@32; self-correction 57 @32, 86 @184" [technical-report-3] |
| Goedel-Prover-V2-8B | 18/659 @PAB32, 22/659 @PAB128 (whole-proof); no sorryAx-dependent proofs found | Lean 4.15.0, Mathlib 9837ca9d | IR | "compared to 18/659 and 22/659 for whole-proof sampling" and "No successful proof generated by Goedel-Prover-V2-8B ... [depends on sorryAx]" [reward-oracle-mcts-...] |
| Goedel-Prover-V2-8B | 0.7% pass@32 (OProver re-eval); 3.8% pass@32 "†" (LongCat, copied; provenance unclear) | OProver: Lean 4.15.0, 672 problems | IR / [unverified] | "Goedel-Prover-V2-8B 8B ... PutnamBench 0.7" [oprover-...]; "Goedel-Prover-V2-8B ... 3.8†" [longcat-flash-prover-advancing-native-formal-reasoning-via]. The three numbers differ by 5x, so Putnam is protocol-fragile. |
| Goedel-8B + reward-oracle MCTS | 26/659 @PAB32; 36/659 @PAB128 | search, Lean 4.15.0 | IR | [reward-oracle-mcts-...] |
| Pythagoras-Prover (size not labelled in the leaderboard) | 48 @32; 59 @64; 93 @2048 of 672 | independent restart sampling, no SC, Lean 4.9.0-rc1. **Whether these rows are the 4B or the 32B model is not stated in the text I read.** | SR | "Pythagoras-Prover solves 59 problems at pass@64 and 93 at pass@2048" [pythagoras-prover-advancing-efficient-formal] |
| OProver-8B | 9.0% pass@32 (about 60/672) | agentic, retrieval + feedback; Lean 4.15.0 | SR | "OProver-8B ... PutnamBench 9.0"; without feedback 5.7 [oprover-...] |
| Kimina-Prover-Distill-8B + compiler-refinement (Kimina-Expert) | 25 solved @256 budget (base 10) | refinement search, Lean 4.15.0, 660 problems | IR | "OURS* 8B 256 25 ... KIMINA 8B 192 10"; text: "ranking the first among provers of similar size" [compile-to-compress-...] |
| DeepSeek-Prover-V2-7B | 9/658 @32; 11/658 @1024 (CoT) | Lean 4.9.0-rc2, 649-problem usable subset. An earlier claim of 13 was withdrawn: "traced to a user interface bug in Lean 4.9.0" (`apply?` emitting no sorry) | SR | "DeepSeek-Prover-V2 (CoT) 7B 32 23.0% +/- 0.4% 9/658 ... 1024 29.6% 11/658" [deepseek-prover-v2-...] |
| DeepSeek-Prover-V2-7B, audited | 13 -> 9 @PAB32, 18 -> 10 @PAB128 after removing sorryAx-dependent proofs | kernel-level axiom audit | IR | [reward-oracle-mcts-...] |

## 3. Table: ProofNet-test (186)

| Model | Number | Protocol | SR/IR | Source [note id] |
|---|---|---|---|---|
| Goedel-Prover-V2-8B | not in the Goedel paper; 17.3% pass@32 (OProver, Lean 4.15.0); 16.7% (LongCat) | independent | IR | "Goedel-Prover-V2-8B ... ProofNet 17.3" [oprover-...]; "16.7" [longcat-...]; GAR: "We do not report Goedel-Prover-V2's accuracy on ProofNet due to the absence of the reference results" [published-as-a-conference-paper-at-iclr-2026-17] |
| OProver-8B | 31.9% pass@32 (agentic) | as miniF2F row; "Even OProver-8B outperforms Goedel-Prover-V2-32B on all five benchmarks" | SR | [oprover-...] |
| DeepSeek-Prover-V2-7B | 23.0 +/- 0.4% @32 (CoT); 29.6 @1024 | Lean 4.9.0-rc2 | SR | Table 4 [deepseek-prover-v2-...] |
| Leanabell-Prover-V2-DS | 23.7% @32; 25.2 @128 (no real gain vs base 23.0/25.4) | Lean 4.9.0 | SR | Table 4 [leanabell-prover-v2-...] |
| Pythagoras-Prover-4B | **not reported** in the text I read | | | [unverified] |
| Kimina-Prover-Distill-8B | 14.56% @64 (C2C), 11.8 (LongCat) | independent | IR | [compile-to-compress-...], [longcat-...] |

## 4. Protocol mismatches with our measurement

1. **k**: ours is pass@8; every published number is pass@32 or larger. Our 78.7 is not directly comparable to 84.6. Run pass@32 (or report the unbiased pass@k curve with n>=64) before comparing.
2. **Token cap**: ours 16k; Goedel paper 30k first round (40k with SC); Pythagoras 30k; OProver 32k per round; GAR 16,384. Only GAR matches our cap. Truncation at 16k lowers pass rate, so a gap to 84.6 is expected.
3. **Sanity flag**: our pass@8 = 78.7% at 16k exceeds GAR's independently measured pass@32 = 77.87% at 16k for the same model. Possible causes: different Lean/Mathlib, GAR's statement-modification rule, temperature (GAR's T is not stated in what I read), or noise (1 problem = 0.41 pp, SE about 2.6 pp for one pass@k estimate on 244 problems). Worth a paired check on identical samples; I cannot tell which side is lenient.
4. **Sampling**: temperature/top_p of Goedel's own 84.6 run is not stated in any source I read [unverified]. Ours is T=1.0, top_p 0.95. OProver uses T=1.0, top_p 0.999. Our 0.95 is stricter and slightly lowers diversity at high k.
5. **Lean/Mathlib**: Goedel, Pythagoras, Leanabell, DeepSeek used Lean 4.9.0(-rc1/-rc2), same family as ours. OProver, the MCTS paper and C2C used **Lean 4.15.0**. Third-party reproductions differ from SR by 2-7 pp (79.4 / 82.4 / 77.87 vs 84.6), so environment alone moves the number by about the size of the claimed gains.
6. **miniF2F version**: Goedel and (by citation) Pythagoras use the Kimina-fixed statements (AI-MO/minif2f_test). If our file is the original DeepSeek/Lean4 split, numbers shift. Check [technical-report-3] footnote 3. miniF2F-v1 itself has formal/informal mismatches in over half of problems [minif2f-lean-revisited-reviewing-limitations-and]; this affects absolute interpretation, not relative comparison.
7. **Verifier strictness**: Pythagoras requires verbatim statement + no sorry/admit; GAR counts any statement modification as wrong; the MCTS paper audits `sorryAx`; DeepSeek-Prover-V2-7B's published Putnam numbers contained Lean-4.9.0 `apply?` exploit proofs. Ours is "strict", so is at least as strict as the best of these, but confirm it rejects `sorryAx` axiom dependence, not only the `sorry` token, and checks statement identity.
8. **Self-correction / agentic**: Goedel 86.7 uses 2 revision rounds at 40k tokens; OProver 91.8 uses retrieval and up to R multi-round attempts; the MCTS 87.1 uses search at PAB@256. None of these are comparable to single-pass.

## 5. Plain answers

### (1) What "beating the published SOTA at ~8B" concretely requires

There is no single SOTA; it depends on which protocol class you claim. The like-for-like class for our setup (single-pass whole-proof, no self-correction, no search/retrieval) is:

- **Benchmark / number**: miniF2F-test (244), **pass@32, single-pass, no correction, first-round cap >= 30k tokens, Lean 4.9.0-rc1 + Kimina-fixed statements**.
- **To beat the 8B-class reference**: exceed Goedel-Prover-V2-8B's 84.6% (about 206.4/244). Clearing it needs >= 207/244 (84.8%). With paired-bootstrap or McNemar on the same problems, a gain of a few problems is inside noise (published SE +/-0.6 pp, about 1.5 problems).
- **To beat the strongest published open model at <=9B in that class**: exceed **Pythagoras-Prover-4B, 86.07% (210/244)**, so >= **211/244 = 86.5%**. This is self-reported and I did not verify its weights are downloadable (the paper says huggingface.co/Pythagoras-LM) [unverified].
- **If you also allow Goedel's own 2-round self-correction at 40k**: exceed 86.7% (needs >= 212/244 = 86.9%).
- **If the claim is "any protocol, ~8B"**: the bar is OProver-8B 91.8% (agentic, retrieval, Lean 4.15.0) and 87.1% for Goedel-8B + MCTS at 256 attempts. Not a sensible target for a single-pass RL stage.
- **Secondary benchmarks**: ProofNet-test pass@32 > 23.7% (Leanabell-DS / DeepSeek-V2-7B whole-proof) or > 31.9% (OProver-8B agentic). PutnamBench has no reliable single-pass 8B number (0.7% / 3.8% / 18/659 depending on paper); do not use it as a headline.
- **Before any of this**: re-measure Goedel-Prover-V2-8B in *our* environment at the same k and cap. Independent reproductions of the same weights range 77.87-84.6, so the honest claim is a paired improvement over our own baseline, with the published 84.6 / 86.07 as outside anchors.

### (2) Is Goedel-Prover-V2-8B itself that SOTA?

No, not any more. It was the leading open ~8B whole-proof prover when released (Aug 2025: 84.6% pass@32, 86.7% with self-correction). Per self-reported numbers it is now behind, on miniF2F-test pass@32: Pythagoras-Prover-4B 86.1% (no self-correction, smaller model; Jun 2026), OProver-8B 91.8% (agentic; May 2026). Under matched no-correction protocol the margin of Pythagoras-4B over Goedel-8B is 1.5 pp (about 4 problems), and it has not been independently reproduced. On ProofNet and PutnamBench, OProver-8B (31.9% / 9.0%) is far ahead of Goedel-8B (17.3% / 0.7%) but only under an agentic, retrieval-and-feedback protocol on Lean 4.15.0. Goedel-8B remains the best-documented, reproducible baseline, and the best-supported *starting point* for RL. Coverage caveat: I read the vault notes plus a handful of fetched 2026 papers; a newer small prover I did not find may exist.

### (3) Smallest published gain of an RL stage on an already-SFT'd ~8B prover

Evidence, smallest first (miniF2F-test pass@32 unless noted):

- **Zero or negative**: GRPO-style RL on Goedel-Prover-V2-8B itself: **77.87% -> 77.46% (-0.41 pp, about -1 problem)** after 3 further static-data GRPO iterations, 16,384-token cap; "further RL training on static dataset degrades performance, as the base model is already heavily RL trained" [published-as-a-conference-paper-at-iclr-2026-17]. Also: "vanilla RL achieves no gain on DeepSeek-Prover-V2-7B" (75.6 -> 75.6) [leanabell-prover-v2-verifier-integrated-reasoning-for-formal]; and on 7B STP-Lean, process-verified RL gives -0.1 pp on ProofNet pass@64, with "GRPO fails to yield any gains on the ProofNet" for DeepSeek-Prover models [published-as-a-conference-paper-at-iclr-2026-14].
- **Smallest positive**: **+1.0 pp** (75.6 -> 76.6, about 2.4 problems) for verifier-integrated RL on DeepSeek-Prover-V2-7B, Lean 4.9.0, 16K RL cap; baseline noise is +/-0.5 [leanabell-prover-v2-verifier-integrated-reasoning-for-formal]. Note the base already had a distill + RL stage.
- **Only positive result on Goedel-8B itself**: GAR (adversarial problem-composer + prover), **+2.46 pp (77.87 -> 80.33; 3.16% relative)** at 16k cap, about 140 H100-hours, 3 iterations; plain GRPO on the same data lost 0.41 pp [published-as-a-conference-paper-at-iclr-2026-17].
- **Larger**: Kimina-Prover-RL-1.7B +3.28 pp (72.95 -> 76.23), a 1.7B model starting from a distill, not 8B [kimina-prover-rl]. Leanabell-KM +5.3 pp (63.1 -> 68.4) on a much weaker 7B base [leanabell-prover-v2-...].
- **Goedel-V2's own RL stage has no numeric SFT-vs-RL ablation in the text** (Fig. 8 shows pass@1 rising with RL steps; pass@N plateaus) [technical-report-3]. [unverified numerically]. Pythagoras says only "RL yields only modest gains over the curriculum-SFT model" and quantifies none; its large gain is from ALF self-distillation (+6.97 pp for 4B, 79.10 -> 86.07), not RL [pythagoras-prover-advancing-efficient-formal].
- Independent 32B datapoint on the Goedel recipe (SFT vs RL checkpoint, pass@8, 244 problems): 80.33 -> 84.02 (+3.69 pp); ProofNet pass@32 21.51 -> 22.58 [preprint-under-review-8]. Eval tokens and Lean version not stated [unverified]; it is 32B.

Implication for the project: from a heavily RL'd start (Goedel-8B), plain outcome-reward GRPO has a published result of "no gain, slightly negative". A target of +1 pp is within the noise of 244 problems. Any claim needs paired per-problem comparison, >= 32 samples, and the same verifier on both arms.

## 6. Items I could not verify
- Temperature/top_p of the Goedel 84.6 run; Lean/Mathlib for Kimina-Distill-8B and Kimina-RL numbers.
- Whether the Pythagoras PutnamBench rows are the 4B or 32B model; whether Pythagoras-4B has a ProofNet number.
- OProver's R (rounds) used in the headline Table 2 number, and the availability of OProver / Pythagoras weights (claimed in the papers; not checked on HF).
- Provenance of Goedel-8B PutnamBench 3.8% (marked "†, external report" by LongCat; the Goedel paper has no 8B Putnam row).
- Papers surfaced by `scholar search` but not read: EconProver (ACL 2026), LAMP (2606.28841), Learning to Repair Lean Proofs (2602.02990, fetched, repair dataset only), Compiler-Guided Adaptive Proof Search (2608.18084). "When Does Structured Knowledge Help" (2609.34460) was excluded: it uses 488 problems, temperature 0.3 and Lean 4.32, not comparable.

## Protocol amendment (2026-10-14, before any fine-tuned candidate exists)

**Verifier time budget.** A "timeout" is the checker giving up on a finished proof, not a property of
the model's solution, so it must not silently count as a failure. Our 180 s budget came from RL
throughput, not from a standard; Goedel-Prover-V2's own checker uses `PROOF_TIMEOUT=300`
(`lean_compiler/repl_scheduler.py`).

| Use | Budget | Rule |
|---|---|---|
| SOTA evaluation (baseline and every candidate) | **300 s** | matches the published protocol; identical for both arms |
| Sensitivity, reported alongside | 1,200 s | re-check whatever still times out at 300 s; report the undecided count separately |
| RL reward / training-data filtering | bounded | a timeout yields no learning signal, never a negative label |

Baseline at 180 s: 202/244 (82.8%); 31 of the 42 unsolved problems had timed-out samples (274),
re-checked at 300 s.