MiniMax M2: Specs, Benchmarks, API, and Local Deployment Guide

Last update: June 30, 2026

MiniMax M2 is an earlier MiniMax M-series Mixture-of-Experts language model built for coding assistance, tool use, and agentic workflows. Written officially as MiniMax-M2, it combines a large sparse model design with about 230B total parameters and about 10B active parameters per token. As of June 30, 2026, newer M-series models such as MiniMax M2.1, MiniMax M2.5, MiniMax M2.7, and MiniMax M3 are also available, so M2 is best treated as a historical, legacy, or comparison model for existing workflows rather than the current default MiniMax model.

This guide focuses on MiniMax M2 as a specific model profile. It covers the MiniMax M2 model architecture, parameter count, context window, benchmark snapshot, API access, Hugging Face weights, local deployment, use cases, limitations, and comparison criteria.

MiniMax M2 at a Glance

ItemDetails
Model nameMiniMax-M2
Current statusEarlier / legacy M-series model; still listed in current MiniMax docs for existing workflows and comparison with newer M-series models
DeveloperMiniMax
Model typeMixture-of-Experts language model
Main focusCoding, tool use, agentic workflows, reasoning
Total parametersAbout 230B
Active parametersAbout 10B per token
Context window204,800 tokens where supported by provider or API setup
Access optionsMiniMax API, Hugging Face/model weights, local deployment, and launch-era MiniMax Agent references; verify current product availability before relying on any hosted route
Deployment frameworksvLLM, SGLang, Transformers, MLX, Docker Model Runner, and compatible quantization routes; check current official and framework-specific docs before deployment
Best fitCoding agents, multi-step automation, developer workflows, research, tool-using assistants
CaveatBenchmark, pricing, and deployment results vary by provider, setup, and evaluation date

MiniMax’s GitHub materials describe MiniMax-M2 as a 230B-parameter MoE model with 10B active parameters, while MiniMax API documentation lists MiniMax-M2 with a 204,800-token context window and keeps it available for existing workflows. The MiniMax-M2 technical report gives the more exact figures of 229.9B total parameters and 9.8B activated per token, with a 192K-token native context window in the base architecture.

What Is MiniMax M2?

MiniMax M2 is an AI language model from MiniMax, designed around practical coding and agentic workflows rather than simple single-turn chat alone. It is usually written in two forms: MiniMax M2 in search queries and MiniMax-M2 in official model IDs, GitHub documentation, and Hugging Face listings.

The model was introduced in MiniMax’s 2025 launch materials as a model for agents and code. MiniMax described its target workloads as end-to-end development, long-chain tool calling, shell operations, browser use, Python code execution, and MCP-style tool coordination.

It should not be confused with newer M-series models such as MiniMax M2.1, MiniMax M2.5, MiniMax M2.7, or MiniMax M3. MiniMax’s current API documentation lists multiple M-series models, including MiniMax-M3 as the latest M-series model and MiniMax-M2 as still available for existing workflows; this article focuses specifically on MiniMax-M2.

MiniMax M2 Architecture: Why 230B Total and 10B Active Parameters Matter

MiniMax M2 is a Mixture-of-Experts model. In simple terms, an MoE model contains many expert subnetworks, but it does not activate all of them for every token. Instead, the model routes each token through a selected group of experts. This allows the model to have a large total capacity while keeping the per-token compute budget much lower than a dense model of the same total size.

For MiniMax-M2, the rounded public numbers are about 230B total parameters and about 10B active parameters per token. The technical report states the more exact architecture as 229.9B total parameters and 9.8B activated per token, implemented as a 62-layer decoder-only Transformer with 256 experts.

This matters because active parameter count affects serving efficiency. A model with fewer active parameters per token can be more practical for interactive agents, batch sampling, and repeated tool-use loops, although parameter count alone does not determine output quality. Data quality, post-training, tool integration, inference engine, context handling, and evaluation setup all affect results.

MiniMax’s own GitHub summary frames the design around lower latency, lower cost, and higher throughput for agentic and coding workloads, but users should validate those claims against their own workload before adoption.

Core Capabilities

Coding Assistance

MiniMax M2 is positioned as a coding model for developer workflows. Its most relevant coding tasks include code generation, multi-file editing, compile-run-fix workflows, test-validated repairs, repository-level refactoring, and CI-style automation. MiniMax’s GitHub page specifically highlights multi-file edits, coding-run-fix loops, and test-validated repairs as target strengths.

For teams building developer assistants, this makes MiniMax M2 most useful when the model is connected to a controlled environment: repository access, test runner, shell, linter, code search, issue tracker, and clear acceptance criteria. The model’s value increases when it can inspect errors, modify files, rerun tests, and make iterative fixes.

Agentic Workflows

MiniMax M2 is also designed for agentic workflows: tasks where the model plans multiple steps, calls tools, observes results, and adjusts its plan. Examples include shell-based debugging, browser-assisted research, retrieval pipelines, code-runner loops, and structured workflow automation.

MiniMax’s launch post describes long-chain tool-calling tasks that coordinate shell, browser, Python code interpreter, and MCP tools. Its GitHub materials also discuss shell, browser, retrieval, and code-runner workflows.

This does not mean MiniMax M2 will perform well in every agent setup. Tool-use quality depends heavily on scaffolding: how tools are exposed, how errors are returned, how memory is handled, how permissions are limited, and how success is verified.

Reasoning and Instruction Following

MiniMax M2 can also handle general reasoning and complex instruction following. However, benchmark scores are not guarantees. A model may perform strongly in a benchmark environment but struggle with a private codebase, unusual documentation, noisy data, or poorly designed tool wrappers.

For production use, MiniMax M2 should be tested with real tasks: bug reports, pull requests, internal documentation, code review workflows, support automations, and long-running agent jobs. That is more reliable than choosing a model based only on public leaderboard results.

MiniMax M2 Benchmarks and Performance Snapshot

MiniMax M2 benchmark data should be treated as a snapshot, not a permanent ranking. MiniMax’s GitHub repository lists benchmark areas such as SWE-bench Verified, Multi-SWE-Bench, SWE-bench Multilingual, Terminal-Bench, BrowseComp, GAIA, HLE with tools, τ²-Bench, FinSearchComp, and AgentCompany.

Artificial Analysis also evaluated MiniMax-M2 and highlighted its efficiency relative to active parameter count among open-weight models. The same analysis noted a practical caveat: MiniMax-M2 used 120M tokens to complete the Artificial Analysis Intelligence Index evaluations, which can reduce the cost advantage of low per-token pricing in verbose workflows.

Benchmark AreaWhat It TestsWhy It Matters for Users
SWE-bench VerifiedReal software issue resolutionUseful for coding agents and bug fixing
Multi-SWE-BenchMulti-language software tasksRelevant for polyglot engineering teams
Terminal-BenchCommand-line task executionImportant for shell-based agents
BrowseCompBrowser-assisted information retrievalUseful for research and web-navigation agents
GAIATool-assisted reasoning tasksHelps evaluate multi-step problem solving
τ²-BenchAgentic tool useRelevant for structured tool workflows
FinSearchCompFinancial search and reasoningUseful for domain-specific retrieval workflows

The safest interpretation is this: MiniMax M2 has credible reported performance in coding and agentic benchmarks, but benchmark results should be compared with real workload tests before committing to a model stack.

How to Use MiniMax M2

MiniMax Agent

MiniMax’s launch and Hugging Face materials referenced MiniMax Agent as a product built around MiniMax-M2 for agent-style workflows. Treat this as launch-era context rather than a permanent availability guarantee. If you want to test MiniMax-M2 today, verify the current MiniMax product interface, API access, and supported model list before relying on an agent UI route.

MiniMax API

MiniMax M2 can be accessed through the MiniMax API. MiniMax API documentation lists MiniMax-M2 among supported LLM models and states that MiniMax models can be called through HTTP requests, the Anthropic SDK path, or the OpenAI SDK path.

A generic OpenAI-compatible example looks like this:

curl https://api.minimax.io/v1/chat/completions \
  -H "Authorization: Bearer <MINIMAX_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MiniMax-M2",
    "messages": [
      {
        "role": "user",
        "content": "Review this function and suggest safer error handling."
      }
    ]
  }'

Before production use, confirm the endpoint, model ID, authentication method, rate limits, pricing, and availability in MiniMax’s official API documentation. MiniMax’s current rate-limit documentation lists MiniMax-M2 at 500 RPM and 20,000,000 TPM, but account-level limits and provider routes can differ. The API documentation also notes that the maximum token count refers to total input and output tokens.

MiniMax M2 API Pricing

MiniMax’s official pay-as-you-go pricing currently lists MiniMax-M2 under Legacy Models at $0.30 per 1M input tokens and $1.20 per 1M output tokens, with prompt caching read at $0.03 per 1M tokens and prompt caching write at $0.375 per 1M tokens. Pricing, discounts, quotas, provider markups, and billing rules can change, so verify the official MiniMax pay-as-you-go pricing before production planning.

Hugging Face and Model Weights

MiniMax-M2 model weights are available through MiniMax’s Hugging Face presence. The Hugging Face model page lists the model as text generation, shows the model ID MiniMaxAI/MiniMax-M2, and displays the license label as modified-mit, while the linked GitHub license uses MIT-style terms with an added commercial-scale attribution condition.

For commercial deployment, review the license, model card, acceptable-use terms, and any provider-specific requirements. The GitHub license says commercial products or services using the software must prominently display “MiniMax M2” in the user interface if they exceed 100 million monthly active users or more than 30 million US dollars in annual recurring revenue. “Open-weight” availability does not remove the need for legal and security review.

Local Deployment

MiniMax-M2 can be deployed locally with inference frameworks such as vLLM and SGLang. The Hugging Face page provides examples for using MiniMaxAI/MiniMax-M2 with vLLM and SGLang, including OpenAI-compatible local server calls.

The vLLM MiniMax-M2 series guide lists MiniMaxAI/MiniMax-M2 among supported models and describes system requirements such as Linux, Python 3.10–3.13, and GPU compute capability 7.0 or higher for NVIDIA deployments. It also notes substantial memory requirements, including roughly 220 GB for weights and 240 GB per 1M context tokens, with example configurations such as 4×96GB GPUs or 8×144GB GPUs depending on the target KV cache capacity.

Local deployment is best suited for teams with GPU infrastructure, inference engineering experience, and a clear reason to control model serving. For many teams, API access or hosted inference may be simpler.

MiniMax M2 Use Cases

MiniMax M2 is most relevant when the task benefits from coding ability, tool use, or long-horizon execution. Practical use cases include:

  • AI coding assistant for repository-level work.
  • Code review assistant for pull requests and diffs.
  • Automated bug fixing with test execution.
  • Repository-level refactoring and migration.
  • Tool-using research agent with browser and retrieval tools.
  • Internal developer automation for routine engineering tasks.
  • Technical documentation assistant for large codebases.
  • Batch generation or evaluation workflows.

The strongest use cases are not just “ask a question, get an answer.” MiniMax M2 is more compelling when paired with tools, verifiers, execution environments, and task-specific guardrails.

MiniMax M2 Limitations

MiniMax M2 is text-focused and should not be treated as a full native multimodal model. Hugging Face lists MiniMax-M2 under text generation, while MiniMax’s API docs separately describe multimodal chat input for M3.

Its other limitations are practical rather than unusual:

  • Benchmarks do not guarantee performance on every private codebase.
  • Local deployment can require substantial GPU memory and engineering work.
  • API pricing, provider routing, rate limits, discounts, and availability can vary; verify the live MiniMax pricing and rate-limit documentation before production use.
  • Tool-use quality depends on integration design.
  • Long-context support depends on provider and deployment setup.
  • Licensing and usage terms should be checked before commercial use.
  • Verbose outputs can increase task-level cost even when token prices look low.

The Artificial Analysis note about high token usage is especially important for agentic workflows. A low price per million tokens does not always mean a low cost per completed task.

MiniMax M2 vs Other Models: How to Think About Comparisons

MiniMax M2 should not be evaluated through a single “best model” claim. For coding and agentic workloads, compare models using:

  • Coding accuracy.
  • Test-pass rate.
  • Tool-use reliability.
  • Latency.
  • Output token usage.
  • Cost per completed task.
  • Context window.
  • Deployment control.
  • License and provider availability.
  • Performance on real internal workflows.

Comparisons with Claude, Gemini, DeepSeek, Qwen, Kimi, or other models should be workload-specific and date-specific. A model that performs well on SWE-bench may not be the strongest choice for document processing, customer support, retrieval-heavy research, or constrained latency environments.

For MiniMax M2, the comparison should focus on whether its MoE efficiency, open-weight availability, and coding-agent orientation match the user’s workload.

MiniMax M2 vs M2.1, M2.5, M2.7, and M3

Searchers looking for “MiniMax M2” may also see references to MiniMax M2.1, MiniMax M2.5, MiniMax M2.7, and MiniMax M3. MiniMax’s current API documentation lists these as separate M-series models, with MiniMax-M3 described as the latest M-series model and MiniMax-M2 still included as a supported model for agentic capabilities and advanced reasoning.

This guide is specifically about MiniMax-M2. Later M-series variants exist and should be evaluated through their own documentation, model cards, benchmarks, pricing, and deployment requirements. For new production planning, start by comparing M2 against newer MiniMax models, especially MiniMax M3, rather than assuming the original M2 profile is still the best default.

Who Should Use MiniMax M2?

MiniMax M2 is a good fit for:

  • Developers building coding agents.
  • Teams experimenting with open-weight model deployment.
  • AI engineers comparing coding models.
  • Researchers studying MoE efficiency.
  • Businesses that need controllable model deployment.
  • Teams building shell, browser, retrieval, or code-runner agents.

It is especially relevant for teams that can create strong evaluation harnesses. A good harness turns vague model comparison into measurable results: issue solved or not, tests passed or not, patch accepted or not, cost per successful task, and time per successful task.

Who Should Avoid MiniMax M2?

MiniMax M2 may not be the right fit for:

  • Users needing native image, audio, or video understanding.
  • Non-technical users who only need a general chatbot.
  • Teams without deployment or inference engineering resources.
  • Projects that cannot tolerate provider or license review.
  • Workflows where verbose output creates unacceptable latency or cost.
  • Use cases that require guaranteed behavior without task-specific testing.

For basic chatbot use, a simpler hosted model may be easier. For high-stakes automation, MiniMax M2 should be wrapped with permissions, logs, approval gates, tests, and rollback paths.

Final Verdict

MiniMax M2 is best understood as an earlier efficient Mixture-of-Experts language model built for coding and agentic workflows. Its main value is the combination of coding/tool-use focus, open-weight availability, and an active-parameter design that made large-model capacity more practical to serve at the time of release.

The model’s reported strengths are most relevant to developer agents, software engineering workflows, tool-calling systems, and long-horizon automation. Its limitations are equally important: benchmark rankings can age, provider details can vary, local deployment is resource-intensive, and task-level cost depends on actual token usage.

For serious adoption, test MiniMax M2 on your own workload, verify current pricing and licensing, and compare it against newer MiniMax M-series models before choosing it as a production route.

FAQ

What is MiniMax M2?

MiniMax M2 is a Mixture-of-Experts language model from MiniMax, designed for coding assistance, tool use, reasoning, and agentic workflows. It is also written as MiniMax-M2 in official model IDs and documentation.

Is MiniMax M2 open source or open weight?

MiniMax’s launch and GitHub materials describe MiniMax-M2 as open sourced, while the Hugging Face model page lists the license as modified-mit. The linked GitHub license uses MIT-style terms with an added commercial-scale attribution condition: products or services using the software must prominently display “MiniMax M2” in the user interface if they exceed 100 million monthly active users or more than 30 million US dollars in annual recurring revenue. For production or commercial use, review the model card, license text, and provider terms directly.

How many parameters does MiniMax M2 have?

MiniMax M2 is commonly described as about 230B total parameters with about 10B active parameters per token. The technical report gives the more exact numbers: 229.9B total parameters and 9.8B activated per token.

What is the context window of MiniMax M2?

MiniMax API documentation lists MiniMax-M2 with a 204,800-token context window. The technical report describes the base architecture with a 192K-token native context window, so context support should be checked against the specific API or deployment setup.

Is MiniMax M2 good for coding?

MiniMax M2 is built for coding and agentic development workflows. MiniMax’s GitHub materials highlight multi-file edits, coding-run-fix loops, test-validated repairs, SWE-bench-style tasks, and Terminal-Bench-style tasks.

Can I use MiniMax M2 through an API?

Yes. MiniMax API documentation lists MiniMax-M2 among supported LLM models and describes access through HTTP requests, Anthropic-compatible calls, and OpenAI-compatible calls.

How much does MiniMax M2 cost through the official API?

MiniMax’s current pay-as-you-go pricing lists MiniMax-M2 at $0.30 per 1M input tokens and $1.20 per 1M output tokens, with separate prompt caching read and write prices. Pricing can change, so verify the official MiniMax pay-as-you-go pricing page and your account billing console before production use.

Can MiniMax M2 run locally?

Yes. MiniMax-M2 weights are available on Hugging Face, and the model page includes examples for local serving with vLLM and SGLang. Large MoE deployment can require substantial hardware, so consult deployment documentation before planning infrastructure.

What is MiniMax M2 best used for?

MiniMax M2 is best used for coding agents, automated bug fixing, repository-level assistance, tool-using research agents, shell/browser workflows, and internal developer automation.

Is MiniMax M2 multimodal?

MiniMax M2 should be treated as text-focused. Hugging Face lists MiniMax-M2 as a text generation model, while MiniMax’s API docs describe multimodal chat input in relation to M3.

How is MiniMax M2 different from MiniMax M2.7?

MiniMax M2 and MiniMax M2.7 are separate M-series models. MiniMax’s API documentation lists both models, with MiniMax-M2 described for agentic capabilities and advanced reasoning, and MiniMax-M2.7 listed separately. This article focuses on MiniMax-M2.