MiniMax M2.5 Tested: Open Weights Coding on SWE-Bench Verified (2026)

MiniMax M2.5 is the open weight coding model that forced the closed frontier to justify its price. It is a 230B mixture of experts that activates only 10B parameters per token, and on SWE-Bench Verified it posts 80.2 percent, which sits 0.6 points behind Claude Opus 4.6 at 80.8 percent. The weights are published on Hugging Face, and hosted inference runs around fifteen cents per million tokens. When a model you can download and self host lands within a rounding error of a flagship on the coding benchmark everyone quotes, at roughly a tenth of the token cost, the interesting question stops being "is it good" and becomes "what does the closed option still buy me."

Attribute	MiniMax M2.5	Typical closed frontier
Weights	open, on Hugging Face	closed, API only
Architecture	230B MoE, 10B active	undisclosed
SWE-Bench Verified	80.2 percent	low 80s
Multi-SWE-Bench	51.3 percent, first place	varies
BrowseComp	76.3 percent	varies
Hosted token cost	roughly 15 cents per 1M	often 10x higher
Self host	yes, if you have the memory	no

Every number in that table is a real published figure, not an estimate attributed to a customer. The comparison column is deliberately loose, because closed vendors move pricing and rarely disclose architecture, and the point is the shape of the trade rather than a single frozen matchup.

What the benchmarks actually say

The headline is SWE-Bench Verified at 80.2 percent. Verified is the 500 task human validated coding benchmark, and by 2026 the frontier clusters in the low 80s on it, so an open weight model at 80.2 is genuinely in the conversation rather than a distant follower. If you want the full story on why Verified compresses at the top and what a more discriminating benchmark shows, we covered that in why SWE-Bench Pro and Verified disagree; the short version is that a single Verified number near the top tells you the model is competent, not that it is best.

The result that impressed me more is Multi-SWE-Bench at 51.3 percent, first place on that board. Multi-SWE-Bench tests coding across several languages rather than Python alone, and topping it means M2.5 is not a single ecosystem specialist that happened to overfit Python issues. It also posts 76.3 percent on BrowseComp, which measures agentic web browsing and retrieval, so the model holds up on tool use and not just static code generation. Taken together, these are the numbers of a broadly capable coding model, which is unusual at open weights. For context on how other open weight contenders stack up on cost and reasoning, our Kimi K3 versus GPT-6 Astra open weights comparison walks the same trade from a different angle.

The 10B active design is the whole economic story

The architecture is where M2.5 earns its price. A 230B mixture of experts with 10B active means the model holds 230B parameters worth of learned capability but only runs 10B of them on any given token. Your compute per token tracks the active count, roughly 10B, while your memory footprint tracks the total, roughly 230B. That split is why hosted access can be so cheap: the provider pays for 10B of compute per token even though the model behaves like something much larger.

For self hosting, the same split is a constraint rather than a gift. You need enough memory to hold the full 230B in whatever quantization you run, which is not a single consumer GPU, but your throughput once loaded is closer to a 10B dense model than a 230B one. The practical read is that M2.5 is cheap to run per token and expensive to hold in memory. If you serve steady volume, that math favors you, because the memory is a fixed cost you amortize across a high request rate. If you serve spiky, low volume traffic, a hosted endpoint at fifteen cents per million tokens is almost always the better deal than standing up your own hardware. We walked a similar dense versus sparse serving decision in our Qwen3 Coder versus Claude Opus 4.8 on SWE-Bench piece.

Where an open weight model like this belongs

The strongest case for M2.5 is data control and unit economics at scale. If you are running coding agents over proprietary source that cannot leave your network, open weights are not a nice to have, they are the only option, and a model this capable makes that constraint far less painful than it was a year ago. If you are running high volume agentic workloads where token cost dominates your bill, the roughly tenfold price gap versus a closed flagship compounds fast, and a 0.6 point SWE-Bench difference is a rounding error next to a 90 percent cost reduction.

The case against it is honest too. If your volume is low, the operational cost of self hosting a 230B model, the memory, the serving stack, the on call, swamps any token savings, and you should just use a hosted endpoint or a closed API. If you need the last few points of reliability on the hardest tasks, the closed frontier still edges ahead on the benchmarks that separate the top, and for some production paths that margin is worth paying for. Open weights buy you control and cost, not a guarantee that you match the best closed model on every task.

One more caveat on freshness: the MiniMax line has continued to iterate since M2.5 shipped, so if you are standing up something new, check whether a later release in the series fits better. M2.5 remains the widely referenced open weight coding baseline because its numbers are strong and its weights are genuinely open, which is why the search demand and the build versus buy debate still center on it.

FAQ

Is MiniMax M2.5 actually open weight? Yes. MiniMax published the weights on Hugging Face, so you can download and self host the model, subject to the license terms on the model card. That is the core difference from a closed API only frontier model.

How does M2.5 compare to Claude Opus 4.6 on coding? On SWE-Bench Verified they are within 0.6 points, 80.2 for M2.5 against 80.8 for Opus 4.6. That is close enough that on most coding work the practical difference is small, and cost and data control become the deciding factors.

What does M2.5 cost to run? Hosted access runs around fifteen cents per million tokens, roughly a tenth of a typical closed flagship at volume. Self hosting shifts the cost to memory and operations, which only pays off at steady, high request rates.

What does 230B MoE with 10B active mean in practice? Compute per token tracks the 10B active parameters, so it is fast and cheap to run, while memory tracks the full 230B, so it is expensive to hold in RAM. Cheap per token, memory heavy to host.

Should I pick M2.5 over a closed model? Choose it when you need open weights for data control or when high volume makes token cost dominate. Stay with a closed API for low volume traffic or when you need the last points of reliability on the hardest tasks.

When this applies to your stack

The decision M2.5 forces is not "open versus closed" in the abstract, it is a unit economics question specific to your traffic. At high, steady volume with data that has to stay in your network, an open weight model within a point of the frontier at a tenth of the cost is a straightforward win, and the savings fund a lot of engineering. At low or spiky volume, the operational weight of hosting a 230B model erases the token savings, and a hosted endpoint or closed API is the disciplined choice. The mistake is picking on benchmark pride rather than on where your traffic and your data constraints actually sit.

Working out that math for a real workload, and building the serving and evaluation stack around it, is the kind of applied AI infrastructure work we do for clients. If you are weighing an open weight coding model against a closed API and want the decision grounded in your own volume, data rules, and reliability targets rather than a leaderboard, Contra Collective can run the numbers and stand up the deployment.