What is MiniMax-M1?
MiniMax-M1 is an open-weight large language model designed for reasoning-heavy workloads. MiniMax released it on June 16, 2025, positioning it for complex problem solving, software engineering, technical writing, long-document analysis, mathematical reasoning, and multi-step agent tasks.
The model is available as two official variants: MiniMax-M1-40k and MiniMax-M1-80k. The suffixes refer to the maximum reasoning-output budget rather than two unrelated model families. The 40k variant is intended to use a smaller reasoning budget, while the 80k variant can spend more tokens working through difficult problems. Longer reasoning can improve performance on some tasks, but it can also increase latency and token consumption.
MiniMax-M1 is the current subject of this page; the 40k and 80k checkpoints are the independently deployable releases within that family. It is distinct from MiniMax’s multimodal model lines: M1 is a text reasoning model, not a native image, audio, or video generation system.
Architecture, parameters, and context capacity
MiniMax-M1 uses a hybrid-attention architecture. It combines Lightning Attention, intended to make attention more efficient over long sequences, with conventional softmax attention. The model is also a mixture-of-experts, or MoE, system. In an MoE model, different parts of the network are selectively activated for each token instead of using every parameter for every step.
The model family has 456 billion total parameters and approximately 45.9 billion activated parameters per token. The distinction matters when evaluating deployment: the active-parameter figure describes the computation used for an individual token, while the total-parameter figure still reflects the substantial memory needed to store and serve the model weights.
MiniMax-M1 supports a context window of up to one million tokens. This is useful for large codebases, lengthy technical documents, extensive research material, and agent workflows that need to retain substantial conversation or task state. A large context window does not automatically make every long prompt equally useful: input quality, retrieval or document organization, available hardware, and inference settings still affect practical results.
The maximum reasoning-output budget is 40,000 tokens for MiniMax-M1-40k and 80,000 tokens for MiniMax-M1-80k. These are unusually large output allowances for step-by-step reasoning, but they should not be confused with the one-million-token context capacity. The context window concerns the total usable sequence, while the reasoning limit concerns the model’s allowed generated reasoning output.
Reasoning, coding, and tool use
MiniMax-M1 is intended for tasks where the model must break a problem into multiple steps before producing an answer. Suitable examples include difficult mathematics, technical analysis, software debugging, architecture planning, and research tasks that require comparing information across long inputs.
MiniMax reports results for mathematical reasoning, software engineering, long-context understanding, and tool-use evaluations. In the company’s published evaluations, MiniMax-M1-80k achieved a 56.0% score on SWE-bench validation, while MiniMax-M1-40k achieved 55.6%. These figures are provider-reported benchmark results and should be interpreted in the context of the stated benchmark version, evaluation setup, and comparison group.
The model also supports function calling through a documented tool-call format. This allows an application to provide available functions, receive a structured request from the model, execute the requested operation externally, and return the result for further reasoning. Tool support makes M1 relevant to agentic workflows such as repository operations, data retrieval, task orchestration, and controlled automation. The supplied research confirms function-call support, but does not establish that every hosted interface exposes identical tool behavior.
For coding, M1 is best suited to substantial tasks rather than only short code completion. Its long context can help it inspect large repositories or extended technical specifications, while its reasoning budget can support planning, debugging, and multi-file changes. However, greater reasoning depth can make it slower than smaller models on routine edits or simple programming questions.
Supported modalities and output types
MiniMax-M1 accepts text and produces text. It does not natively generate images, audio, video, music, embeddings, or speech according to the supplied model data. It is therefore appropriate for text-based reasoning and tool-driven applications, but not as a direct replacement for a multimodal generation model.
Users who need image understanding, image generation, audio processing, or video generation should consider a model family specifically designed for those modalities. MiniMax’s broader catalog includes other model lines such as MiniMax-VL and Hailuo, but those are mentioned here only to clarify M1’s positioning; MiniMax-M1 itself remains a text-only reasoning model.
Deployment and licensing
MiniMax released the M1 weights through official Hugging Face repositories under the Apache 2.0 license. The official materials provide deployment guidance for Transformers, vLLM, and SGLang. This makes M1 relevant to organizations that want to study the model, adapt their serving stack, or run inference without relying exclusively on a hosted endpoint.
Self-hosting is demanding. The model’s 456-billion total parameters create substantial memory and infrastructure requirements, even though approximately 45.9 billion parameters are activated per token. MiniMax’s deployment guide states that, under its tested configuration, a server with eight H800 GPUs can process contexts of approximately two million tokens. That statement describes the provider’s tested deployment configuration and should not be treated as a universal hardware requirement or guarantee for every serving framework.
For smaller teams, hosted access may be more practical than operating high-memory GPU infrastructure. Self-hosting offers more control over deployment and data handling, but requires engineering work, suitable accelerators, model storage, and operational capacity. Hosted use reduces infrastructure responsibility but introduces dependence on provider availability, current pricing, and the capabilities of the selected endpoint.
Pricing and API availability
The launch API pricing published by MiniMax was tiered by input length:
| Usage category | Launch price |
|---|---|
| Input from 0 to 200,000 tokens | $0.40 per 1 million tokens |
| Input from 200,000 to 1 million tokens | $1.30 per 1 million tokens |
| Output tokens | $2.20 per 1 million tokens |
These are launch prices rather than a guaranteed current rate. Hosted API pricing and availability can change independently of the open-weight releases. The input tiers also mean that a very long prompt may cost more per million input tokens than a shorter one. Extended reasoning can further increase output-token usage, so the practical cost of a difficult request depends on both the input length and the amount of generated reasoning.
The open-weight checkpoints remain useful for self-hosted research and experimentation, but hosting them locally is not automatically cheaper. Infrastructure, GPU rental, electricity, storage, engineering time, and utilization all affect the total cost. A hosted endpoint may be preferable for occasional use, while self-hosting may make more sense for teams with sustained workloads and existing high-memory GPU capacity.
Strengths and limitations
Main strengths
- Long context: The model supports up to one million tokens, making it suitable for large documents, codebases, and extended task histories.
- Extended reasoning: The 40k and 80k variants provide large reasoning-output budgets for difficult multi-step tasks.
- Software engineering focus: Provider-reported SWE-bench validation results indicate a strong emphasis on coding and repository-level problem solving.
- Open-weight availability: Official checkpoints are released under Apache 2.0, with deployment guidance for Transformers, vLLM, and SGLang.
- Tool support: The documented function-call format allows integration with external tools and agent workflows.
Main limitations
- High deployment demands: The model’s total parameter count makes self-hosting substantially more demanding than using a smaller reasoning model.
- Potentially high latency: Extended reasoning budgets may improve difficult-task performance but can make responses slower.
- Variable cost: Long inputs and large reasoning outputs can consume more paid tokens through a hosted API.
- Text-only operation: M1 does not natively accept or generate images, audio, or video.
- Unclear knowledge cutoff: The primary release materials and official repositories do not clearly specify a knowledge cutoff.
- Changing hosted terms: Launch API prices and availability should be checked before production use.
When to choose MiniMax-M1
Choose MiniMax-M1 when the task benefits from a large working context, deliberate reasoning, or both. It is a strong candidate for analyzing a long technical document, reviewing a large repository, planning a multi-step software change, solving difficult mathematical problems, or coordinating tools across an extended agent workflow.
The 40k variant is the more practical choice when the task is demanding but does not require the largest available reasoning budget. The 80k variant is better suited to especially complex tasks where additional reasoning may justify higher latency and token usage. The research does not establish that the 80k version is universally better; the appropriate choice depends on task difficulty, response-time requirements, and budget.
A smaller reasoning model may be more appropriate for short questions, routine code edits, high-volume classification, or latency-sensitive applications. A conventional fast language model may also be a better fit when a task does not require extended internal reasoning. A multimodal model is preferable when the application must directly understand or generate images, audio, or video.
MiniMax-M1 is therefore best understood as a specialized open-weight option for long-context, reasoning-intensive text workloads. Its combination of one-million-token context, large reasoning budgets, function calling, and Apache 2.0 checkpoints is valuable for advanced experimentation and demanding applications, but its infrastructure requirements and potentially slower, more expensive inference make it less suitable for lightweight or real-time use.