Astra Explained: How an Unreleased OpenAI Model Solved 10 Open Math Problems With Zero-Sorry Lean Proofs

In the first days of August 2026, OpenAI published something unusual: not a product, not a model you can sign up to use, but a 249-page manuscript and a GitHub repository. The manuscript describes ten problems in mathematics and theoretical computer science that had sat unsolved for at least a decade, most for far longer, and claims an unreleased internal version of OpenAI's next model family, code-named Astra, solved every one of them [1][3].

What makes this worth a long technical post, rather than a one-line news blurb, is not the headline. "AI solves hard math problem" has been a recurring, often overhyped, genre of announcement for a few years now. What is different here is the verification story: every one of the ten results ships as a Lean 4 formal proof, published under an open license at github.com/openai/ten-proofs, that anyone with a laptop can compile and check against Lean's kernel without trusting OpenAI's word for anything [2]. That is a fundamentally different claim than a benchmark score, and it is worth understanding exactly what it does and does not prove.

This post walks through what actually shipped, the ten problems themselves, how a language model produces a machine-checked proof at all, how to reproduce the verification yourself on your own machine, what the eight-hundred-dollar-per-problem cost figure really means, and what mathematicians outside OpenAI have said about it so far.

If you would rather generate a short clip than a still image to illustrate that same verification idea, here is a video generation prompt built around it, written for a Wan-style video model:

Ten identical wax-sealed paper scrolls rest in a neat row on a warm wooden desk under soft studio light. The camera slowly dollies forward as, one by one from left to right, each scroll's wax seal cracks open and unrolls flat, revealing a formal ruled ledger page that stamps itself with a glowing brass checkmark seal in a single decisive motion, a small puff of fine dust rising with each stamp. By the final scroll the whole row lies open and stamped, and the camera settles on a slow overhead pull-back showing all ten stamped pages at once. Photoreal editorial product-shoot lighting, warm and precise, shallow depth of field, no readable text, no logos, no people, smooth deliberate camera motion.

Step 1: What OpenAI Actually Published

Strip away the framing and the concrete artifact is this: a paper titled "Ten advances in mathematics and theoretical computer science," a 249-page PDF manuscript, and a companion GitHub repository containing a Lean 4 formalization of each result [1][3]. OpenAI used the release to introduce the name of its next major model family, Astra, without shipping Astra itself. No API access, no waitlist, no benchmark leaderboard entry. Just the proofs, the model's reasoning walkthroughs behind them, and an invitation to check the work [1].

That is an odd way to introduce a model, and it appears to be the point. OpenAI researcher Noam Brown, commenting on the release, put it dryly: "Sadly, no Millennium Prize Problems (yet)" [3], acknowledging the obvious next question while framing this batch of results as a step below that famous tier of unsolved problems, not a claim to have cracked one of them. The ten problems here are genuinely open research questions across group theory, high-dimensional geometry, coding theory, quantum complexity, lattice-based cryptography, and extremal combinatorics, each of which had resisted specialist mathematicians and computer scientists for at least ten years [1].

One data point from earlier in the year sets the context for how seriously to take this. In May 2026, an earlier internal system reportedly resolved a variant of the Erdős unit distance conjecture, a discrete geometry problem that had resisted direct attempts since 1946 [3]. The August release is a much larger, more formally packaged version of the same underlying claim: a reasoning model, given enough inference-time compute, can push past the frontier of pure mathematics research, not just replicate known results faster.

Step 2: The Ten Problems, One by One

The most reliable source for exactly what was solved is not a news summary, it is the file list in the GitHub repository itself, since each Lean file name maps directly to one formalized result [2]. Here is the full set:

A few of these are worth a plain-language gloss, since the file names alone do not convey why mathematicians care.

The non-sofic group construction answers a question the mathematician Mikhail Gromov posed in 1999: do all countable groups embed, in a precise technical sense, into a limit of finite symmetric groups? A "sofic" group is one that does. Whether every group is sofic had been open for a quarter century, and constructing an explicit non-sofic example, rather than proving one must exist abstractly, is exactly the kind of concrete, checkable construction that a formal proof assistant is well suited to verify [1][5].

The Connes rigidity conjecture result goes the other direction: it is a disproof, a counterexample showing a widely believed conjecture about von Neumann algebras (a foundational structure in operator algebra theory) does not hold in general. Disproving a conjecture mathematicians had largely assumed was true, rather than proving an open question, carries a different kind of research weight, since it redirects an entire research program rather than closing one out [1].

The multicolor Ramsey number result is described in more than one independent write-up as coming from Paul Erdős's own catalog of open problems in combinatorics, one of several results in the batch drawing on Erdős-style extremal questions [6][3]. Ramsey numbers, informally, measure how large a structure has to be before a certain kind of order is unavoidable inside it, and multicolor variants are notoriously hard to pin down even approximately.

The closest vector problem (GapCVP) hardness result sits in a different neighborhood entirely: lattice-based cryptography. Hardness-of-approximation results for problems like GapCVP are part of the theoretical foundation underpinning post-quantum cryptographic schemes, so a new hardness bound here is not an abstract curiosity, it feeds directly into how confident cryptographers can be in systems built on lattice assumptions [2].

Step 3: Why "Machine-Checkable" Is the Whole Story

A skeptical reader should have one immediate question here: mathematicians and AI labs have claimed AI-assisted proofs of hard problems before, and more than a few of those claims did not hold up once independent reviewers looked closely, sometimes because the "proof" quietly assumed the thing it was trying to show, sometimes because it worked for small cases and was presented as general. What makes this batch different is that the claim is not "trust our proof," it is "here is a machine-checkable certificate, go run it yourself."

That distinction runs on a tool called Lean, an interactive theorem prover and functional programming language built specifically so that mathematical proofs can be written in a form a computer can verify line by line, not just typeset [2]. Lean 4 ships alongside mathlib, a large, community-maintained library of already-verified mathematical definitions and lemmas that a new proof can build on, the same way a piece of software imports a standard library instead of reimplementing everything from scratch. When a Lean file compiles successfully against the Lean kernel, every logical step in it has been mechanically checked, no gaps, no hand-waved "it is easy to see that."

The specific thing to look for in a Lean proof is the word sorry. In Lean, sorry is a placeholder tactic: it lets a file compile even when a step has not actually been proven, explicitly marking that step as an admitted gap rather than a completed argument. A Lean file full of real proof work but with a single sorry buried in it is, formally speaking, not a proof of anything, it is a proof with a hole. OpenAI's specific claim for this release is that the repository's sorry count across all ten formalized proofs is zero, meaning every step, in every one of the ten files, compiles as a complete, gap-free argument against Lean's kernel [2]. That is a much stronger and more checkable claim than "our model produced a convincing-looking proof," and it is checkable by anyone, not just by OpenAI.

Step 4: Reproducing the Verification Yourself

This is the part that makes the claim genuinely different from a benchmark screenshot: you do not have to take anyone's word for the zero-sorry claim. You can check it yourself, on your own machine, with open-source tooling.

The repository's own build instructions use elan, Lean's toolchain version manager, and lake, Lean's build tool, targeting Lean 4.32.0 [2]:

bash
/code
# Install elan (Lean's toolchain version manager) if you do not already have it
curl https://raw.githubusercontent.com/leanprover/elan/master/elan-init.sh -sSf | sh

# Clone the repository and let elan pick up the pinned Lean 4.32.0 toolchain
git clone https://github.com/openai/ten-proofs
cd ten-proofs

# Pull prebuilt mathlib cache instead of rebuilding it from source, this is
# the single biggest time saver, mathlib itself is enormous
lake exe cache get

# Build every formalized proof in the repository against the Lean kernel
lake build All

# Or build one specific result, for example the non-sofic group construction
lake build NonSoficGroup

Once the build succeeds, a compiled Lean file with no sorry in it has, by construction, no unproven gaps. But you do not need to trust that implication blindly either, you can search the source directly. This is a genuinely useful, general-purpose technique any time you are handed a Lean repository and want an independent sanity check before trusting a headline claim about it, not something specific to this one release:

bash
/code
# Independently audit a Lean repository for admitted proof gaps.
# A zero-result here, combined with a clean `lake build All`, is what
# actually substantiates a "fully verified, zero-sorry" claim, rather
# than just trusting the paper that makes it.
cd ten-proofs

# Search every .lean source file for the sorry placeholder tactic,
# excluding comments that merely mention the word
grep -rn --include="*.lean" -E '(^|[^a-zA-Z_])sorry([^a-zA-Z_]|$)' . | grep -v '^--' || echo "No admitted gaps found in $(find . -name '*.lean' | wc -l) Lean files."

If that script prints nothing for a repository claiming zero admitted gaps, and the lake build All step from the previous snippet completed without errors, you have independently reproduced the core verifiability claim yourself, using nothing but open-source tooling and the public repository. That is a meaningfully different epistemic position than reading a press release.

Step 5: How a Model Actually Produces a Formal Proof

Getting a language model from "here is an open math problem" to "here is a Lean file that compiles with zero gaps" is not one step, it is a pipeline, and it draws on a research thread that predates this release by at least two years.

The general approach, often called autoformalization when it runs in the natural-language-to-formal direction, breaks roughly into stages: a model proposes a natural-language proof sketch or strategy, that sketch gets translated into formal statements and tactic calls in the target proof language, the formal attempt is checked against the language's kernel, and failures feed back into the next attempt rather than being discarded [9]. Recent research on autoformalization, including work using joint embeddings to align natural-language proof steps with their formal Lean counterparts, treats this translation step itself as a learnable problem rather than a fixed rule-based conversion, which matters because natural mathematical language is often deliberately imprecise in ways a formal system cannot tolerate [9].

The proof-search half of the pipeline, actually finding a sequence of tactics that gets a formal statement to compile, is where inference-time compute does the heavy lifting. This is the same underlying idea behind why reasoning models spend variable amounts of "thinking" time on hard problems: research on scaling test-time compute has shown that adaptively spending more inference-time search on a harder problem, rather than using a fixed budget for every query, can match the performance of a model many times larger on the problems that need it [10]. A proof search over Lean tactics is a particularly good fit for this idea, because the Lean kernel gives an unambiguous, immediate signal, a candidate step either type-checks or it does not, which is exactly the kind of dense, reliable reward signal that makes extended search tractable instead of just expensive.

None of this is invented for Astra. Google DeepMind's AlphaProof and AlphaGeometry 2 demonstrated the general shape of this approach at IMO 2024, reaching a silver-medal-equivalent score by combining a reinforcement-learning-trained formal prover with a geometry-specific solver, with some problems solved in minutes and others taking up to three days of search [11]. Notably, the human judges who scored those AlphaProof solutions against official IMO grading criteria included Sir Timothy Gowers, the same Fields medalist who has now reviewed and praised the Astra manuscript two years later [11][3]. A year after that, DeepMind's Gemini Deep Think reached full gold-medal-equivalent IMO performance, officially recognized by the IMO itself [12]. Astra's ten open-research proofs are best understood as the next point on that same trajectory, moving from competition mathematics, where a correct answer is already known to exist, to open research problems, where nobody knew in advance whether a solution existed at all.

Here is a minimal, deliberately simplified illustration of what a Lean proof with and without an admitted gap actually looks like in practice, so the sorry concept above is concrete rather than abstract. A real formalized proof of, say, the Ehrhart volume inequality result runs to hundreds of lines built on mathlib lemmas, but the shape of the gap is the same at any scale: a statement like theorem add_comm_example (a b : Nat) : a + b = b + a := by sorry compiles in Lean, because sorry satisfies the type checker, but it proves nothing; replacing sorry with an actual tactic proof, by ring in this trivial case, is what turns a compiling file into a verified one. Auditing a Lean repository for research claims essentially means checking, at scale, that every one of those sorry placeholders has actually been replaced with real tactic work, which is exactly what the audit script in Step 4 automates.

Step 6: The $2,000 Number, and Why It Is Not the Whole Cost

The figure that traveled fastest through coverage of this release is the price tag: roughly $2,000 in compute, at OpenAI's own Sol API token rates, to produce all ten results [1][3]. It is a genuinely striking number next to a 249-page manuscript solving decade-plus-old open problems, and it is also, on its own, a somewhat misleading one if read as "AI does world-class mathematics for pocket change."

Forbes's own analysis of the figure makes the important caveat explicit: the $2,000 figure appears to represent the token cost of the successful runs that produced the final proofs, not the cost of every attempt the model made along the way, including the ones that did not pan out, which makes it closer to a cost of publication than a true cost of discovery [3]. Any search process, whether it is a Lean tactic search or a human mathematician's own false starts, spends most of its effort on paths that do not work out. A model exploring ten genuinely open problems almost certainly burned meaningfully more compute than the $2,000 figure captures, on approaches that were abandoned, re-tried, or replaced entirely before a working proof emerged. That does not make the number meaningless, a real, reproducible result did land at roughly $200 per problem in final-run token cost, but it is worth reading as a lower bound on what the underlying research effort actually cost to run, not the full number.

Step 7: What Mathematicians Outside OpenAI Actually Said

The most load-bearing piece of external validation in this release is not a benchmark score, it is that named, credentialed mathematicians outside OpenAI reviewed the work and were willing to put their names next to a specific, checkable opinion.

Sir Timothy Gowers, a Fields Medal winner and one of the two human judges who scored AlphaProof's IMO 2024 solutions two years earlier, reviewed at least one of the ten Astra results and said he would recommend it for publication in a top mathematics journal without hesitation [3][11]. That is a meaningfully strong endorsement from someone who has no institutional incentive to inflate OpenAI's claims, and whose earlier public role judging machine-generated proofs gives his opinion here unusual weight.

At the same time, the honest framing from multiple outlets covering the release is that the broader mathematical community's reaction is positive but still cautious, describing the work as still being digested and reviewed rather than instantly, universally accepted [7][5]. That caution is appropriate and worth preserving rather than smoothing over. A machine-checked Lean proof settles the question of whether the logical steps are valid, that part is not really open to debate once the file compiles with zero sorry placeholders. It does not by itself settle questions a working mathematician still cares about: whether the proof is illuminating, whether it generalizes, or whether the formal statement being proven actually captures the informal conjecture mathematicians meant when they posed the original open problem decades ago. Formalizing the wrong statement correctly is a real failure mode distinct from formalizing the right statement incorrectly, and only human mathematical judgment, not the Lean kernel, can catch the former.

Step 8: Where This Fits in the Broader Reasoning-Model Story

Zoom out and this release is not really a standalone event, it is one more data point in a pattern that has been building across the industry throughout 2026: labs pushing reasoning models to spend variable, sometimes very large, amounts of inference-time compute on genuinely hard problems, rather than only competing on model size or single-pass response speed. The same underlying test-time compute scaling research that explains Astra's approach to proof search also explains why frontier reasoning models increasingly ship with adjustable effort settings for exactly this tradeoff, letting a user or a system choose between a fast, cheap answer and a slower, deeper one depending on how hard the task actually is [10].

That broader shift matters even outside pure research settings. Any AI system that has to reason correctly through a multi-step problem before producing a usable output, whether that is a formal proof, a piece of production code, or a creative pipeline that has to plan a script before generating matching visuals, benefits from the same underlying advances in how well models can search, verify, and revise their own intermediate reasoning. Miraflow's own Text2Shorts pipeline, for instance, depends on a model correctly reasoning through a script before it generates the scene visuals that match it, a much smaller-stakes version of the same "reason correctly through several dependent steps before committing to an output" problem that a formal proof search has to solve at a much higher bar. The tools are different, a video pipeline and a Lean kernel do not share code, but the underlying research trend, models getting better at extended, checkable, multi-step reasoning, is the same current lifting both.

Step 9: A Practical Checklist for Evaluating the Next Claim Like This

This will not be the last "AI solved an open problem" headline you read, and the tools above generalize well beyond this one release. Here is a concrete checklist worth running before deciding how much to trust the next one:

• Is there a machine-checkable artifact, or just a natural-language write-up? A Lean, Coq, or Isabelle file you can compile yourself is a fundamentally stronger claim than a paper describing a proof in prose, since the latter still depends on human reviewers catching every gap by eye.
• What is the actual gap count, not just the headline claim? Run the audit script from Step 4, or its equivalent for whatever proof language is involved, yourself. Do not take "fully verified" at face value without checking for sorry or its equivalent placeholder in the target system.
• Did the build actually succeed on your own machine, against the stated toolchain version? A repository that does not build cleanly against its own documented dependencies is a red flag regardless of what the paper claims.
• Is the model that produced the result the one being sold to you? Astra, as of this release, has no public API. That is a meaningfully different claim than "our shipping product can do this," and it is worth being explicit with yourself about which claim is actually being made.
• Has more than one named, credentialed outside expert reviewed it? One strong endorsement, like Gowers's here, is a real signal. It is still one data point, not a consensus, and coverage describing the reaction as "still being digested" is more accurate than coverage that skips straight to "settled."
• Does the cost figure represent total research cost, or the cost of the final successful run? As Step 6 covers, these are very different numbers, and headline compute-cost figures routinely conflate them.

Common Mistakes When Reading Claims Like This

• Treating "an unreleased internal model solved this" as equivalent to "you can now get this from a public product." Astra has no public API as of this release. The capability existing inside a lab's research environment and that capability being available to you are two different facts.
• Assuming zero sorry placeholders means the proof is easy to understand or teaches you anything. A machine-checked proof can be logically airtight and still be, in Gowers's own domain, dense or unintuitive to a human reader. Formal correctness and mathematical insight are related but distinct properties.
• Quoting the $2,000 figure as the full cost of discovery. As Step 6 covers, the number most likely reflects the token cost of the successful runs, not every abandoned search path along the way.
• Skipping independent verification because a Lean file "should" be trustworthy. The entire point of publishing an open-license, buildable repository is that you do not have to assume that. Running lake build All yourself takes a few minutes and turns a claim you are trusting into one you have checked.
• Conflating this release with earlier, weaker "AI solved a proof" claims that did not hold up. The machine-checkable, zero-gap, openly buildable packaging here is a materially higher bar than a model producing a convincing-looking but unverified proof sketch, which is exactly the distinction this post is trying to make legible.

Production Notes: Using This Same Pipeline on Your Own Formalization Work

If you work with Lean or another formal proof assistant yourself, the reproducible shape of this release, not just its headline results, is worth borrowing directly. A few practical habits carry over from Steps 4 and 5:

Treat sorry auditing as a standard CI check, not a manual step you remember to run before a release. The bash snippet in Step 4 is short enough to drop directly into a GitHub Actions workflow that runs on every pull request touching a .lean file, failing the build the moment an admitted gap sneaks into a branch.

Separate proof-search compute from proof-checking compute in your own cost accounting, the same distinction Step 6 makes about the $2,000 figure. Checking a finished proof against the Lean kernel is fast and cheap. Finding that proof in the first place, whether by a human or a model, is where the real cost lives, and conflating the two numbers in your own project's cost tracking will consistently understate what a hard result actually took to produce.

Pin your toolchain version explicitly, the way the ten-proofs repository pins Lean 4.32.0. Formal proof assistants and their standard libraries move fast enough that a proof which compiles today can fail against a newer mathlib release next year, and an explicit, elan-pinned toolchain version is what makes a formalization reproducible years later rather than just at publication time.

Frequently Asked Questions

Is Astra a publicly available model? No. As of this release, Astra has no public API, waitlist, or product surface. OpenAI used the results to introduce the name of its next model family while keeping the model itself internal.

What does "zero sorry" actually mean? sorry is a placeholder in the Lean proof language that lets a file compile even when a proof step has not actually been completed, explicitly marking it as an admitted gap. A zero-sorry count across the repository means every logical step in all ten formalized proofs compiled as a complete argument against Lean's kernel, with no admitted gaps.

Can I actually verify these proofs myself without trusting OpenAI? Yes. The repository is public under an Apache-2.0 license. Cloning it and running lake build All with the Lean 4.32.0 toolchain, as shown in Step 4, independently reproduces the compilation. Searching the source for the string sorry independently reproduces the zero-gap claim.

Did this solve a Millennium Prize Problem? No, and OpenAI's own team was explicit about that distinction, joking that there were "sadly, no Millennium Prize Problems (yet)" among the ten results. These are real, decade-plus-old open problems, but they sit a tier below that most-famous category of unsolved mathematics.

How is this different from earlier claims that AI solved a hard math problem? The key difference is machine-checkable, zero-gap formal verification published under an open license, rather than a natural-language proof write-up that depends on human reviewers catching every gap. That is a substantially higher, independently checkable bar than most earlier claims in this space met.

What is the relationship between this and DeepMind's AlphaProof? They are part of the same broader research trajectory, using reinforcement-learning-style search over formal proof steps, verified against a proof assistant's kernel, to solve problems progressively further from anything in the model's training data. AlphaProof reached IMO silver-medal-equivalent performance on competition mathematics in 2024. Astra's release extends the same general approach to open research problems where no known solution existed in advance.

Conclusion

The headline number, $2,000, is the part of this story that traveled fastest, and it is also the part most likely to mislead if taken at face value as a full cost of discovery rather than a cost of the final successful runs. The part worth actually sitting with is the packaging: ten open problems spanning group theory to lattice cryptography, each shipped as a Lean 4 file anyone can compile and check, with a documented zero-sorry gap count, reviewed by outside mathematicians willing to put their names on a specific opinion about specific results. That is a meaningfully higher, more falsifiable bar than most AI research claims clear, and it is one you do not have to take on faith, the build instructions in Step 4 above are enough to check it yourself. Whether or not Astra itself ever ships as a public product, the verification pattern this release demonstrates, machine-checkable proof over prose claim, is likely to be the template the next several "AI solved an open problem" headlines get measured against.

References and Sources

[1] OpenAI. "Ten advances in mathematics and theoretical computer science."

[2] GitHub. "openai/ten-proofs: Lean certificates accompanying ten proofs in mathematics and theoretical computer science."

[3] Forbes (Jon Markman). "OpenAI's Astra Solved Decades-Old Math Problems For $2,000."

[4] Tech Times. "OpenAI's Astra Solves Ten Decade-Old Math Problems With Machine-Checkable Lean Proofs."

[5] The Decoder. "OpenAI announces its 'next major model' Astra by dropping ten previously unsolved math solutions."

[6] DataCamp. "OpenAI's New Model, Astra, Has Solved Ten Open Math Problems."

[7] The Rundown AI. "OpenAI's 'Astra' solves 10 long-standing math problems."

[8] TheNextWeb. "OpenAI says its next model, Astra, has solved ten open problems in mathematics."

[9] arXiv. "ProofBridge: Auto-Formalization of Natural Language Proofs in Lean via Joint Embeddings."

[10] Snell, Lee, Xu, Kumar. "Scaling LLM Test-Time Compute Optimally Can Be More Effective Than Scaling Model Parameters."

[11] Google DeepMind. "AI achieves silver-medal standard solving International Mathematical Olympiad problems."

[12] Google DeepMind. "Advanced version of Gemini with Deep Think officially achieves gold-medal standard at the International Mathematical Olympiad."

[13] YouTube. "OpenAI's Astra Solved 10 Unsolved Math Problems — for ~$2,000."