A useful AI mathematics announcement should let readers reconstruct the result. Which problems were attempted? What did the system prove? Who checked that the formal statement matched the original question? AlphaProof Nexus offers unusually concrete material for answering those questions, while also showing why a proof count needs context.
The source report describes a Science study published on October 8, 2026, following a May preprint. The paper reports nine solved problems from a selected set of 353 Erdős problems, including two that had remained open for 56 years. It also reports 44 proofs from 492 OEIS conjectures. Those are results on prepared collections, rather than a success rate for arbitrary mathematical questions.
Start with the attempted set
Nine out of 353 is approximately 2.5 percent. The other 344 attempts belong in the account because they show the current boundary of the method. The problems also had to be represented in Lean and supported by available formal libraries. Selection, library coverage and compute therefore influence the measured result alongside model capability.
The relevant evidence includes the Science paper, the preprint, and the public proof repository. Successful files make logical checking possible; unsuccessful formalizations help define the evaluation rather than disappearing behind the headline.
Separate three kinds of correctness
Lean checks whether a proof follows from its encoded definitions and assumptions. That is a valuable guarantee, but a different task remains: checking that those definitions faithfully express the intended problem. A changed quantifier, omitted boundary condition or stronger assumption can make a valid proof answer a weaker question.
Novelty requires another review. An existing theorem may already imply a result that the system independently proved. The source reporting notes an audit questioning the novelty of one reported case. That does not invalidate its formal derivation; it changes what can be claimed as new research. The expert reactions provide context for this distinction.
Examine what the agent adds
The core workflow generates Lean code, checks it, and revises unsuccessful attempts using compiler feedback. More elaborate configurations add coordinated search and access to the specialized AlphaProof prover. Importantly, the simplest reported configuration solved the same nine Erdős problems without that specialized tool.
This is a reason to ask for ablation results before crediting architecture complexity. A direct model-and-verifier loop may account for much of the headline performance. More advanced components can still help elsewhere, but their value should be measured by additional successes, lower total cost or better research support.
Budget for the whole research process
A successful inference run is only one expense. Failed searches, formalization, library maintenance, specialist review and the work of translating a formal proof into an understandable explanation all contribute to the result. A per-success price that omits those inputs cannot establish the full cost of discovery.
For a research team, a practical pilot would preserve problem statements, attempted strategies, machine-checkable artifacts, compute spending and human interventions together. Review faithful formalization first, verify the proof next, and assess novelty and explanatory value before describing a problem as newly resolved.
The broader lesson is a design pattern for agents: pair probabilistic generation with a strict evaluator, retain useful intermediate work, and use expert attention where automated checking stops. The original reporting supports that narrower and more useful conclusion. Progress should be judged by independently audited results and gains on previously unsuccessful problems, as well as by the number of completed proofs.