MiniMax-M2.5: specs, benchmarks, and how to run it on Lyceum

Get started: call MiniMax-M2.5 on Lyceum

To integrate MiniMax-M2.5 into your application, you can use the standard OpenAI Python SDK. Our platform provides a drop-in replacement API, meaning you do not need to rewrite your application logic or learn a new framework. By updating the base URL and providing your Lyceum API key, you can route requests directly to our managed infrastructure.

from openai import OpenAI
 
 client = OpenAI(
 base_url="<the base URL shown in your Lyceum dashboard>",
 api_key="<your lyceum api key>",
 )
 response = client.chat.completions.create(
 model="MiniMaxAI/MiniMax-M2.5",
 messages=[{"role": "user", "content": "Hello!"}],
 max_tokens=256,
 )
 print(response.choices[0].message.content)

Pricing and region for MiniMax-M2.5

When you deploy this model through the Lyceum Serverless Inference API, you are billed strictly on a per-token basis with no minimum commitments or idle compute charges. MiniMax-M2.5 is served through Serverless Inference, the same pay-per-token product as every other catalogue model, so there is no service tier to select.

The pricing for MiniMax-M2.5 is $0.30 per million input tokens and $1.20 per million output tokens. This is one of the few catalogue models that is globally hosted rather than EU-hosted, and it only receives traffic when you select it explicitly. This setup allows engineering teams to access a massive 230-billion parameter Mixture-of-Experts model without the overhead of provisioning and managing the underlying hardware. You pay only for the exact compute you consume during inference.

What MiniMax-M2.5 is good at

Frontier-level coding and agentic workflows

MiniMax-M2.5 is a 230-billion parameter Mixture-of-Experts model developed by MiniMax. During inference, it activates only 10 billion parameters per token, allowing it to maintain high throughput while delivering reasoning capabilities that rival the largest proprietary models. The model was extensively trained using reinforcement learning across hundreds of thousands of complex environments, making it highly effective for software engineering and agentic tool use.

One of the defining characteristics of MiniMax-M2.5 is its emergent Architect Mindset. Unlike standard coding models that immediately begin generating scripts based on a prompt, M2.5 proactively decomposes the task. It plans the project structure, feature requirements, and user interface design before writing any code. This architectural approach significantly reduces logical errors in complex, multi-file software projects and makes the model exceptionally well-suited for autonomous agent workflows.

Multilingual programming and web research

The model demonstrates strong proficiency across more than ten programming languages, including Python, Rust, Go, C++, and TypeScript. It handles the entire development lifecycle, from initial environment setup to system development and debugging. Furthermore, MiniMax-M2.5 excels at web research and tool calling. It can navigate complex browser environments, manage long contexts, and execute precise search iterations to gather necessary information before synthesizing a final response. This makes it a strong candidate for backend automation and data-heavy research pipelines.

Limitations and trade-offs

Where MiniMax-M2.5 falls short

While MiniMax-M2.5 delivers exceptional performance for software engineering, its massive scale introduces significant deployment challenges for teams attempting to self-host the model. The unquantized bf16 weights require approximately 457 GB of VRAM. Even with aggressive 8-bit quantization, the model demands over 240 GB of memory, necessitating multi-GPU clusters like an 8x H100 node. For startups and mid-market teams, the infrastructure costs of running this model on dedicated hardware often outweigh the benefits, making managed API access a more practical choice.

Another trade-off stems from the model's reinforcement learning profile. Because MiniMax-M2.5 is trained to exhibit an Architect Mindset, it tends to over-plan and over-explain when given straightforward tasks. If you ask the model to write a basic bash script or fix a minor syntax error, it may generate unnecessary architectural breakdowns and project specifications before delivering the code. This behavior consumes additional output tokens, which increases latency and inference costs for trivial requests.

Finally, while the model supports a 204,800-token context window, utilizing the extreme upper limits of this context can degrade time-to-first-token performance. Teams building real-time, latency-sensitive applications should carefully manage their prompt sizes or consider smaller, specialized models for tasks that do not require deep reasoning or complex task decomposition.

Benchmarks and how it compares

MiniMax-M2.5 benchmark results

MiniMax-M2.5 has been evaluated across several rigorous industry benchmarks, demonstrating performance that matches or exceeds current frontier models. It is particularly strong in software engineering and agentic web navigation.

Source: MiniMax Official Release and Hugging Face Model Card, both read on 3 August 2026. MiniMax publishes no comparator scores for the SWE-Bench and BrowseComp rows.

On the SWE-Bench Verified evaluation, which tests a model's ability to resolve real-world GitHub issues, MiniMax-M2.5 scores 80.2%. MiniMax publishes no comparator score on that row of its model card, and reports that M2.5 completes the evaluation 37% faster than its predecessor M2.1. In multilingual coding tasks measured by Multi-SWE-Bench, the model reaches 51.3%, and it scores 76.3% on BrowseComp when context management is enabled.

When compared to sibling models in the open-weights ecosystem, MiniMax-M2.5 offers a distinct advantage in reasoning speed. It runs complex agentic evaluations faster than its predecessor, MiniMax-M2.1. For engineering teams evaluating models for autonomous coding agents, M2.5 provides the accuracy of a massive dense model with the inference efficiency of a sparse Mixture-of-Experts architecture.

Using it in production

Production configuration for MiniMax-M2.5

When deploying MiniMax-M2.5 in production, engineering teams must account for its specific context limits and pricing structure. The model supports a maximum context window of 204,800 tokens, the figure MiniMax publishes in its own model documentation, read on 3 August 2026. This massive capacity allows you to input entire codebases, extensive API documentation, or large datasets in a single prompt. However, to maintain optimal inference speeds, we recommend utilizing prompt caching strategies and keeping routine requests well below the maximum limit.

On the Lyceum platform, MiniMax-M2.5 is served through Serverless Inference. There are no service tiers: every catalogue model is billed per token, and latency and capability follow from the model you choose rather than from a plan you select. This is one of the few catalogue models served outside the EU, so Lyceum's EU-hosting default does not apply to it.

To forecast your infrastructure costs, consider a typical agentic workflow. If an autonomous coding agent processes 2 million input tokens while reading repository files and generates 500,000 output tokens while writing new features, the cost calculation is straightforward. The input tokens cost $0.60 (at $0.30 per million), and the output tokens cost $0.60 (at $1.20 per million). The total cost for this extensive task is $1.20. This per-token pricing model ensures you only pay for active compute, eliminating the financial risk of maintaining idle GPU clusters. For more details on how this architecture scales, read our guide on serverless GPU inference explained.

Why run MiniMax-M2.5 on Lyceum

Why run MiniMax-M2.5 on Lyceum

Lyceum gives AI teams a managed way to run frontier models without standing up GPU infrastructure of their own. The MiniMax-M2.5 catalogue endpoint is globally hosted rather than EU-hosted, and you reach it through a standard OpenAI-compatible interface. Point your existing OpenAI SDK at our base URL, swap in your API key, and the model becomes a drop-in replacement, so there is no new framework to learn and no application logic to rewrite. The preceding generation is documented separately in our notes on Nemotron-Ultra-253B and how to run it.

Managing a 230-billion parameter model on your own hardware is a complex engineering challenge. It requires advanced orchestration, continuous monitoring, and specialized inference engines like vLLM or NVIDIA Dynamo. By using our Serverless Inference API, you offload this operational burden. Our platform handles the underlying GPU provisioning, load balancing, and auto-scaling, and our open-stack approach keeps the serving layer transparent rather than a black box. You can also burst to per-second dedicated GPUs when a workload needs guaranteed throughput.

Lyceum runs European data centres in Spain, Paris and the Nordics, with GPU compute billed per second and no base fee, though MiniMax-M2.5 itself is served globally rather than from that European footprint. Per-token pricing on the catalogue carries no base fees, no minimum commitments, no idle charges, and zero egress fees, all on a single unified bill. Whether you are running batch jobs or serving real-time requests, you scale from zero to thousands of concurrent requests instantly. For a deeper look at how this architecture works, read our guide on A100 vs H100 for LLM inference.

Sources

[1] MiniMax M2.5: Built for Real-World Productivity; [2] MiniMaxAI/MiniMax-M2.5 on Hugging Face; [3] MiniMax M2.5 - SOTA in Coding and Agent; [4] GitHub; [5] MiniMax M2.5 Open-Weights Models Catch Up