The claim, precisely
On Sudoku-Extreme — the 17-clue setting, the hard end of the benchmark — a GoM of just 98,000 parameters holds the only published learned-solver score — and statistically clears the nearest published headline. (That is the point of the architecture: models sized to the problem, not one giant model for everything.) Across the full 4,865-puzzle 17-clue population, on an Apple M5 laptop running offline, its five-seed ensemble solves 96.86% — and the confidence interval’s lower bound, 96.36%, sits above Kona’s published 96.2%, so it is a real statistical beat rather than a tie. Same accuracy on a laptop as on our datacenter run; no cloud, no server round-trip. For scale, 98K parameters is a rounding error next to a single layer of a modern language model.
Here is exactly how the win is earned. A single deterministic pass scores 95.42% — matching our own datacenter run to within noise, so nothing is lost on the move to the laptop — at roughly 163ms per puzzle, already faster than Kona’s 313ms, though at that speed it sits just under the 96.2% bar. A four-seed ensemble only ties; it is the fifth seed that lifts the interval clear of the bar, and that clean beat is a spend-more-compute choice — several passes instead of one — that the same laptop runs when you want the last fraction of a point.
| System | Headline | Actually measured on | Model size | Hardware | Independently checkable? |
|---|---|---|---|---|---|
| GoM (ours) | 100.00% hardest tier (Jul 9, audited) 98.7% single deterministic pass 96.86% as of Jul 6 | the complete hardest tier — all 4,865 17-clue puzzles, a census, not a sample | 98K params | Apple laptop, offline | reproducible from saved model files |
| Kona | 96.2% | ~13,000 solved public-demo puzzles — their blog’s “See the live benchmark” link points at the demo itself. We sampled their API (n=200, 07/2026): 98% are easier 21+-clue puzzles; 1% are 17-clue | undisclosed | datacenter GPU (their blog: "$4 in GPU time") | no dataset or technical report released |
| BDH (Pathway) | 97.4% | internal, unreleased ~250K collection — not the public benchmark split | demonstrated at 10M–1B — 100×–10,000× ours | undisclosed | authors state open code does not reproduce it |
| PTRM | 98.75–99.06% | full 423K mixed-difficulty set (the hardest tier is ~1% of it), with 100 sampled attempts per puzzle | 5M + K=100 rollouts | GPU | paper published; hardest tier not broken out |
Read the table twice and one fact falls out: we are the only entry measured on the hardest tier at all — and on the easier band the others’ headlines were actually measured on, our score is ~99.8%. Two-way comparison, same verdict either way: smallest model, weakest hardware, hardest test, full transparency — and the best number.
Update, July 9: from 96.86% to all of them
Three days after publishing the 96.86% record, our paper-validation program tested an idea from the PTRM paper (arXiv 2605.19943, Jolicoeur-Martineau’s group — the same lineage our comparator table credits at 98.75–99.06% on the easier mixed set): inject small, seeded Gaussian noise into the model’s recursion so parallel trajectories explore different paths, then let the model’s own halting signal pick. Their mechanism, our architecture, no retraining. Result on the complete tier: one noisy rollout: 99.32% — already beating our five-model ensemble at a fifth of the compute — and under 800 seeded rollouts (32 chunks of 24): 4,865 of 4,865. 100.00%, statistical floor 99.92%.
Because a perfect score is an extraordinary claim, it did not publish until an independent adversarial audit re-verified it end to end: its own Sudoku validator over every answer, its own solver re-deriving each puzzle’s unique solution, a byte-level comparison of our puzzle set against the upstream public benchmark (identical — no substitution possible), search-budget parity across all control arms, and cross-device reproduction of the deciding puzzle. The controls matter: with the same search budget and no noise, the model scores 91.47% flat regardless of vote count — the gain is genuinely the explored diversity, not extra compute. Every rollout is deterministic given its recorded seed; same-seed reruns are bit-identical.
A second import from the same program (signal-propagation fixes from arXiv 2606.18206) independently raised the fast mode — the single deterministic 0.2-second pass with no rollouts at all — from 95.42% to 98.23–98.66% (two seeds). So the product now has two clean configurations: the fast pass at ~98.7%, and the census-perfect mode at 100.00%. We tested whether the two ideas stack; they don’t (measured, not assumed), so each ships where it’s best.
We want the credit flow to be explicit: the noise-rollout mechanism is PTRM’s idea, published by a competitor’s team; the stability fixes come from the Fixed-Point Reasoners group. What our architecture contributed is the substrate where those ideas compound — a 400KB exact-verifying model where their mechanisms reach 100% of the hardest tier instead of 99% of the easiest. That, and the discipline of auditing a perfect score before saying the word.
Same answer, every run
One more property, because it matters as much as the score: the single-pass solver is deterministic. Give it the same puzzle and it returns the identical answer every time, in the same 163 milliseconds — no sampling, no run-to-run variance, nothing sent to a server. The ensemble is the same property repeated five times. How that determinism holds up when plans run hundreds of millions of steps deep is its own story — Note 3: reasoning that holds at depth — but it starts here, at 400 kilobytes.
See it run
Live Real recorded solvesSame architecture, different discipline: the depth story — a 37M-parameter GoM solving Tower of Hanoi in a regime where every frontier model we tested scores zero — is Note 3: reasoning that holds at depth.