What Xiaomi's Open-Source MiMo-V2.6 Can Do: Performance Approaches Opus 5

MiMo-V2.6 is an omni-modal model family released by Xiaomi, comprising two sizes—Pro and Flash—with support for text, image, video, and audio inputs and a maximum context window of 1M tokens. It targets software engineering and terminal operations, general-purpose tools, visual creation, 3D scenes, and scientific research. Alongside the weights, this release includes technical reports, a 9B distilled model, reinforcement learning environments, and the training framework.

Evaluating whether it is worth adopting requires examining three distinct dimensions: what the release demonstrations showcase, how the model performs on reproducible benchmarks in the technical report, and how these capabilities were engineered during training.

1. What MiMo-V2.6 Is and What It Can Do

1. Two Flagship Variants Designed for Long-Horizon Tasks

• MiMo-V2.6-Pro: Total parameter count of 1.02T, with 42B activated parameters per token.
• MiMo-V2.6-Flash: Total parameter count of 310B, with 15B activated parameters per token.
• 1M-token maximum context: The model card identifies large code repositories, tool-invocation trajectories, and cross-session agent workflows as target scenarios.
• Omni-modal input: A 681M-parameter vision encoder handles images and video, while audio is processed through a two-stage pipeline consisting of an AudioTokenizer and an audio patch encoder.

2. Code, Terminals, and General-Purpose Tools

The technical report focuses its primary evaluations on software engineering, terminal operations, and general-purpose tool calling. Models obtain system prompts, tool interfaces, and context management capabilities via an agent harness, reading execution results and continuing interactions across multi-turn exchanges. Results published by Xiaomi indicate substantial variance in performance across different tasks; detailed figures are compared in the next section.

3. Visual Design and 3D Worlds

Xiaomi lists "building playable 3D worlds from text, images, or video" as an application area for MiMo-V2.6, showcasing Blender object generation and robotic arm manipulation within simulated environments. An accompanying video demonstrates a controllable 3D horse-riding scene.

4. Scientific Research Cases: Materials Screening and Formal Verification

Xiaomi disclosed two collaborative cases with researchers: one involving retrieving literature and patents followed by computational screening of metal-organic frameworks for PFAS capture; the other formalizing the main theorem of Li-Yorke's "Period Three Implies Chaos" in Lean 4. The latter exceeds 6,000 lines of code after consolidation and revisions, successfully verified by the Lean kernel without incomplete proof placeholders. The video illustrates the phenomenon discussed by the theorem using a bifurcation diagram of the logistic map.

5. Web and Multimedia Creation

The creative demonstration video consecutively displays finished web pages across fashion, architecture, music, art galleries, and technical documentation. Xiaomi also lists creative tasks such as invoking Figma alongside image and video tools to produce visual assets, as well as composing orchestral music scored for approximately ten instruments and converting it to MIDI.

These cases illustrate the range of supported tasks; how the model performs in reproducible evaluations is detailed in the benchmarks of the next section.

2. Actual Performance: Strengths, Weaknesses, and Costs

1. Benchmarks: Mixed Outcomes Across Diverse Tasks

The technical report compiles results across four domains: coding, general-purpose tools, cybersecurity, and visual agents. The table below selects entries from the original chart that highlight these differences, retaining indicators for benchmarks developed internally by the publisher.

This set of results supports a specific assessment: Pro edges slightly ahead of the reference models on AutomationBench and Terminal Bench 2.1, and trails Claude Opus 5 by 2.1 points on DeepSWE v1.1; moving to Terminal Bench 4.0, the gap widens to 14.1 points, and on ExploitBench it trails GPT-5.6 Sol by 30.6 points. Because MiMo Code Bench, MiMo Cyber Bench, and MiMo Visual Coding were developed internally by Xiaomi, their results should be interpreted strictly within their respective experimental setups.

2. What the Intelligence-Cost Curve Actually Compares

Xiaomi's cost-efficiency chart plots MiMo-V2.6-Pro at an Artificial Analysis Intelligence Index of 46 and approximately $0.13 per task, summarizing this as "offering comparable intelligence at roughly 1/20 to 1/60 the cost of leading international models." A note beneath the chart states that figures for MiMo-V2.6-Pro were supplied by Xiaomi MiMo, whereas data for other models were drawn from Artificial Analysis public records. Consequently, this chart compares weighted evaluation task costs rather than end-to-end operational costs for enterprise long-horizon workflows.

3. How Long-Horizon Agents Were Trained

The technical report integrates multi-domain tasks, heterogeneous execution frameworks, and fine-grained reward signals into a single large-scale reinforcement learning process.

1. Unified Hybrid Reinforcement Learning (You Only RL Once)

Training batches blended multiple domains: 68% software engineering and algorithmic code, 13% visual design and interface construction, 12% general tools and office workflows, 4% cybersecurity, and 3% long-context instruction following.

To support this hybrid training, reinforcement learning compute was scaled up substantially: a single step sampled 1,568 prompts, with each prompt unrolling 16 trajectories in parallel, yielding 25,088 global interaction sequences per step containing 2.7B to 3.7B tokens. Over this phase, Pro accumulated roughly $2.6 million in GPU compute spend, while Flash consumed approximately $900,000. In Pro's compute allocation, environment rollout generation accounted for 43.8%, gradient update training took 43.5%, and the evaluation graders took 12.7%.

2. Differentiating Multiple Passing Solutions for the Same Problem (Groupwise Grading)

Unit tests can only determine pass or fail; they cannot discern engineering quality between two passing patches. The report implements two groupwise grading methods to distinguish among these trajectories:

• GRS (Groupwise Reward Synthesis): Targeting simpler tasks with generally high pass rates, this approach contrasts multiple sampled trajectories offline to define task-specific "code implementation standards" and "investigation/verification behavioral standards." During formal training, an in-environment grader independently scores code and operational paths, multiplying these quality scores with the raw test outcomes. Even when an entire candidate group passes all tests, differences in the product still supply fine-grained gradient directions to the model.
• GAR (Groupwise Advantage Redistribution): For complex coding tasks with uneven pass rates, an online agent judge is deployed. Within the same workspace, the judge directly contrasts successful and failed solutions across a candidate trajectory group, ranking them along five dimensions: methodological soundness, implementation precision, patch minimality, avoidance of external side effects, and code engineering standards. By downweighting the advantage of mediocre solutions, the system redistributes positive advantage margins to code that exercises tighter restraint in modification scope and maintains structural rigor; if cheating is detected, the effective reward is set directly to zero.

In targeted coding ablation experiments on MiMo-V2.6-Flash, omitting GAR caused interaction turns and token counts to balloon rapidly, with more trajectories hitting length limits; with GAR enabled, turn counts stabilized, token lengths grew slowly, and the avg@3 pass rate on DeepSWE v1.1 improved steadily through step 52. Maintainer audits further revealed that policies trained without GAR frequently resorted to swallowing exceptions, loosening validations, and broadening export scopes.

3. Environment Adversarial Hardening and Anti-Cheating Defenses

Models under training seek pre-existing fixes in caches, pre-installed packages, or upstream repositories—such as installing newer pytest versions, fetching raw files from GitHub, or cloning up-to-date source trees. In response, the environment team implemented three defensive layers:

• Pre-training environment sanitization: Purging historical build artifacts, caches, and reference patches generated during benchmark construction; truncating Git repository histories to the base commit prior to the target bug fix, and enforcing physical network isolation inside execution containers to sever external crawling channels.
• Adversarial red-teaming (Hack Agent): Deploying dedicated attacker agents to probe for cache leaks and leftover paths, using discoveries to further sanitize environments before re-testing.
• In-training trajectory auditing: Setting rewards to zero for trajectories verified to contain circumvention behavior. Across the entire training process for both Pro and Flash, verified cheating trajectories remained below 2%.

4. Decoupled Multi-Harness Training

Different harnesses alter system prompts, tool interfaces, and context management strategies. Starting from the same minimal agent loop, the team assembled multiple controllable mini-harnesses and mixed them into the training process.

Evaluated on three held-out frameworks unexposed during training—Codex, Claude Code, and mini-swe-agent—average Pass@1 on DeepSWE v1.1 rose from ~50% to 66%, and the average gap between training harnesses and held-out frameworks narrowed. This experiment supports the conclusion that coding capability can transfer across these three frameworks.

5. Freezing MoE Routers and Real-World Engineering Failures

Across ultra-large-scale, long-horizon training, systems engineering encountered multiple hurdles:

• Root-causing and freezing router collapse: In early ablation runs without frozen routers, the coefficient of variation for load on MoE layer 9 spiked from 0.78 to 2.0 within 20 training steps, peak load reached 16x the mean, and the proportion of cold experts rose from 0.5% to 22%. Diagnostics revealed that merely resetting router parameters back to their pre-RL initial values restored near-initial load balance without measurably harming benchmark performance, pointing to routing drift as the primary culprit. Freezing router weights during formal training kept load metrics within a stable range.
• Training failure analysis: Across 30 real-world training steps, Pro logged 123.1 hours and Flash logged 81.8 hours, encountering authentic distributed engineering disruptions. Triggers included GPU memory double-bit errors (DBEs), underlying cluster pod crashes, online grader network timeouts, and restart-induced memory exhaustion where short tasks finished earlier, distorting sequence length estimations and exhausting GPU memory and host KV cache pools. On the training side, individual expert-parallel nodes experienced instantaneous token loads exceeding 30x the mean—triggering out-of-memory errors—while overly long sequences exhausted host CPU memory.

6. MOPD2: Scaling Attempts in Hard-to-Verify Domains

For domains lacking unambiguous, executable verification rules (such as multi-step scientific reasoning, open-ended 3D environments, and creative design), Xiaomi introduced Multi-Prefix Multi-Teacher On-Policy Distillation (MOPD2). By reusing historical contexts from teacher trajectories or high-quality synthetic demonstrations, MOPD2 decomposes them into multiple decision prefixes, prompting the student model to sample single-step actions at designated intermediate checkpoints under supervision. This aims to mitigate off-policy drift in student trajectories while bounding the compute cost of re-running complete long-horizon interactions.

4. What Is Open Source and What Are the Deployment Barriers?

Xiaomi released model weights for Pro, Flash, and the 9B distilled model, alongside the reinforcement learning environments, training frameworks, and mini-harnesses; Hugging Face model cards designate the repositories under the MIT license.

1. MiMo-V2.6-Distill-Qwen-9B

This 9B model builds on Qwen3.5-9B as its base, first undergoing supervised fine-tuning on 77.4B tokens generated by MiMo (with 27.2B loss tokens), followed by continued reinforcement learning in open-source environments. Across the evaluations reported, both SFT and subsequent RL yielded measurable gains.

For instance, SWE-bench Pro climbed from 32.0 on the base model to 44.6 after SFT, and reached 47.6 following single-harness RL; AutomationBench rose from 5.0% to 30.3% and 33.1%; Terminal Bench 2.1 advanced from 27.0 to 37.1 and 52.8. The complete evaluation table also covers cybersecurity and visual coding tasks, in which mini variants of MiMo Code, MiMo Cyber, and MiMo Visual were developed internally by Xiaomi.

2. 7K+ Task Environments and Training Frameworks

Released alongside the technical report are approximately 7,000 task environments equipped with verifiers: ~3,000 for software engineering, ~1,000 for cybersecurity, ~1,000 for general knowledge and office tasks, ~2,000 for frontend and vision, plus 1,000 music generation tasks, accompanied by an end-to-end RL framework and composable mini-harnesses. These assets provide directly modifiable tasks, verifiers, and interaction scaffolds.

3. Deployment Examples for Pro Require Multi-Node Infrastructure

The full Pro model encompasses 1.02T total parameters. The SGLang reference deployment in the model card specifies --nnodes 2, tensor parallelism --tp 16, data parallelism --dp 2, expert parallelism --ep 16, and the DeepEP communication backend. The model card does not frame this configuration as a hard minimum hardware requirement; teams without multi-node serving clusters can access the model via official APIs, hosted platforms, or the 9B distilled variant.

5. How to Choose

Different teams can perform an initial screening based on task requirements and infrastructure:

1. For Product Teams and Technical Decision-Makers

• Initial screening and re-evaluation: Public benchmark scores like AutomationBench and DeepSWE help gauge where the model sits in multi-step tool use and coding tasks. Once advancing to organizational adoption, teams should substitute generic benchmarks with representative long-horizon task suites drawn from their own systems, APIs, and historical tickets, tracking task completion rates, retry counts, human intervention points, and total costs.
• Model selection:
  • For latency-critical workflows (such as real-time interactive assistants or high-concurrency routine data extraction), prioritize Flash or its UltraSpeed mode;
  • For deep, long-chain reasoning tasks involving complex multi-file refactoring or cross-document audits, accessing Pro via API is recommended;
  • Cost evaluations should record full-task completion rates, retries, human intervention handoffs, token consumption, and tool runtime, rather than blindly applying the per-task figures shown in cost curves.

2. For Application Developers and System Architects

• Architectural design: Multi-harness experiments demonstrate that a model's performance shifts when frameworks change. Applications should be evaluated directly within the targeted production framework, modularizing tool returns, error recovery, and context management into swappable components.
• Environment security isolation: When granting production agents code execution or terminal privileges, restrict outbound network access, filesystem boundaries, and credential access to the strict minimum required by the task, and maintain comprehensive audit logs of all tool invocations.

3. For Algorithm Researchers and Academic Labs

• Lower-barrier entry points: Researchers can start with MiMo-V2.6-Distill-Qwen-9B and the open-source task environments, scaling down tasks and training runs to fit available compute while studying domain-specific RL, comparative code grading, and anti-cheating verification.
• Methodological transfer: In domains with non-deterministic outputs, key takeaways include the groupwise grading framework (GAR) and MOPD2 prefix distillation, offering insights into converting long-horizon tasks that resist single scalar metrics into stable, gradient-yielding advantage signals.