Formal verification has long been the domain of specialists willing to spend weeks convincing a proof assistant that a piece of code or a theorem behaves exactly as intended. Leanstral 1.5, released by Mistral AI under the Apache 2.0 license, shifts that reality. It is a Lean 4 code agent that saturates the miniF2F benchmark, solves 587 out of 672 PutnamBench problems and, more importantly, uncovers previously unreported bugs in real open-source repositories. That combination of mathematical strength and practical utility is what makes this release worth a closer look.
What Leanstral 1.5 actually is
Leanstral 1.5 is a code agent model purpose-built for Lean 4, the proof assistant used to express everything from perfectoid spaces to specifications of Rust fragments. It belongs to the Mistral Small 4 family and updates the earlier Leanstral-2603 release.
Under the hood it uses a mixture-of-experts architecture with 128 experts, of which 4 are active per token. Total capacity sits at 119B parameters, with only 6.5B activated on any given token. Context length reaches 256k tokens, and the model accepts both text and image input while producing text output. The recommended working context is up to 200k tokens, which matters for the long agentic sessions the model was designed for.
Two reasoning modes are exposed. Setting reasoning effort to none gives fast responses for lightweight tasks, while high engages full reasoning for complex proof engineering. Weights are on Hugging Face, a free API endpoint named leanstral-1-5 is live, and self-hosting through vLLM 0.24.0 or newer is supported.
How Mistral trained the model
Training happened in three stages: mid-training, supervised fine-tuning, and reinforcement learning with CISPO. The reinforcement learning phase used two environments that shaped the agentic behaviour the model is known for.
In the multiturn environment, the model receives a theorem statement and must prove or disprove it. It submits a proof, reads Lean compiler feedback, and refines its attempt until it either succeeds or exhausts its budget. The loop mirrors how a human proof engineer works with the compiler.
In the code agent environment, Leanstral operates inside a raw filesystem. It edits files, runs bash commands, and queries the Lean language server for goals, errors and type information in real time. That lets it complete partial proofs in a repository, build auxiliary lemmas and persist through context compaction, where earlier context is compressed so long tasks continue to fit the window. Correctness is verified by Mistral’s fork of SafeVerify against a list of target theorems.
Benchmark results that shift the frontier
Leanstral 1.5 saturates miniF2F, hitting 100% on both validation and test sets. miniF2F is a cross-system benchmark for formal mathematics covering elementary problems up to IMO-level challenges in algebra, combinatorics and number theory. A perfect score there closes a chapter that has occupied the field for years.
On PutnamBench, a suite of 672 Putnam Mathematical Competition problems demanding deep reasoning and long proof chains, Leanstral solves 587. That edges out Seed-Prover 1.5 in its high setting by 7 problems while costing roughly $4 per problem, against an estimated $300 or more for Seed-Prover, which runs a budget of 10 H20-days per problem. For reference, Aleph Prover sits around $54 to $68 per problem.
The FATE benchmarks target graduate and PhD-level abstract algebra, covering group theory, ring theory and module theory. Leanstral sets a new state of the art with 87% on FATE-H and 34% on FATE-X, compared against Goedel-Architect without natural-language guidance and AxProverBase.
On FLTEval, built from real pull requests to the Fermat’s Last Theorem repository, pass@1 climbs from 21.9 to 28.9 and pass@8 from 31.9 to 43.2. That pass@8 score surpasses Opus 4.6’s 39.6 at one-seventh the cost, while widening the gap with open-source models three to ten times larger.
Test-time scaling that actually keeps working
The defining behaviour of Leanstral 1.5 is how it handles longer thinking budgets. On PutnamBench Pass@8, raising the token budget per attempt produces a smooth, monotonic climb: 44 problems solved at 50k tokens, 244 at 200k, 493 at 1M and 587 at 4M. Instead of stalling when a proof runs long, the model keeps reasoning, editing files and revising strategy across millions of tokens.
That behaviour is not just a benchmark curiosity. The AVL-tree proof described below ran for over 2.7 million tokens across 22 context compactions, and Leanstral held its reasoning together throughout.
From mathematics to real code verification
Although Leanstral was trained primarily on mathematics, it transfers surprisingly well to software verification. Mistral documents two case studies that make the point concrete.
Proving AVL tree time complexity
AVL trees are self-balancing binary search trees that maintain O(log n) height through rebalancing on insertions and deletions. Leanstral proved those time complexity guarantees for a real implementation. The task required structural induction mirroring the recursive tree structure, careful handling of monadic time tracking through the TimeM monad and exhaustive case analysis for every rebalancing path.
Over 2.7 million tokens and 22 compactions, the model systematically unfolded each layer of the TimeM monad, exposed the underlying computations despite their interleaving with control flow, and established a tight bound of roughly 48 steps per height unit plus a constant for insertion. It then connected height to tree size through a logarithmic relationship, delivering verified proofs that insertion and deletion are genuinely O(log n).
Finding hidden bugs in Rust code
To probe bug-catching ability, Mistral built an automated pipeline. Aeneas translates Rust code into Lean, then Leanstral infers user intent and generates correctness properties directly from the code. Each property gets four attempts at a proof. If those all fail, Leanstral tries to prove the negation with four more attempts.
Across 57 tested repositories, the pipeline flagged 47 violated properties, of which 11 pointed to genuine bugs. Five of those had never been reported on GitHub. One example lived in the sign function for zigzag decoding inside the datrs/varinteger library: on input Std.U64.MAX, the expression (value + 1) overflowed, causing crashes in debug mode and silent corruption in release. That is exactly the kind of edge case testing and fuzzing typically miss.
Getting Leanstral working in your project
The smoothest path is Mistral Vibe, Mistral’s agent CLI. Sign in at the Mistral chat interface on the free plan, opt into Labs models in privacy settings, and generate an API key. After installing the Vibe CLI, run the /leanstall command inside Vibe to add the Lean agent, then launch it with vibe –agent lean. Running Vibe inside a VS Code terminal, positioned in your Lean project directory, gives you both the agent and your code in view.
For tighter integration with Lean itself, the lean-lsp-mcp server is worth adding. It gives the agent standardised access to the language server, which pays off on long-running proof tasks.
Self-hosting works through vLLM 0.24.0 or newer, with a matching mistral_common install. Point the OpenAI-compatible client at your server, set reasoning_effort to high for hard proofs or none for quick edits, and use OpenAI-style tool calling to expose helpers like a lean_run_code function that compiles snippets on demand.
Why this matters beyond the benchmarks
Saturated benchmarks and eye-catching cost comparisons are easy to read as another leaderboard update. The more interesting shift is quieter: an open-source model, freely licensed, now catches real bugs in production Rust code and proves complexity bounds for data structures that people actually ship. Formal methods used to be a luxury reserved for compilers, cryptography and safety-critical systems. When the tooling costs a few dollars per proof and runs from a terminal, the calculus for adding verification to ordinary projects changes. The question is no longer whether formal verification is feasible outside academia, but which parts of your codebase deserve it first.
