.png)
Mistral AI has released Leanstral 1.5, a free Apache-2.0 licensed model for formal verification and proof engineering in Lean 4. The update pushes performance hard on theorem proving benchmarks, while staying open-source and practical enough to use in real code verification workflows.
Leanstral 1.5 is a Mixture-of-Experts model with 119B total parameters and 6.5B active parameters per token, plus a 256k context window. That combination matters because the release is not just about benchmark chasing; it is trying to make long-horizon proof search and code-level verification feasible without locking the model behind a closed API.
Mistral positions it as an updated Lean 4 formal proof engineering model optimized for automated theorem proving and autoformalization. If your stack already uses Lean for verification or proof search, this is a model worth evaluating directly against your current prover-assisted pipeline, especially on long-context theorem states, multi-step proof repair, and code-property verification.
The headline numbers are strong:
Those results are meaningful because formal verification benchmarks tend to punish superficial reasoning shortcuts. Saturating miniF2F suggests the model is hitting the ceiling on a smaller, well-trodden benchmark, while PutnamBench and the FATE suites better probe search depth, robustness, and transfer to harder proof tasks.
The important question for production use is not whether the model tops a chart, but whether it improves end-to-end success rates in your own proof search loop. For teams already doing Lean 4 autoformalization or proof repair, this release is the kind that should be measured on compilation success, proof length, retry budget, and failure recovery rather than raw log-prob perplexity.
Leanstral 1.5 is trained in three stages: mid-training, supervised fine-tuning, and reinforcement learning with CISPO, or Clipped Importance Sampling Policy Optimization. The RL setup is built around two environments that map closely to how proof engineering actually behaves in practice.
In the multiturn environment, the model gets a theorem statement, emits a proof attempt, receives Lean compiler feedback, and iterates until the proof compiles or the budget runs out. That setup is useful because it closes the loop around the actual verifier instead of optimizing for static proof text.
In the code agent environment, the model behaves more like an engineer operating inside a filesystem: editing files, running checks, and using feedback from the tool loop to converge on a fix. Mistral says this helped Leanstral uncover 5 previously unknown bugs across 57 open-source repositories tested, which is the most convincing signal in the release because it points to real verification utility rather than benchmark-only specialization.
CISPO itself is a sensible choice for this kind of training regime because the task is both sparse-reward and feedback-heavy. For proof search systems, RL methods that remain stable under noisy compiler feedback and long-horizon credit assignment tend to matter more than the exact algorithm label, and the release suggests that Mistral is optimizing for that stability.
Leanstral 1.5 is fully open-sourced and available through Hugging Face and a free API. The Apache-2.0 license is the other big operational detail: it removes a lot of the deployment and redistribution friction that usually slows adoption of high-performing verification models.
For ML engineers, the immediate use cases are straightforward:
The model card also matters because the released parameters are not tiny in absolute terms. A 119B MoE model with 6.5B active parameters is still a serious serving and latency planning problem, even if the per-token compute is much lighter than dense models of comparable total size. In other words, this is open and practical in the licensing sense, but not small in the infra sense.
If your team works on formal methods, this is one of the rare model releases that is easy to justify as an engineering evaluation target: strong benchmark numbers, tool-using behavior, real repository findings, and a permissive license. The main thing left to test is how well it holds up on your own theorem corpus, your own proof styles, and your own compiler-feedback loop.
