The behavior of MiMo-V2.6-Pro comes from one mixed reinforcement-learning run: 30 steps, 1,568 prompts per step, 16 rollouts per prompt, 2.7 to 3.7 billion tokens of trajectory per step, and a bill of $2.6M. The report titles the section "You Only RL Once", and the name is the design.
If you are planning a reinforcement-learning run of your own, or trying to read the training curve published with the release, this chapter is the map. It covers what one step contains, where the compute goes, and what broke along the way, because the failure log is as instructive as the scores.
The obvious alternative is to train each capability separately, the way most teams do: a coding run, a tool-use run, a design run. This run instead mixes all of them into every batch, across several agent harnesses at once, on the theory that capabilities trained together reinforce each other and that strategies learned in one harness transfer to others.
What the batch mixes
The task distribution is recorded plainly: agentic and competitive coding at 68%, aesthetic design at 13%, general tool use at 12%, cybersecurity at 4%, context following at 3%. Each prompt spawns a group of 16 rollouts, so one step trains on about 25,000 trajectories running 110K to 150K tokens each.
The harness dimension is layered on top. Production agent harnesses wrap the model in engineering scaffolding and instruction prompts that sit outside the reward signal, and their modules cannot be varied independently, so they make poor training instruments. The run instead uses small composable harnesses, all built from one minimal loop of system prompt, tools, and context management, with configurations adapted per domain. Four of those mini-harnesses appear in training. When the trained model is then evaluated on codex, claude code, and mini-swe-agent, three harnesses it has never met, the group mean pass rate on DeepSWE v1.1 climbs from roughly 50% to 66% over the course of training. The learned coding ability transfers across harness implementations.
What one step contains
The algorithm is Group Relative Policy Optimization (GRPO) with asynchronous partial rollouts at a staleness of 4. Partial rollouts are the piece that keeps a large batch fed. When it is time to collect a training batch, sequences that are still running get interrupted and resumed in the next rollout phase instead of being discarded. The price of resuming is re-prefill: after each policy update, a continuation must rebuild its key-value cache from scratch. A large batch amortizes that rebuild across more finished work, which is why batch size and partial rollout are chosen together.
Two filters keep the batch useful. A dynamic sampler drops groups where all 16 rollouts passed or all 16 failed, because such a group carries no gradient signal. A sample mixer holds the per-task mixture steady while rollout durations vary enormously: across 25 profiled data sources, mean generated tokens differ by 90 times and active rollout duration by 66 times, so slow sources get bigger concurrency budgets to keep their share of the batch.
Build the training batch
Move any slider. The published run sits at the defaults.
Where the money went
The cost splits three ways, and the third way is the new one. Rollout generation takes 43.8%, gradient training takes 43.5%, and grading takes 12.7% of the $2.6M. A twelfth of the budget goes to deciding which answers were better, which is the subject of chapter 6.
Preparation before RL, and what broke during it
Preparation happened first. Mid-training ran on agent-centric data, initially at 256K context and then extended to 1M, with an optimizer switch from AdamW to Muown, a variant of Muon with row-norm control, for the hidden weight matrices. The reason was scale: Muon updates matrices by orthogonalization and holds up better as batches grow. The report notes no loss spike during the switch, which prior work had warned about. Mid-training also included quantization-aware training at MXFP4, so the model learned to live at the precision it would be served and rolled out at.
Then RL ran for 30 steps and 123.1 hours of wall clock on the Pro model. The failure log is candid. GPU memory double-bit errors forced restarts. Pro was restarted once when the grader became unreachable over the network after step 14. Partial rollouts produced their own failure mode: shorter sequences finish first, which biased the length estimates used for admission and exhausted the GPU and pinned-host key-value pools. One harness produced rollouts less than half as long as the others on the same data, and the estimates took two steps after a restart to recover. Training itself crashed once when an expert-parallel rank received over 30 times the mean token load of one layer.
If you run an asynchronous batch with partial rollouts, expect the same class of failures: length-estimate bias after a restart, memory spikes from routing imbalance, and infrastructure restarts you did not schedule. The report budgets for them.