Mistral AI deprecated Leanstral 1.5 on September 29 and scheduled the hosted model for retirement on September 30, according to its model documentation and changelog. For teams that put the specialized Lean 4 model inside proof-generating agents, that one-day transition from deprecation to retirement is more than a version update. It is a reminder that model lifecycle events can become immediate production incidents when an agent depends on a specific model’s reasoning, tool use, and output behavior.
Leanstral 1.5 was released on June 30 as a model for formal proof engineering, automated theorem proving, and autoformalization. Mistral lists 119 billion total parameters with 6.5 billion active, a 256,000-token context window, a 128,000-token maximum output, and support for chat completions, function calling, structured output, and its Agents and Conversations APIs. Three months later, the hosted API identifier labs-leanstral-1-5 is being phased out.
The operational lesson reaches well beyond theorem proving: agent platforms must treat model retirement as a controlled dependency migration, not a configuration edit. A model replacement can change planning, tool arguments, output schemas, latency, refusal patterns, and the proof or code artifacts an agent produces. The correct response is a lifecycle playbook built around inventory, replayable evaluations, pinned identifiers, and a tested rollback path.
Why this retirement is unusually instructive
Leanstral is not a generic chat model. Its purpose is to work with Lean 4, a proof assistant used to express mathematical statements and mechanically check proofs. That makes the model a component in a larger verification loop: it proposes formalizations or proof steps, Lean checks them, and an agent reacts to compiler or prover feedback. The system’s value comes from the interaction between the model and the verifier, not from plausible prose alone.
This architecture has an advantage during migration because Lean provides a deterministic acceptance signal. A proof either checks under the selected environment or it does not. But deterministic verification does not eliminate migration risk. A replacement may take longer, consume more context, select different tactics, emit malformed structured output, call tools differently, or fail on the project-specific theorems that matter most.
The short deprecation window also exposes a common weakness in AI operations. Many teams monitor application code, packages, cloud services, and certificates, but model catalogs are still reviewed manually. A retirement notice may sit on a documentation page until requests begin failing. Experimental models are particularly vulnerable to short lifecycles, yet experiments often become quiet production dependencies when a prototype proves useful.
First, find every place the model can hide
A reliable migration begins with a dependency inventory. Searching a primary repository for labs-leanstral-1-5 is necessary, but it is not sufficient. Model identifiers can live in workflow builders, feature-flag services, notebooks, evaluation harnesses, environment-specific configuration, customer-specific routing tables, and scheduled jobs. They may also be selected indirectly through an alias or a gateway policy.
Teams should trace the dependency across four layers:
- Invocation: every API client, agent graph, batch job, and human-facing tool that can request the model.
- Routing: aliases, fallbacks, provider gateways, regional endpoints, and tenant-specific overrides.
- Behavioral contracts: prompts, tool schemas, structured-output definitions, stop conditions, and retry logic tuned to the model.
- Downstream artifacts: proof files, generated code, cached responses, audit records, and derived datasets that record or assume a model version.
The inventory should name an owner for each workflow and distinguish production, evaluation, and abandoned experiments. It should also record whether a failure is visible. A user-triggered request may surface an error immediately; a nightly proof-maintenance job can fail silently for days if its alert only watches process completion rather than accepted artifacts.
Do not substitute a model before defining equivalence
When a provider retires a model, the tempting response is to replace the identifier with the recommended successor and redeploy. That treats models like binary-compatible libraries. They are not. Even when two models expose the same API, their behavior is statistical and their preferred interaction patterns can differ.
Before choosing a successor, define what equivalence means for the workload. For a Lean proof agent, the primary measure should be the share of tasks that produce a proof accepted by the pinned Lean toolchain. Secondary measures might include time to acceptance, number of prover iterations, generated file size, tactic stability, token consumption, and the rate of changes outside the requested theorem.
A production-shaped test set should include more than a public benchmark. Build it from recent successful jobs, known failures, long-context projects, unusual imports, ambiguous natural-language statements, and adversarial instructions embedded in repository content. Remove sensitive data as required, but preserve the structure that makes the task difficult. A migration that passes simple theorem completion and fails on repository-scale dependency resolution is not equivalent.
The test harness should pin everything it can: the Lean version, packages, tool permissions, prompt template, temperature and sampling controls, and the model identifier. Run the incumbent and candidate under the same limits. Because model outputs vary, repeat representative cases and report distributions rather than a single pass.
Measure the whole agent loop
Accuracy alone can hide operational regressions. Agentic workloads accumulate costs and risks across repeated model and tool interactions. A candidate that proves the same number of theorems but requires twice as many compiler cycles may overload shared workers. Another may be faster but produce more expansive edits that increase review time.
A useful migration scorecard includes:
- Verified completion rate and first-attempt completion rate
- Model calls, tool calls, and prover/compiler iterations per accepted task
- Input, output, and cached tokens per accepted task
- Median and tail latency for the complete run
- Malformed tool arguments and structured-output violations
- Human review minutes and the rate of manual repair
- Unauthorized file changes, network attempts, or scope expansion
The denominator matters: measure resources per accepted proof or completed job, not per request. A superficially cheaper model can become more expensive when retries and human correction are included. Conversely, a more expensive model may lower the total cost if it reaches a verified result in fewer loops.
Put the replacement behind a routing boundary
Direct model names scattered throughout application code make every retirement harder. A small routing layer gives operators one place to map workload classes to pinned model versions, enforce budgets, and collect comparable traces. The application can request a capability such as formal-proof-agent; the router can resolve that capability to an approved model and configuration.
That abstraction should not hide the resolved version. Every trace and artifact should record the actual provider, model ID, prompt version, toolchain version, and routing rule. Otherwise, an alias change can alter behavior without leaving enough evidence to reproduce an incident.
Fallbacks need the same care. Automatically sending a failed proof task to a generic model may preserve API availability while degrading correctness, privacy, or cost. A fallback is safe only if it has passed the workload’s acceptance tests and supports the required context, structured output, and tool behavior. If no validated replacement exists, failing closed with a clear operational alert may be safer than producing unchecked work.
Migrate with shadow traffic and explicit gates
When time permits, replay recent inputs against the candidate without letting its actions affect production. Shadow evaluation reveals differences in plans and tool usage while the incumbent still serves the workflow. For formal proofs, candidate outputs can be checked in isolated environments and compared with the incumbent’s accepted artifacts.
A controlled rollout can then advance through small cohorts. Start with internal or low-impact jobs, compare acceptance and cost, and expand only when predefined thresholds hold. For agents that modify repositories, keep execution sandboxed and require review until the candidate has demonstrated stable behavior. Maintain a rapid routing rollback, but remember that a retiring upstream model may soon make rollback impossible. The durable rollback may be a self-hosted checkpoint, a second validated provider, or a queue that pauses work safely.
With a one-day retirement window, a full staged rollout may not be possible. The incident response should then prioritize safety: disable unvalidated autonomous execution, preserve queued inputs, switch to a tested fallback if one exists, and communicate degraded capability. Urgency is not a reason to remove verification gates.
Build lifecycle monitoring before the next notice
The immediate fix for Leanstral 1.5 is workflow-specific. The durable fix is automated lifecycle intelligence. Teams should ingest provider changelogs and model catalogs, compare them daily, and raise an owned ticket when a used identifier changes status. Alerts should include the affected services, last invocation, volume, responsible team, stated replacement, deprecation date, and retirement date.
Set internal lead-time objectives. For example, a production workflow might require a migration plan within two business days of deprecation and a validated successor before a provider’s final retirement window. Experimental or “labs” models should carry stricter controls: explicit expiry dates, lower blast radius, and a preselected escape path.
Model selection records should also capture lifecycle maturity. Capability and price are only part of the decision. A slightly weaker but stable model can be the better production choice when the workflow is expensive to requalify. Specialized preview models may still be valuable, but teams should price migration work into the experiment from the start.
The practical takeaway
Leanstral 1.5’s rapid move from release to deprecation and retirement makes model lifecycle management concrete. Agentic systems bind to behavior as well as an endpoint, so replacements must be evaluated at the level of verified tasks, tool interactions, and downstream artifacts.
The playbook is straightforward: inventory every invocation and routing path, define acceptance before selecting a replacement, replay production-shaped tasks, measure the complete loop, deploy behind a version-aware router, and monitor provider lifecycle data continuously. Teams that establish those controls can use specialized models without allowing a catalog change to become an uncontrolled outage.
