What MiniMax-M2-REAP-139B-A10B is
MiniMax-M2-REAP-139B-A10B is an open-weight causal language model released by Cerebras. It is derived from MiniMaxAI's MiniMax-M2 and belongs to the sparse mixture-of-experts, or MoE, class of models. In an MoE model, the complete network contains many specialized expert modules, but a router activates only a subset of them for each token. This allows the model to contain a large amount of learned capacity without running every parameter for every part of every prompt.
The name describes the compressed configuration: the checkpoint contains approximately 139 billion total parameters and activates approximately 10 billion parameters per token. The model uses Cerebras Research's Router-weighted Expert Activation Pruning method, abbreviated REAP, to remove experts that contribute less to the target workload. According to the supplied model documentation, 40% of the experts were pruned.
This is not a new general-purpose model family separate from MiniMax-M2. It is best understood as a deployment-focused derivative: a smaller expert pool intended to require less memory than the uncompressed model while retaining much of its coding, reasoning, conversation, and tool-use behavior.
How the REAP compression works
The checkpoint is configured with 62 layers, 48 attention heads, 154 remaining experts, and 8 experts activated for each token. The router continues to make input-dependent selections among the surviving experts. That distinction matters because REAP removes experts rather than combining their weights into averaged replacements.
Expert merging can reduce the number of components, but combining experts may also reduce the functional differences that allow an MoE model to respond differently to different tasks. Cerebras describes REAP as preserving independent routing among the experts that remain. In practical terms, the model still uses conditional computation: a coding request, a mathematical problem, and a conversational prompt can be routed through different expert combinations.
The 139B total-parameter figure should not be read as meaning that all 139 billion parameters are executed for every token. The approximately 10B active-parameter figure describes the approximate amount selected per token, while the full parameter count still matters for storing the checkpoint and planning deployment hardware. Consequently, this model can be more economical to run than the full MiniMax-M2 in some respects, but it is not a small model and is not suitable for ordinary low-memory hardware.
Coding, reasoning, and general capabilities
MiniMax-M2-REAP-139B-A10B is intended for text generation, code generation, agentic coding, mathematical reasoning, conversation, and function or tool calling. The official materials report evaluations including HumanEval, HumanEval+, MBPP, MBPP+, and AIME25. The supplied research indicates that the REAP variant scores below the uncompressed MiniMax-M2 baseline on the listed coding benchmarks, while remaining competitive relative to its reduced deployment footprint.
That positioning is important. The model should not automatically be treated as a quality improvement over MiniMax-M2. Its principal benefit is the trade-off between retained capability and reduced expert count. Users who need the strongest available result from the original family may prefer the full model, assuming they can meet its memory and serving requirements. Users who need a compressed open-weight checkpoint may accept some benchmark degradation in exchange for a more manageable deployment.
For reasoning tasks, the model is suitable for mathematical problem solving, code analysis, planning-oriented prompts, and other workloads that benefit from a large language model's ability to work through multiple steps. However, the research does not provide a model-specific knowledge cutoff or a guaranteed reasoning-token limit. Its reasoning quality should therefore be evaluated on the user's own tasks rather than inferred from the editorial reasoning score alone.
Context, inputs, and outputs
The configured context length is 196,608 tokens, providing room for very long documents, codebases, multi-step conversations, and tool traces. This is a model configuration limit, not a guarantee that every deployment will expose the entire window. The serving framework, available memory, request settings, and prompt format can impose additional practical limits.
The checkpoint is a text-generation model. It accepts text and returns text. Its supported uses include ordinary chat, code generation, reasoning responses, and text representations of tool or function calls when the serving setup supports them. It does not natively generate images, video, audio, speech, music, or embeddings. The supplied model information also does not identify native multimodal input support.
No maximum output-token value is identified in the supplied research. Users should not assume that the full 196,608-token context can be emitted as a single response: the context window covers the combined prompt and generated continuation, subject to the model server's own limits.
Tool use and deployment options
The model includes a chat template and can be loaded with the Transformers library using trust-remote-code support. The official documentation also provides deployment examples or guidance for vLLM, SGLang, Docker Model Runner, and related tooling. vLLM and SGLang can expose OpenAI-compatible local endpoints, which may make it easier to connect the model to existing applications.
Tool or function calling is listed as supported, but the exact behavior depends on the chat template and serving framework. A local endpoint may format tool calls in a structured way, stream tokens, or accept schema-related request options, but those are deployment features rather than additional native output modalities. Applications should test the exact prompt template, parser, and server configuration they plan to use.
The checkpoint is primarily intended for local, self-hosted, or research deployment. The supplied research states that Hugging Face does not currently identify this exact checkpoint as deployed by an inference provider. There is therefore no verified official hosted API endpoint or managed inference price for this model in the available information.
Pricing and cost considerations
No provider-hosted input or output price is supplied for MiniMax-M2-REAP-139B-A10B, and no listed inference provider is currently serving the exact checkpoint. Its direct model price is therefore unknown rather than zero. The relevant cost question for most users is infrastructure: storage, memory capacity, electricity, hardware rental, and engineering effort for operating a roughly 139B-parameter checkpoint.
REAP is intended to improve that deployment trade-off by removing 40% of the experts and activating approximately 10B parameters per token. This can lower memory and serving requirements compared with the full MiniMax-M2 configuration, but the model remains large. A deployment that cannot accommodate the stored checkpoint and its runtime overhead should consider a smaller model rather than assuming sparse activation alone makes it inexpensive.
The editorial cost score associated with this record reflects the model's compressed design and open-weight deployment potential. It is an evaluation aid, not a provider-published price or operating-cost guarantee.
Main strengths and limitations
Strengths
- Reduced expert count: REAP removes 40% of the original experts while retaining conditional routing among the remaining experts.
- Long context: The configured 196,608-token window is useful for large documents, repositories, long conversations, and tool traces.
- Broad text workload coverage: The model is designed for coding, mathematical reasoning, agentic coding, conversation, and tool calling.
- Open deployment: Users can work with Transformers, vLLM, SGLang, Docker Model Runner, and related local-serving tools.
- More manageable than the full model: Its approximately 139B total parameters represent a substantial reduction from the uncompressed MiniMax-M2 configuration.
Limitations
- Still very large: Approximately 139B total parameters require substantial storage and runtime resources.
- Some quality trade-off: The supplied benchmark summary indicates lower results than the full MiniMax-M2 baseline on the reported coding evaluations.
- No managed pricing: There is no verified hosted API price or listed inference provider for the exact checkpoint.
- Text-only generation: It does not natively produce images, video, audio, speech, music, or embeddings.
- Deployment details matter: Framework support, chat templates, tool-call parsing, quantization, and hardware configuration can affect the practical experience.
- Unspecified output ceiling: The research gives a context length but does not provide a separate maximum output-token limit.
When to choose MiniMax-M2-REAP-139B-A10B
Choose this model when you want an open-weight MiniMax-M2 derivative for self-hosted use and the main constraint is the cost or memory footprint of the full expert pool. It is a reasonable candidate for long-context coding assistants, repository analysis, agentic coding systems, mathematical reasoning experiments, conversational applications, and local tool-calling workflows. Its value is greatest when the application can use a large model but can tolerate some loss relative to the uncompressed baseline.
It may be particularly appropriate for teams that already operate Transformers, vLLM, or SGLang and want to evaluate a compressed MoE checkpoint in their own environment. Local deployment also provides control over data handling and request routing, although it shifts hardware and operational responsibilities to the user.
When another option may be more appropriate
Use the full MiniMax-M2 instead if maximum quality within this model family is more important than reduced memory requirements and your infrastructure can support it. Choose a substantially smaller language model if the deployment target has limited memory, if low latency is more important than long-context capacity, or if a 139B-parameter checkpoint is impractical.
A hosted model may be a better fit when you need predictable per-request pricing, a managed endpoint, automatic scaling, or a documented service-level interface. A multimodal model is more appropriate for applications that must directly process or generate images, audio, or video. Similarly, a dedicated embedding model is the appropriate type of system for vector search rather than this text-generation checkpoint.
Bottom line
MiniMax-M2-REAP-139B-A10B is a compressed, open-weight version of MiniMax-M2 designed to make a large sparse MoE model easier to deploy. It retains a 196,608-token context window and targets coding, reasoning, conversation, and tool use, but it remains a demanding 139B-parameter checkpoint. Its central trade-off is clear: lower expert and memory requirements than the full model in exchange for some reported benchmark degradation and the ongoing complexity of self-hosting. For users who can provide the hardware and want an open long-context model with a reduced expert pool, it is a focused deployment option rather than a general-purpose hosted API product.