Quick Answer
Use Leanstral 1.5 as a compiler-in-the-loop proof engineer, not as a source of proof-shaped text.
A reliable first workflow is:
- pin the repository commit, Lean version, mathlib or other dependency versions, and build command;
- define one theorem, file boundary, allowed assumptions, and acceptance test;
- verify the current Mistral model identifier with a minimal request;
- give the agent read access first and require a plan before edits;
- let it use the Lean compiler and language server for iterative feedback;
- reject changed statements, new axioms, unsafe shortcuts, admitted results, and unrelated edits;
- compile and test from a clean environment;
- obtain human proof-engineering review before merge.
Mistral announced Leanstral 1.5 on July 2, 2026 with Apache-2.0 weights and a free API endpoint. The current Leanstral model record explains an important source difference: the release names leanstral-1-5, while the model card checked July 30 names labs-leanstral-1-5.
Do not infer Flowith availability from Mistral access.
Decide Whether Leanstral Fits the Task
Leanstral 1.5 is designed for:
- Lean 4 theorem proving;
- autoformalizing a natural-language statement;
- completing partial proofs;
- building helper lemmas;
- debugging compiler and type errors;
- navigating a Lean repository;
- investigating whether a stated property can be proved or disproved;
- formal verification work connected to real code.
It is not proof that:
- the original theorem captures the user’s intent;
- all assumptions are acceptable;
- a compiled statement is meaningful;
- a repository change is safe to merge;
- translated source code preserves the original program semantics;
- a benchmark result predicts the cost or success of a new project.
If the task is ordinary code generation without Lean, use a general coding model and keep formal verification as a separate workstream.
Reconcile the Current Access Record
Mistral’s first-party sources do not currently use one identical record.
Release Post
The July 2 release says:
- 119B total and 6B active parameters;
- Apache 2.0;
- downloadable weights;
- a free API endpoint named
leanstral-1-5; - Mistral Vibe as the recommended agent surface.
Current Model Card
The model card checked July 30 says:
- Public Preview;
- 119B total and 6.5B active parameters;
labs-leanstral-1-5;- 256k context;
- 128k maximum output;
- $0 displayed price;
- chat completions, function calling, agents and conversations, and structured outputs.
Treat the model card as the current API catalog record, but do not silently rewrite the release. Before implementation:
- list or inspect the live model catalog;
- confirm the alias available to the account;
- send a minimal request;
- record the response model identifier;
- check quotas, data treatment, preview terms, regions, and rate limits;
- keep the model name configurable for future migration.
The $0 preview display is not a permanent pricing guarantee.
Prepare a Bounded Proof Brief
Give the model a machine-checkable task record.
Environment
Record:
- repository URL and commit;
- Lean version;
- Lake version;
- mathlib or project dependency lock;
- operating system and toolchain;
- build and test commands;
- network policy;
- available compiler and language-server tools.
Target
Record:
- exact theorem name;
- current statement;
- expected proof style;
- allowed helper lemmas;
- files that may change;
- files that must not change;
- whether counterexamples or disproval are acceptable;
- token, time, and cost ceilings.
Prohibited Shortcuts
Explicitly reject:
sorry;admit;- new axioms;
- unsafe declarations;
- weakening the theorem;
- strengthening assumptions without approval;
- disabling checks;
- changing dependencies;
- editing generated or unrelated files;
- hiding failures in scripts.
The exact prohibited patterns depend on the repository. Turn them into automated checks where possible.
Run a Compiler-in-the-Loop Workflow
1. Diagnose Before Editing
Ask Leanstral to:
- restate the theorem;
- list relevant imports and definitions;
- inspect nearby lemmas;
- identify missing facts;
- propose a small proof plan;
- name likely failure points.
Do not grant broad write or shell permissions merely because the plan looks plausible.
2. Make the Smallest Change
Allow one file or one theorem first. Require a diff after each meaningful step.
Preserve:
- theorem name and statement;
- namespace;
- visibility;
- imports;
- existing public API;
- project style.
3. Feed Back Real Errors
The model should act on:
- compiler errors;
- unsolved goals;
- inferred types;
- language-server information;
- test failures;
- linter output.
Do not replace real tool output with a paraphrased error if exact spans and terms are available.
4. Check the Proof Boundary
Before accepting a compile:
- compare theorem statements before and after;
- search for admitted or unsafe constructs;
- inspect new axioms and imports;
- review changed definitions;
- check dependency files;
- review all shell commands and generated files;
- confirm no test or linter was disabled.
Compilation proves the accepted statement under the active environment. It does not prove that the statement is the right specification.
5. Reproduce Cleanly
Use a clean checkout or isolated build environment:
- apply only the reviewed diff;
- restore the pinned toolchain and dependencies;
- build the target;
- run repository tests and linters;
- run any proof-specific verifier;
- capture logs and the final commit;
- have a qualified reviewer approve the result.
Evaluate the Model on Your Repository
Start with a representative suite rather than a single impressive theorem.
Measure:
- proof completion rate;
- compiler-valid rate;
- human-accepted rate;
- statement-change rate;
- unsafe-shortcut rate;
- attempts and tokens per accepted proof;
- wall-clock time;
- tool-call failures;
- unrelated-diff rate;
- clean-reproduction rate.
Include:
- small local lemmas;
- a dependency-sensitive proof;
- a long-horizon task;
- a task that should be disproved;
- an ambiguous specification;
- a known failure case.
Mistral publishes strong results on miniF2F, PutnamBench, FATE-H/X, and FLTEval. Those results use specific budgets, comparison conditions, and verification setups. Attribute them to Mistral and do not convert them into an expected success rate for a private repository.
Permissions, Data, and Secrets
Formal methods repositories may contain proprietary specifications, security properties, unpublished research, or sensitive source code.
Before using an API:
- review current Mistral data and retention terms;
- classify the repository;
- remove secrets and credentials;
- restrict network and filesystem access;
- use least-privilege tokens;
- log tool activity;
- prevent unapproved publishing or package release;
- keep a human approval gate for external actions.
For self-deployed weights, the license does not replace infrastructure, model, dependency, telemetry, and security review.
Failure Modes and Recovery
The Proof Compiles After the Statement Changed
Restore the approved statement and add an automated statement fingerprint or targeted diff check.
The Model Adds an Assumption
Treat the proof as rejected until the assumption is independently justified and explicitly approved.
The Task Loops
Stop at the budget ceiling. Save the smallest error-producing state, review missing lemmas, and split the target.
The API Alias Fails
Query the live Mistral catalog. Test labs-leanstral-1-5 as the current checked model-card alias, but do not assume an account has access.
A Clean Build Fails
The result is not reproducible. Compare toolchain, lockfiles, environment variables, generated files, and uncommitted state before continuing.
Official Sources
- Mistral’s Leanstral 1.5 release for training, evaluation, license, weights, release-time API wording, and setup.
- Mistral’s current Leanstral 1.5 model card for current preview status, alias, context, output, displayed price, and features.
- LeanstralSafeVerify for the verifier fork linked by Mistral.
- Lean 4 for the proof assistant and official project resources.
Checked July 30, 2026. Recheck API, price, quota, terms, model alias, and preview status before implementation.
Frequently Asked Questions
How should I start a Leanstral 1.5 proof task?
Pin the repository, Lean and dependency versions, state one proof target, define allowed files and assumptions, then begin with a bounded diagnostic task before allowing edits.
Which Leanstral 1.5 API model ID is current?
Mistral’s July 2 release names leanstral-1-5, while the model card checked July 30 lists labs-leanstral-1-5. Query the live catalog and run a minimal request before configuring a workload.
Is compiled Leanstral output automatically safe to merge?
No. Compilation is necessary but not sufficient. Review theorem changes, axioms, unsafe declarations, dependencies, generated files, permissions, tests, and the complete diff before approval.
Can I use Leanstral 1.5 in Flowith?
Mistral’s API and weights do not establish a Flowith mapping. Verify the live Flowith selector independently before describing that access.