The Math Harness

An LLM can write a proof. A math harness decides which problem it must solve and what information it may use. It also decides how the search retains useful state, which claims deserve another attempt, and what must happen before a result reaches a mathematician.

A math harness takes a conjecture stated in natural language and succeeds only by returning a true, human-readable proof or disproof of that exact statement. An LLM must drive the search. Standalone reinforcement-learning and symbolic-search systems without an LLM in the search loop fall outside this survey. Bounds, constructions, and precise accounts of a remaining gap may be useful intermediate artifacts, but they do not count as success. The harness may call a proof assistant, computer algebra system, numerical solver, or search program; none is required. Lean-first systems whose main task is translating a formal theorem into kernel-checked code also fall outside the survey.

The harness surrounds the model with exact problem statements, context and literature, parallel or iterative proof search, durable memory, computation, adversarial review, and an honest stopping rule. More model calls do not by themselves produce better mathematics. A useful harness must preserve the target, accumulate knowledge rather than transcripts, and make an incorrect proof harder to promote than to generate.

The numbers below are a dated map, not a leaderboard. They come from different problems, budgets, release policies, and review standards. They describe individual systems but cannot be compared as one controlled experiment.

Benchmark

A benchmark for a natural-language math harness has an awkward job. The task must be hard enough to require real mathematical work, recent or private enough to resist memorization, self-contained enough that failure does not merely measure missing context, and judged by something stronger than the presence of proof-shaped prose. Cost, abstention, tool access, literature access, and human steering must also be visible.

TCS-Bench

TCS-Bench is the clearest large benchmark currently aimed at research-style natural-language proof generation. Its 300 tasks are extracted from 190 papers published at STOC, FOCS, and SODA between 2020 and 2026. Each task contains up to 10,000 tokens of curated context, a target statement, and a withheld ground-truth proof. The construction recovers a paper’s dependency graph and creates harder variants by hiding intermediate lemmas, so the model may have to reconstruct part of the paper rather than fill one local gap. The task repository is public.

The benchmark uses an automated natural-language proof verifier calibrated against 100 expert-labelled proof attempts; the paper reports accuracy above 90% on that alignment task, although it does not document a separate verifier-prompt test split. In the 13 August 2026 revision, the verifier accepted 204 of 300 outputs from the strongest reported direct model. The paper also evaluates an internal harness called Colosseum, which explores several strategies, decomposes the target, revises a proof, and uses cross-model criticism to choose between two runs. Cross-model selection received 203 acceptances, compared with 162 and 140 for its two individual arms. These are grader verdicts, not established true successes. The benchmark paper only sketches Colosseum, so its results support neither a reproducible harness comparison nor a position on the capability–cost frontier.

TCS-Bench has published reference proofs, scalable difficulty, and enough tasks for controlled comparisons. It does not remove the central difficulty of informal-proof evaluation: its grader is still a language model, and 90% agreement is not mathematical certainty. Papers from 2020 also predate current models, while newer additions offer a cleaner contamination test.

FirstProof

First Proof and its second batch test systems on questions supplied by active researchers before solutions are publicly available. The second batch contains ten problems across several fields, allows only public models and tools, gives systems a 24-hour run, and sends the resulting proofs through expert journal-style review. The small sample makes percentages unstable, but the protocol tests something a large extracted benchmark cannot: whether a system can produce a true proof or disproof of a question whose answer is not already in the literature it can retrieve.

FirstProof has become a common proving ground for Aletheia, RMA, and ProofCouncil. Their quoted results must remain attached to the exact batch and review language. Only an expert-verified complete proof or disproof counts as a success here; partial progress, no returned answer, and a result that still needs a substantive repair all count as failures.

MathArena

MathArena continuously publishes problems, model outputs, and costs for many mathematical tasks. Only its Proof-Based Competitions fit this survey: 50 public problems from USAMO 2025 and 2026, IMO 2025, IMC 2025, the 2025 Miklós Schweitzer competition, and Putnam 2025. The protocol varies: USAMO and IMO have four attempts per model and problem, IMC uses one attempt with MathArena’s expert graders, and Putnam and Miklós use official single submissions. All are scored with competition points, so a harness comparison should instead count each completely correct proof as one binary success and ignore partial credit.

The fixed track is too small and public to be the main benchmark, and its newest slice is already saturated. GPT-5.4 averages 95.24% of the available points on the six USAMO 2026 problems, while GPT-5.5 reaches 98.21%; MathArena flags the latter because the model was released after the competition. A future proof competition could support a useful preregistered comparison if the base model and harness are run immediately under the same dollar limits. The historical leaderboard cannot establish a current harness advantage, and MathArena’s overall score mixes proof generation with final-answer, visual, and Lean tasks that do not measure this objective.

IMProofBench confirms that harder natural-language research problems exist—GPT-5.4 completely solved 49% of its July 2026 paper set—but its internal evaluation system currently exposes no public interface for arbitrary harness submissions. It could become useful through a blind runner: the organizers execute a versioned harness on hidden problems, broker and meter its model and tool calls, retain the problem and transcript, and return binary success counts with dollar cost. The solving process sees each conjecture while the developer does not; a development split may return per-problem feedback, while the final held-out split should reveal only aggregate results.

LemmaBench

LemmaBench continuously extracts lemmas from recent arXiv papers and rewrites them as self-contained problems. Its latest published slice uses 120 retained lemmas from papers posted in the last week of April 2026. The paper’s preferred whole-proof GPT-5.5 judge accepted 49 of 120 GPT-5.5 outputs at pass@1, or 40.8%; a stricter step-by-step GPT-5.5 judge accepted only 25, or 20.8%. The same 120 outputs received a 65.8% acceptance rate from a Gemini 3.1 judge, and the latest slice has no human validation. The published acceptance score is not saturated, but the judge spread is too large to treat any of these verdicts as a true-success count.

Published scores age quickly. GPT-5.6 Sol appeared after the latest LemmaBench experiments, and no public GPT-5.6 run exists. Before using LemmaBench to compare harnesses, run the actual base model once on the exact fresh slice and independently verify its outputs. If it already proves or disproves most tasks, generate a newer slice or preregister a harder band using a separate calibration run. Adding a harness to a benchmark already saturated by the base model measures overhead more than proof search.

The public repository contains the pipeline, but its data/ directory currently contains only a placeholder rather than the published benchmark snapshots. Appendix F of the paper gives one complete example. Anyone who wants to inspect a full set must currently run the extraction pipeline on a chosen arXiv week; the exact 120-problem April slice is not available there as a browsable or downloadable dataset.

The most useful development problems occupy a narrow gap: the chosen base model fails in one zero-shot direct attempt, but a harness built from that model finds a verified proof or disproof within a recorded dollar budget. These cases test search, memory, and verification during development; ablations are needed to tell which mechanism recovered the problem. Because the set is selected after observing the separation, it is a development corpus rather than an unbiased benchmark. The final capability–cost comparison must use fresh held-out problems from the same difficulty band and give the direct model and harness matched model and tool access at several fixed dollar budgets.

A benchmark worth building therefore separates two bands above the model’s zero-shot reach. Tasks the base model fails zero-shot but at least one harness solves measure capability: they are the only tasks on which harness identity can matter at all. Tasks the base model fails zero-shot but every compared harness solves measure cost: with capability tied on that band, cost-of-pass becomes a clean comparison instead of a statistic that hides unequal coverage. Both bands are defined by observed outcomes, so they inherit the selection caveat above: calibrate the bands on development problems, then draw fresh problems from the same difficulty bands for the reported comparison.

Harness

The surveyed systems all place controllers, proof workers, and critics around a language model. Their differences are narrower: what state survives, how a failed proof changes the search, and who or what may declare the proof finished. This section states how to evaluate a harness, what the systems are converging on, and which mechanisms deserve controlled tests; the individual systems are described in the appendix.

Evaluation

A harness has two measured outcomes on a frozen task set: capability, the number of exact conjectures truly proved or disproved, and cost, the total dollars spent by the evaluated system on all attempts, tools, and internal verification. The common blind final adjudication is evaluation overhead outside both arms and is reported separately. Correctness is binary: a false proof, a proof of an easier statement, and partial progress all count as failure.

Compare systems by their Pareto frontier across several budgets. A system is better when it solves at least as many tasks for no more money, with one inequality strict. No single weighted score is needed. Cost-of-pass is a useful derived statistic, but it can hide the difference between a cheap system that solves almost nothing and a more expensive system that reaches a substantially larger set of problems.

The decisive baseline spends the same dollars on independent attempts by the base model and applies the same verifier. Memory, decomposition, parallel workers, and hard gates matter only when they move the harness above and to the left of that baseline. Coverify has not yet run this comparison.

What the systems are converging on

Strip away the system names and the work separates into two jobs. Exploration produces proof routes, lemmas, counterexamples, toy cases, and literature matches while deciding what to repair, replan, or abandon. Verification decides what may cross from speculation into trusted state and, eventually, the final answer. Memory is the handoff: it preserves the status and dependencies of routes, objections, and accepted work without replaying the transcript.

The cells name the mechanism worth testing, not a novelty claim or a performance verdict. “Verification” means the harness’s internal gate; an LLM reviewer accepting a proof does not make it true. A dash means no distinct mechanism is documented or the harness delegates that job.

None of these structures earns a presumption of value. Workers, critics, retries, and memory all cost money, and agreement among models does not make a proof true. On frozen tasks with the same correctness test, a harness earns its complexity only by returning more true proofs or disproofs for the same dollars, or the same number for fewer dollars. Partial progress, consensus, publication, and tidy state do not add outcomes.

Harness mechanisms to test

Test each intervention on frozen held-out tasks against both an otherwise identical arm and independent direct attempts. Keep the available model and tool pool, sources, blind final judge, and user-set dollar budget fixed. Spend any dollars the intervention saves on more calls.

Exploration

• Separate proof and disproof routes. Within the user-set budget, send independent workers after constructions, counterexamples, toy and limiting cases, reductions, and the literature. The control spends the same dollars on generic “prove or disprove” calls; specialization changes the allocation, not how long search may continue.
• Repair the level that failed. Have the critic locate the failure in the derivation, proof plan, or overall approach. Repair that layer instead of reflexively rewriting the proof.
• Return the smallest failure. When an exact or one-sided checker exists, return the smallest violated instance, uncovered region, or failed obligation rather than a scalar score. The next candidate must explain why its repair generalizes.
• Make derivations executable. Couple each proposed symbolic transformation to code that tests adversarial parameter values, prune falsified branches, and require an independent natural-language proof for the surviving derivation.
• Fund evidence, not confidence. At predeclared checkpoints, shift remaining dollars toward routes that have produced a verified lemma, explicit obstruction, exact witness, or checker improvement. Compare with equal funding per route. These artifacts guide routing; they are not successes, and the policy adds no default budget, timeout, or universal route cap.

Verification

• Lock the target and relevance test. Before search, freeze the original quantifiers, admissible assumptions, and what would count as proof or disproof. Reject a candidate only if it changes the statement or invokes a result whose hypotheses and conclusion do not settle it. A correctly matched existing theorem counts; novelty is irrelevant.
• Preserve the verification boundary in memory. Store each claim with its exact statement, proof, dependencies, and status. Numerical hints, unchecked lemmas, finite certificates, and human-checked theorems must retain different types through every summary.
• Verify claims when they become load-bearing. Let speculative lemmas remain visibly unverified. Trigger expensive review when a claim enters a live candidate’s dependency closure, controls a budget-allocation checkpoint, or would permanently prune a route. A terminal proof or disproof may use only a fully verified dependency closure. Compare this lazy policy with eager verification, measuring unused-review dollars, late failures, and verification delay.
• Use one critic with memory and one without it. One tracks whether earlier defects were repaired; the other sees only the frozen statement and current proof. Send disagreements to a third fresh critic.
• Reconstruct the proof blind. Turn a candidate into a dependency brief that states premises and obligations without copying its prose. Ask a fresh solver to reconstruct the proof, then compare the two arguments at their load-bearing steps.
• Extract a verifier. When several attempts fail at the same checkable bottleneck, turn that bottleneck into a project-owned checker. Compare its localized feedback with binary accept or reject.

Measurement and efficiency

The score has two coordinates: exact tasks passed and total dollars spent. Token counts and elapsed time explain movement on that frontier; they do not add dimensions. Raw tokens cannot stand in for money because providers price fresh input, cached input, cache writes, and output differently.

Record every paid leaf

Record each model or tool request once, at the paid leaf. Preserve the full parent chain: campaign → run → wake → dispatch → verification stage → provider request. Store usage as leaf deltas; mark rollups and cumulative snapshots so they cannot enter sums. Each record needs:

• requested and served model, provider, model revision, reasoning effort, experimental arm, replicate, and seed;
• actual billed dollars or the price schedule in force, with provider lanes kept separate;
• fresh-input, cache-read, cache-write, total-output, and reasoning-output tokens, plus the provider’s convention for whether cached input is included in total input;
• attempt count, since a retry can rebill the whole context without adding another visible turn; derive the provider-request count from the transcript when one exists, and otherwise record it once at the paid leaf;
• start, admission, first-token, and completion times, together with queue, rate-limit, backoff, tool, and retry spans;
• a content hash and token count for every prompt component, including the statement, contract, durable state, retrieved routes, transcript tail, wake delta, and tool output;
• cache namespace, reusable-prefix hash, hit or miss, expiration if known, and the exact input hashes governing any reused verifier result;
• links to claim-level premise records and a run-level terminal record whose reason is verified resolution, exhausted user-set dollar budget, user stop, or external failure.

Missing usage remains marked unmetered rather than becoming zero. Reasoning tokens are a subset of output on providers that report them that way; adding both double-counts. A subscription call has no honest per-call cash price, so controlled dollar comparisons should use metered APIs or predeclare an allocation rule and label list-price conversions as counterfactual.

Token and dollar savings to test

• Do not pay to audit a sketch. Run expensive candidate-level verification only after an attempted proof states the exact target, dependencies, and complete proof skeleton; audit a sample of rejected sketches for false negatives. One Coverify campaign spent 30.7 million billable tokens and produced no promotions before candidate-scope discipline. That is a reason to test the gate, not an estimate of what it saves.
• Do not audit orphaned lemmas. Keep speculative, required, and verified claims separate. Queue expensive claim-level review only at the predeclared demand triggers above, while requiring a fully verified dependency closure before success. Measure avoided review dollars, late rejection and repair, and the delay caused when a speculative claim becomes necessary.
• Dependency-scoped packets. Send each role the frozen statement and only the facts it may use, not the campaign transcript or whole evidence tree.
• Stop replaying the failed-route ledger. Retrieve ranked obstruction snippets and a paged route inventory instead. In one campaign, repeatedly presenting a 31 KB ledger contributed about 40.4 million tokens to the reasoner lane.
• Stable prefixes and delta wakes. Keep the contract, statement, and accepted state byte-identical at the front of prompts; append only new evidence so provider prompt caches can be reused.
• Artifact-first tool output. Save full logs and computations once, then send bounded diagnostics plus content hashes and paths rather than reinserting raw output on every turn.
• Content-bound reuse. Content-address retrieval and computation caches. Reuse a saved verifier response only when every input hash and saved output byte matches, the earlier verification sequence stopped before completion, and the response did not influence a repair. Never reuse a candidate–reconstruction comparison or a PASS from a completed verification sequence.
• Route deduplication. Match a proposed mechanism against active and failed routes before dispatch, then measure both avoided duplicate calls and successful ideas incorrectly suppressed.
• Reserve expensive models for mathematical judgment. Use cheaper models for mechanical coordination, retrieval, and preliminary checks, then escalate disagreements and proof candidates to stronger models. Compare the entire capability–cost curve, not token savings alone.
• Cheap checks first. Put deterministic checks of statement identity, dependency integrity, citation resolution, syntax, exact algebra, and finite-witness validity before expensive language-model audits without weakening the final verification policy.
• Finite role outputs. Request the candidate, dependencies, obstruction, and evidence without an exploration diary. Measure later repair spend as well, since a short first answer that causes more retries is not a saving.

Elapsed-time savings to test

• Event-driven scheduling. Wake the coordinator when evidence arrives instead of polling, and coalesce several completed reports when the delay is cheaper than replaying the prompt prefix.
• Parallelism sweep. At the same dollar budgets, test several user-set worker counts and measure the critical path, duplicate routes, and coordinator overhead. This finds a workload-specific knee rather than a universal agent limit.
• Immediate cancellation after verified resolution. Cancel remaining work only after the terminal proof passes independent verification; record cancellation latency, dollars spent after that gate, and provider work that continued after cancellation.
• Asynchronous exact checks. Run independent retrieval, numerical tests, finite checkers, and critic calls concurrently when none consumes another’s output; preserve serial dependencies where one result changes the next prompt.
• Checkpoint and resume. Resume from content-addressed durable state after interruption or compaction instead of reconstructing a transcript. Charge the compaction call and every mandatory state reread.

Saving time by parallelism can spend more money; saving tokens can increase output or repair cost. No wall-clock timeout should truncate proof work. The time report should separate end-to-end duration, critical path, queue delay, tool time, and time to the first independently verified result rather than summing overlapping calls.

Fair comparison

Preregister the held-out task set, user-set dollar budgets, replicate count, and stopping rule, then run paired trials at every budget. Freeze model snapshots, tools, literature access, and the final judge, and freeze every variable other than the intervention; when concurrency is the intervention, keep provider quotas and the model pool fixed. Isolate caches between arms and randomize arm order. The autonomous track permits no human steering. Any human-assisted track stays separate, predeclares how human time is converted to dollars, and includes that cost. Every internal controller, critic, tool, and verifier belongs inside the arm’s cost. One blind external adjudication procedure applies to both arms outside their budgets.

Cold-cache and steady-state trials should remain separate. Warm each arm independently and amortize warm-up over a predeclared number of tasks. Report the capability–dollar pair at each budget, failed-run dollars, paired uncertainty by task, provider splits, cache dollars, and token/time diagnostics. Development tasks selected because zero-shot fails and the harness passes are useful for choosing mechanisms once; the final comparison must use untouched problems from the same difficulty band.

Problem Specific Harness

A problem-specific harness adds a verifier for a recurring bottleneck in natural-language proof search: a polynomial inequality, interval certificate, geometric rule, or symbolic derivation that software can test exactly or conservatively. The verifier supplies dense, local feedback, but the model must still return a proof or disproof of the assigned conjecture.

Such a verifier gives up generality, but it can identify why a candidate failed and direct the next model call toward a smaller defect. Count the trade as useful only when a controlled comparison yields more true proofs or disproofs for the same dollars.

Grothendieck constant

Long-Horizon AI Research for Grothendieck Constant describes a system built around one analytic optimization problem; the complete mathematics appears in a companion paper. Its natural-language reasoning model chooses directions and develops arguments, while a coding agent runs experiments and certifies one-dimensional inequalities with Arb interval arithmetic. The live search is steered through a human-editable bulletin; session reports preserve proofs, code, failures, and explanations for later sessions.

The run lasted from 16 June to 24 July 2026: roughly 240 research sessions, 2,091 reasoning-model calls, 152 million tokens, an estimated $5,400 in API cost, and about 40 dated human directives. The system discovered and first proved the lower bound K_G \ge 6\pi/11; the authors then independently checked and rewrote the proof. The upper-bound construction in the companion result came from an earlier conversation with a reasoning model and predates the reported long-horizon harness. Several stronger bounds produced later remain labelled “system-tested” because their certificates have not yet been checked by the authors.

Repeated state compression dropped a caveat attached to an exploratory numerical score. The compact research state then treated the score as a record for 25 days, until a later test withdrew it, even though the full archive still contained the warning. Saving everything did not keep the decision state sound. A harness must preserve the few facts that determine whether later conclusions remain valid.

Gilbert–Pollak and the Steiner ratio

Towards Solving the Gilbert–Pollak Conjecture via Large Language Models narrows proof search much further. The model does not attempt the conjecture end to end. It generates rule-constrained geometric lemmas as executable structured code. Those lemmas instantiate verification functions whose shape reduces a continuous inequality over a region to checks at finitely many vertices, with symbolic algebra and recursive subdivision supplying the certificate. The prompts, code, and certificate are public.

The search–verify–reflect loop reports a certified Steiner-ratio lower bound of 0.8559, improving the prior 0.824 bound while remaining below the conjectured \sqrt{3}/2. When a candidate set of lemmas fails, the verifier returns a localized region in which coverage is missing; that structured failure becomes the next prompt. The certificate is a true theorem about the lower bound, but the run is not a success if the assigned target is the Gilbert–Pollak conjecture.

The system is not fully autonomous. The paper states that every model-proposed lemma was manually checked before being installed as a verification function, and its cylindrical-algebraic-decomposition verifier becomes expensive as dimension and degree grow. Those limitations define the bargain: human and symbolic effort build a narrow certified search space, and the language model explores it at a scale that manual lemma design could not.

Cosmic-string radiation integral

Solving an Open Problem in Theoretical Physics using AI-Assisted Discovery couples Gemini Deep Think to a PUCT tree search over derivations of a singular integral governing gravitational radiation from cosmic strings. Each node contains an intermediate LaTeX expression and executable Python code. A high-precision numerical evaluator scores the expression on random parameter values and feeds errors or tracebacks back to the model. The search explored about 600 nodes and pruned more than 80% for algebraic errors or numerical divergence before finding six analytic approaches, including an exact Gegenbauer expansion.

The numerical evaluator can reject a false identity at a sampled point, but it cannot certify a universal identity. After the first run, a researcher manually started a second session with a stronger model; that model corrected an error in the first spectral recurrence and simplified an exact infinite series to a finite analytic expression. The paper supplies the derivations, giving an exact human-checkable solution to the integral, but the workflow is a human–AI handoff rather than a fully autonomous run. An autonomous evaluation must score the initial run as a failure. A human-assisted evaluation may count the solved result only if it includes the second model run and prices the researcher’s intervention.

A thin harness with local verifiers

Keep the boundary between general and problem-specific machinery movable. Start with natural-language search and durable adversarial review. If repeated attempts hit the same checkable bottleneck, put a verifier in the project and return its smallest counterexample or uncovered region to the search. The verifier remains local; a finite checker does not prove an unbounded theorem until the reduction to that checker is proved.

The general harness stays thin. Natural language carries the question, choice of direction, proof explanation, and interaction with a mathematician. Exact tools enter only where the problem supplies an exact interface. Lean is one option, not a requirement.

Appendix: The Harnesses

Aletheia

Aletheia, from Google DeepMind, is the minimal loop: Gemini Deep Think generates, verifies, and revises a natural-language solution until the verifier accepts it or the run reaches a limit. The system is not released, but its prompts and research outputs are public.

Aletheia ran 700 questions then marked open in the Erdős Problems database. It returned 212 candidates; human review found 63 technically correct answers, but only 13 that addressed the intended mathematical question through a relevant argument or literature result. The paper groups four autonomous solutions and partial solutions to open questions rather than reporting a binary count of exact resolutions, so that number cannot enter the capability–cost comparison. The drop from 212 candidates to 13 relevant answers is why target interpretation and exact source matching belong inside the harness, not after it.

Rethlas

Rethlas adds theorem retrieval through Matlas and recursive proof subagents to the worker–verifier loop. Its workers search literature, test toy cases and counterexamples, plan, and draft informal arguments for a separate natural-language verifier. Archon can formalize the result in Lean afterward, but Rethlas itself does not require Lean and its code is public.

Danus

Danus changes the shared state. Parallel Rethlas workers explore claims, counterexamples, and toy cases, but only a stateless verifier may admit a claim to a content-addressed fact graph. Each accepted fact carries its proof and dependencies; the graph, not the agent transcripts, feeds the final paper. Danus is open source.

The paper presents six case studies in algebraic geometry, singularity theory, and combinatorics. In its strongest matched case, three Rethlas runs failed while Danus, using the same worker and verifier models, produced a candidate that human review found locally incomplete but repairable. Under the binary criterion here, that run is a failure. The case gives a reason to test parallel search and fact-level memory, not evidence that they improve capability.

ProofCouncil

ProofCouncil changes the review schedule. One critic remembers earlier drafts and checks whether their defects were repaired; every few rounds another sees only the current proof. The author can also consult other model families or a computer-algebra agent, and returns the proof only when author and both critics agree. The harness and its DAG-based agent library are public.

On the second FirstProof batch, expert referees judged six of ten submissions correct up to at most minor revisions. On 30 researcher-supplied problems, 21 received feedback: five were judged complete, two possibly complete, eight useful partial progress, four had no apparent errors but little substantive progress, and two answered easier interpretations. The official FirstProof run cost about $350 per analyzed problem, while a roughly $12 one-query baseline received the corresponding positive verdict on four of nine analyzed problems rather than six. These categories must be converted to the same binary truth criterion before either system can enter the capability–cost comparison.

QED

QED changes error recovery. Its regulator classifies a failure as local to the proof, structural to the dependency-DAG plan, or fatal to the whole approach, then revises at that level. Different coding-agent backends can generate and verify in parallel. The implementation and proof artifacts are public.

The paper evaluates 18 research projects and reports five original works accepted by the corresponding domain experts. Two have separate public manuscripts that explicitly attribute their proofs to QED: lower bounds for advection–diffusion equations and the return probability of a lamplighter walk on a regular tree. Both include a QED developer as an author, so they demonstrate output rather than independent third-party adoption. Under one reported verifier configuration, all 17 accepted candidates were later accepted by experts. That 17-for-17 agreement says nothing about false acceptance: rejected candidates were not all independently labelled, and the projects were not a frozen random test set.

RMA

Research Math Agents (RMA) puts a compact, disk-based knowledge bank between controlled literature search and proposer–verifier rounds. It reports eight correct solutions on the first FirstProof set under its own blind expert evaluation, along with ablations over memory, proposer and verifier counts, and rounds.

RMA is not yet a reusable public harness: the May 2026 paper says that solutions and implementation will be released upon acceptance. Until the implementation and complete run artifacts can be inspected, its results remain author-reported.

MechMath Agent Team

MechMath Agent Team (MMAT) differs in scope rather than proof-search technique: it packages the loop as a long-lived project workspace. A Natural Language Prover, Formal Language Prover, and Knowledge Base Manager exchange files and persistent memory under a task DAG and ledger. The public project template supports Codex and Claude Code, and the Natural Language Prover runs separately, so Lean is optional for the part relevant here.

Table 4 reports 11 solved problems over two months and nine completed arXiv works, while the conclusion says ten problems. The manuscripts mix natural-language proofs generated alongside Lean formalizations, interactive human–MMAT collaborations, and a finite certificate produced with human guidance; one human-involvement label also conflicts with its manuscript. The public template contains no deployment traces, and the paper gives neither dollar cost nor a matched direct-attempt baseline. Its output cannot yet be placed on the capability–cost frontier.

AI co-mathematician

The AI co-mathematician keeps a human inside the control loop. A project coordinator negotiates goals, launches parallel literature, reasoning, coding, and review workstreams, and writes reports into a shared workspace. The current prototype’s proofs are informal; formal provers are optional future components.

Its case studies emphasize collaboration rather than autonomous pass rates. A mathematician can inspect a failed proof, salvage its strategy, supply the missing idea, and ask the system to rebuild and review the argument. A repaired proof belongs in a human-assisted track; preserved state and partial assistance alone do not count as successes.

qmd-prover

qmd-prover is a proof-document harness rather than a search strategy. Claude Code or Codex writes definitions, statements, and proofs as Quarto Markdown blocks with stable identifiers and explicit dependencies. The TypeScript tool locks the main statement, checks the graph mechanically, can send each proof with only its cited premises to a fresh AI reviewer, and renders the result as a navigable book.

The host coding assistant still supplies the proof search, and the optional reviewer remains a language model rather than a formal kernel. Model separation is configured rather than enforced, assumed facts may be permitted, and the default review policy allows advisory gaps that strict mode would reject. The repository reports a 34-fact Gödel-completeness demonstration, but publishes no benchmark or auditable verifier transcript. I found no public paper that cites qmd-prover or attributes a research result to it as of 14 August 2026.

Coverify

Coverify binds promotion to exact saved artifacts. A campaign freezes one statement and records its routes, candidates, gaps, audits, and promotions as plain files. Before promotion, a candidate faces a hostile audit, a proof-leak check on its dependency brief, blind reconstruction from that brief, and comparison with the original. Verifier reuse is bound to every stage input and the saved artifact hash.

Coverify is not a proof assistant. “Promoted” means that specified language-model reviews passed on exact saved bytes; it does not mean the theorem is machine-checked or true. The current implementation is a working research harness with live campaign experience. It has not yet produced a capability–cost curve against the raw proof-search workflow, so cost-efficiency remains a design target rather than a result.

Public attribution ledger

Rethlas has the largest traceable public-paper footprint I found. This is a bibliography of disclosed use, not an evaluation metric: publication count is neither capability nor cost, and no manuscript counts as a benchmark success merely by appearing here. For this snapshot I counted a distinct public result manuscript only when its own text names the harness and credits it with generating, discovering, completing, materially structuring, or verifying mathematical content. I excluded each harness’s system paper, benchmark reports, private or repository-only artifacts, ordinary related-work citations, and statements that one harness merely descends from another.

One manuscript credits both Rethlas and Danus, so the first two rows contain 31 distinct manuscripts rather than 32. The counts measure disclosed use, not mathematical correctness, autonomy, importance, or independent adoption. They are lower bounds dated 14 August 2026: papers can appear faster than indexing, and authors vary in how much AI assistance they disclose.

Rethlas attribution ledger

The 21 manuscripts behind the leading count are:

1. A Counterexample to Problem 19 on Integer-valued Polynomial Rings
2. An Integrally Closed Reduced Ring with McCoy Localizations That Is Neither McCoy nor Locally a Domain
3. On a question of Kollár and Kovács
4. An example of a very non-movable effective divisor
5. Optimal bend-and-break for foliations
6. On a question of Mauri and Moraga
7. A question on klt type varieties of Han and Jiang
8. Shokurov’s global index conjecture for threefold foliations
9. Boundedness of total Cartier indices for rational singularities in families
10. Degenerate constants in degree inequalities for Sobolev circle maps
11. On some open problems in commutative algebra resolved by Rethlas
12. Lift-independence problem in the p-adic Simpson correspondence for curves
13. A counterexample to the near-quadratic Elekes–Rónyai expander conjecture over \mathbb R
14. On Injectivity of Phase Retrieval
15. Criteria of isolated weighted homogeneous hypersurface singularities using Logarithmic vector fields
16. Involution-equivariant topological recursion and mirror symmetry for the affine binary dihedral Calabi–Yau threefold
17. Kazhdan–Lusztig polynomials of matroids need not be unimodal
18. Analytic Bertini theorem II — The local case
19. A counterexample to the zero-mass conjecture
20. Factorial asymptotics of the Matryoshka numbers
21. On a conjecture of Esser, Totaro, and Wang

The Rethlas results repository preserves raw outputs for several of these projects. The individual manuscripts remain the attribution authority: some describe complete autonomous proofs, others a discovered construction, repaired proof, verified computation, or substantial proof architecture later checked and rewritten by humans. The latter categories document adoption but are failures if the harness’s assigned conjecture was not truly proved or disproved.