MiniMax M2.5: A Strong Coding Model With a Retirement Date

MiniMax M2.5 is a model you might still be running in production, and the most useful thing to know about it in October 2026 is not a benchmark. It is a date. MiniMax's model overview now lists M2.5 as legacy and says the M2.5 and M2.7 families stop being available to new users on 19 October 2026 and are retired on its API on 18 November 2026.

That does not make M2.5 a bad model. It was a strong one when it shipped, and its weights are still published. But a guide written today has to answer two questions at once: what M2.5 is good at, and what to do when the first-party endpoint goes away.

What MiniMax claimed in February

MiniMax released M2.5 on 12 February 2026 and pitched it at "real-world productivity": coding across many languages, agentic tool use and search, and office work in documents, slides and spreadsheets. The headline numbers, all vendor-reported:

• SWE-bench Verified — 80.2%, run with Claude Code as the scaffold
• SWE-bench Verified on other scaffolds — 79.7% on Droid, 76.1% on OpenCode
• Multi-SWE-Bench — 51.3%
• BrowseComp — 76.3%, with context management

The scaffold spread is the detail worth keeping. The same weights moved by four points depending on which agent harness drove them. That is a useful reminder that a SWE-bench figure describes a model plus a harness, not a model alone. Before comparing M2.5 against anything else, check that both numbers came from the same harness.

The Hugging Face card lists the model at roughly 229B parameters in a mixture-of-experts design, under what MiniMax labels a modified MIT licence. The release post itself does not restate the active-parameter count, so treat any single figure you see on aggregator sites with some caution.

The efficiency numbers are the interesting part

More revealing than the scores is what MiniMax said about cost and time against its own predecessor, M2.1. On SWE-bench Verified the average end-to-end runtime per task fell from 31.3 minutes to 22.8, which MiniMax describes as 37% faster. Tokens consumed per task fell from 3.72M to 3.52M. On search-heavy agent tasks it reported roughly 20% fewer rounds.

Those are the numbers that predict a bill. An agent that reaches the same answer in fewer rounds spends less on re-sent context, and in a long loop input tokens dominate cost. Fewer turns usually matters more than a cheaper per-token rate.

MiniMax also shipped a Lightning variant served at a steady 100 tokens per second, priced at $0.30 per million input tokens and $2.40 per million output, with the standard M2.5 endpoint at half that rate. OpenRouter listed M2.5 at $0.27 input and $0.95 output per million tokens at the time of writing, with a 204,800-token context and up to 32,768 output tokens. Prices on third-party routes move, so check before you budget.

The retirement notice changes the calculation

Here is what MiniMax's documentation says, and what it does not.

• From 19 October 2026, M2.5 and M2.7 are no longer available to new users of the MiniMax API.
• Existing pay-as-you-go users keep access until 18 November 2026. After that, requests to these models stop working.
• On MiniMax's subscription plans, requests to M2.5 and M2.7 are routed automatically to M3.1 Flash Preview from 19 October, with the old model names still accepted.

That last point deserves attention. If you are on a plan, your code will keep calling a model named M2.5 while a different model answers. Nothing will error. Your outputs will simply change, and any eval you ran last month stops describing what you are getting.

The notice covers MiniMax's own API. It says nothing about third-party hosts serving the open weights, and those decide their own schedules. If you reach M2.5 through a router, check that provider's deprecation page rather than assuming either outcome.

Open weights are the exit route

Because the weights are published, M2.5 does not disappear when the first-party endpoint does. You can keep running it on your own hardware or through any host that serves it. Whether that is worth doing depends on why you chose it.

If you picked M2.5 because it was cheap and good at coding, there are newer options in the same family. MiniMax M3 is the current flagship with a 1M context and native multimodality, covered in the MiniMax M3 guide. If you picked it because a specific prompt set or fine-tune is tuned to its behaviour, self-hosting keeps that behaviour frozen, at the cost of running a model with roughly 229B weights in memory.

Read the licence before planning a self-hosted deployment. "Modified MIT" means the base terms are MIT with additions, and additions are exactly where commercial surprises live. Open-weight model licences compared covers what to look for.

Moving off M2.5 without a regression

The migration risk is not that the replacement is worse on average. It is that it is different on your specific tasks, and you do not find out until something ships. A short procedure:

1. Before 18 November, capture twenty real tasks with their M2.5 outputs as a baseline.
2. Run the same tasks through each candidate on the same harness. Record pass rate, turns to completion and total tokens.
3. Check tool-call formatting separately. A model swap often breaks parsing before it breaks reasoning.
4. Pin the new model by an explicit name. Avoid any alias that can be re-pointed under you, which is precisely what the plan routing above does. Pinning model versions covers why.

How to benchmark LLMs on your own work has the harness setup. If two candidates come out close, keep both and route between them; that is cheaper insurance than betting on one.