Mistral launches Leanstral 1.5: 6.5B active parameters tackle Lean 4 proofs

On June 30, Mistral quietly updated Leanstral to version 1.5. The release pace remains distinctly European—no launch event, no hype, just a blog post, a model card, and a push to the playground. Done.

This is the first major update since the initial Leanstral release in March. The positioning remains unchanged: a code agent model designed solely for writing formal proofs in Lean 4. It has 119B total parameters, 6.5B active parameters, and a sparse MoE architecture. It runs lighter than a 7B dense model but takes on tasks suited for mathematicians and verification engineers.

Let’s start with what actually changed in this update

To be frank, Mistral was quite restrained in revealing details this time. The model card doesn’t include new benchmark scores, nor does it clarify specific improvements over the March version. What we can confirm so far:

• Architectural parameters are unchanged — 119B total parameters, 6.5B active;
• Continued optimization for Lean 4’s two core tasks: Automated Theorem Proving (ATP) and autoformalization;
• Available for free trial on the Mistral AI playground;
• Weight release policy not yet announced; the March version used Apache 2.0, but whether 1.5 will follow suit remains to be seen.

So, to be precise, this is an iteration of retraining and fine‑tuning under an unchanged architecture, not a compute‑doubling major version. Mistral’s own blog titles it “Proof Abundance for All,” roughly meaning: make formal proofs affordable, adequate, and no longer an academic luxury.

That positioning is key. We’ll come back to it later.

Why a “proof‑focused” model deserves attention

Let’s fill in some background. Lean 4 is a programming language developed by Microsoft Research and the Leibniz Center for writing formal mathematical proofs and verifying program correctness. Unlike typical programming languages, every line of Lean 4 code is not just “runnable” but machine‑verified line by line to be logically airtight.

Sounds cool—but anyone who’s used it knows the pain: it’s extremely hard to write. A math PhD student may spend a week proving a lemma from an undergraduate textbook. For developers wanting to verify their own functions with Lean, each invariant and boundary condition must be manually fed into the prover.

That’s why the AI field has been pouring resources into this direction recently. DeepMind has AlphaProof, OpenAI has internal projects, and in China, both Kimi and Zhipu are working on mathematical‑proof models. The logic is straightforward: an AI capable of automatically proving mathematical theorems can likely also prove code correctness.

In domains like financial settlement, aerospace embedded systems, and cryptographic libraries—where one bug can be catastrophic—this is essential.

When Mistral entered the space with Leanstral in March, they took this idea to the extreme: treat “formal proof” as an independent model capability rather than a side task of a general model.

Sparse architecture + specialization: cost that undercuts Claude

For performance, we have comparison data from the March version. Mistral hasn’t rerun benchmarks for 1.5, but since the architecture is unchanged, previous results still hold as reference.

On mainstream Lean 4 benchmarks like miniF2F and ProofNet, Leanstral’s pass@2 is 26.3, outperforming Claude Sonnet 4.6’s 23.7 by 2.6 points. That may not sound huge, but the cost difference is staggering:

| Model | pass@2 | Cost per benchmark run | |--------|--------|-----------------------| | Leanstral | 26.3 | $36 | | Claude Sonnet 4.6 | 23.7 | $549 | | Claude Opus 4.6 | Higher | More expensive |

For one proof task, Leanstral costs only one‑fifteenth of Sonnet.

Why so cheap? Half of it is the sparse MoE design—only 6.5B active parameters, so the inference compute path is small. The other half is specialization—general models need costly detours to handle Lean, while Leanstral was trained entirely on Lean 4 corpora and proof traces, incurring zero cognitive tax.

Even the open‑source camp has difficulty keeping up. Qwen3.5 397B‑A17B, Kimi‑K2.5 1T‑A32B, and GLM5 744B‑A40B are all heavyweights with tens of billions of active parameters, yet a 6.5B active specialized model beats them on general Lean tasks. This shows that specialized models can still outperform general large models in vertical domains—at least within this cost range.

That aligns with Mistral’s long‑standing product philosophy: don’t chase SOTA, chase Pareto. If you want the best, use Opus; if you want “good enough” and cheap, use Mistral.

“Self‑verifying code” is not a marketing slogan—it’s a real need

Let’s talk technical details. How is Leanstral used in practice?

Simply put, there are two modes:

1. Automated Theorem Proving (ATP). You write a mathematical proposition, e.g. “for any natural number n, n + 0 = n,” and the model auto‑generates the corresponding Lean 4 proof script. It’s useful in math libraries (like mathlib4), education, and research.

2. Autoformalization. You describe specifications in natural language or Python/Rust code—say, “this sorting function returns an ordered list with the same elements”—and the model translates that into a Lean 4 formal specification, then generates the proof.

This second mode has real industrial value. For example:

-- A simplified IMP language semantic rule
E_Seq (c1 c2 : com) (st st' st'' : state) 
      (h1 : ceval c1 st st') 
      (h2 : ceval c2 st' st'') :
      ceval (CSeq c1 c2) st st''

A mid‑sized compiler may have hundreds of such rules, each requiring proof of certain invariants. Manually writing them takes months; with models like Leanstral, the cycle can drop to days.

Zooming out—the promise of vibe coding or fully automated AI code generation runs into one bottleneck: “Would you trust AI‑written code in production?” Would a bank let Claude directly modify core ledgers? Would aerospace engineers flash GPT‑generated C code to a controller? The answer is almost always no.

But if every AI‑written function comes with a Lean 4 proof verifying it meets its declared specification, that changes everything. Mistral’s blog calls this “trustworthy vibe coding”—a slightly awkward phrase, but the meaning is clear enough.

There are some caveats

After the praise, some reality checks.

First, Leanstral 1.5’s transparency is too low. No new benchmarks, no comparison charts, no word on when weights will drop. Over the past two years, Mistral has been pulling back on openness—Medium 3.5 and Voxtral TTS are no longer fully open source. The first Leanstral was Apache 2.0, but whether 1.5 continues that is unconfirmed. The open‑source community is already asking on Hugging Face discussions.

Second, the overall Lean 4 ecosystem is still small. Worldwide, probably fewer than 10,000 people can fluently write proofs in Lean 4. Even if the model is cheap, without a user base, commercialization hits a ceiling. Mistral’s bet here is on the future, not the present.

Third, what does a pass@2 of 26.3 mean? It means with two tries, the success rate is just over 25%. Better than Sonnet, but far from ready to replace humans. For deployment in finance or core infrastructure, that rate needs to double at least. Mistral’s chosen wording “Proof Abundance” is deliberate—they aim to make proofs plentiful and cheap, not necessarily correct. The nuance is intentional.

What this means for developers

If you work in formal verification, math‑library development, or compiler‑correctness proofs, Leanstral 1.5 is worth a trial. The playground is free—run some tactic generations on your Lean 4 projects and see how it does.

If you build general AI coding tools (like IDE plugins or Copilot‑style agents), watch whether Leanstral gets integrated into mainstream Lean 4 toolchains. The March version already had community‑made VS Code plugin support; 1.5 will likely follow soon.

If you’re an ordinary software developer—no immediate impact, but remember this: AI‑generated code is starting to prove itself correct. Once that pipeline matures, the industry’s trust threshold for AI programming will reset.

A final observation: model‑release rhythms have stratified. One layer is the big all‑rounders—Opus, GPT, Gemini—competing on general intelligence. The other is specialized small models like Leanstral, competing on cost and peak vertical efficiency. Mistral clearly chose the latter as a differentiation path. In an era where generic model intelligence is oversupplied, that may not be defensive—it might be a strategic positioning.

Competing on IQ with a sparse‑MoE 119B model is meaningless; what matters is how much cheaper and more accurate it is at your one specific need.

References

• Hugging Face – Official Mistral model repository – main release hub for Mistral open‑source model weights; Leanstral model cards are mirrored here
• GitHub – leanprover/lean4 – official Lean 4 language repo; essential for understanding Leanstral’s application context
• GitHub – leanprover‑community/mathlib4 – Lean 4 math library, key training and evaluation corpus for Leanstral
• Zhihu – Discussions on formal verification and AI – Chinese discussions on Lean and formal‑proof topics