Diagnosing and Mitigating Tool-Call Repetition in MiMo-V2.6
A post-mortem on repeated tool calls in MiMo-V2.6: how tool-call flooding was amplified during RL, why a stricter penalty alone was costly and generalized poorly, and how a repetition-specialized RL teacher with MOPD fixed it.
English简体中文ProductMiMo CodeMiMo DesktopResearchPaperBlogJoin UsEnglish简体中文 September 27, 2026Diagnosing and Mitigating Tool-Call Repetition in MiMo-V2.6A lesson from scaling RL: the reward blind spot in optimizing for correctnessFollowing the release of MiMo-V2.6, tool-call repetition emerged as one of the most noticeable issues affecting the user experience. In MiMo Desktop, MiMo Code, OpenCode, and other agentic settings, the model would sometimes issue the same or highly similar tool calls repeatedly, consuming substantial time and context without making meaningful progress.Our internal evaluations confirmed this pattern: the response-level repetition rate exceeded 0.05%. The table below breaks down the rates for MiMo-V2.6-Flash-RL and MiMo-V2.6-Pro-RL across different agent harnesses.Tool-call repetition rates of MiMo-V2.6-Flash-RL and MiMo-V2.6-Pro-RL across agent harnessesHarnessMiMo-V2.6-Flash-RLMiMo-V2.6-Pro-RLOpenCode1.02%0.54%MiMo Desktop0.19%0.19%Claude Code0.27%0.10%OpenClaw0.17%0.08%Codex0.23%0.07%MiMo Code0.11%0.07%DeepSeek Harness0.17%0.07%Hermes0.16%0.05%Zcode0.07%0.05%Tracing the Source of Tool-Call RepetitionTo understand the problem, we first distinguish among normal parallel tool calling, tool-call flooding, and tool-call repetition.Parallel tool calls are a standard way to improve agent efficiency. For example, an agent may read several relevant files at once or run multiple independent queries in parallel. Even calls to the same tool are not repetitive when they serve different information needs. Tool-call flooding occurs when the model issues substantially more calls than the task requires or the execution environment can process effectively, creating execution queues and backlogs of pending tool results.Tool-call repetition, by contrast, refers to repeated actions with no reasonable justification. The model continues to generate semantically identical or highly similar calls even though neither the available information nor the environment state has materially changed and there is no legitimate reason to retry or verify the result. This may occur within a single response, across turns after tool feedback, or as a loop over the same sequence of operations. Reasonable retries after failures, necessary state polling, and rerunning tests after modifying code do not count as repetition here.Flooding and repetition can occur independently, but they may also reinforce one another. A model can issue many duplicate calls in one response and continue the same behavior in later turns, compounding wasted computation and context usage while making little progress. From the user's perspective, tools keep running but the agent stalls, leading to longer waits, an unresponsive experience, or even task failure.The description above defines repetition behaviorally. Because semantic equivalence is difficult to detect reliably at scale, we use a narrower but reproducible metric in this post: exact within-turn repetition. We treat the batch of calls emitted in one assistant turn before any tool feedback as a single unit. Two calls count as duplicates when they invoke the same tool and their arguments are identical after JSON canonicalization. If a turn contains N calls and U unique calls, its exact within-turn repetition rate is:(N − U) / NThis metric has two advantages. First, because no tool feedback arrives between calls in the same turn, duplicates generally cannot be explained as result-driven retries. Second, the judgment can be replayed and reproduced directly from a single turn. However, it is only a lower bound on observable repetition, not a complete repetition rate or a measure of flooding. It excludes three important cases: cross-turn repetition after tool feedback; near-duplicates whose arguments differ slightly despite serving the same information need; and calls made inside code-mode harnesses, where the model exposes only an exec call while the underlying tool invocations remain embedded in its script.To determine when the problem emerged, we replayed a fixed set of internal examples that had exhibited repetition against checkpoints from different stages of RL training (steps 0, 5, 10, 15, and 20). Evaluating the same examples at every checkpoint allowed us to track how the behavior evolved during training.For MiMo-V2.6-Flash-RL, the share of replayed examples that still exhibited flooding (more than ten tool calls in a single turn) was already 11.1% at RL step 0, and the flooding rate rose to 24.6% by step 20. The trend was especially pronounced under MiMo Code, where the flooding share was already 30.6% at the start and grew to 41.7% late in training.RL stepShare of replayed examples with ≥10 tool calls in a single turnMiMo DesktopMiMo CodeOpenCodeCodexClaude CodeAll harnesses011.1%30.6%5.6%5.6%8.3%11.1%516.7%22.2%0%5.6%8.3%8.7%1025.0%44.4%0%11.1%5.6%16.7%1533.3%38.9%25.0%8.3%2.8%22.5%2033.3%41.7%27.8%16.7%5.6%24.6%This increase occurred despite an existing tool-call flooding penalty in our RL pipeline. During rollout, if the model issued more than 32 tool calls in a single turn, we stopped the rollout early and set its reward to zero. During the subsequent gradient update, preceding turns were masked out and the penalty was applied only to the turn that triggered the rule. Every token in that turn, including chain-of-thought tokens, was included in the penalty.We then examined the corresponding training metrics. The model almost never triggered the flooding penalty early in training. Starting at approximately step 15, however, the number of examples with more than 32 tool calls in a single turn began to rise noticeably and continued increasing as training progressed.Samples triggering the tool-call flooding penalty (more than 32 calls in a turn) in the MixRL training log, as a count and as a rate. The Flash and Pro runs use the same per-turn cap and are directly comparableFurther analysis suggested that the threshold was too permissive. Using MiMo-V2.6-Flash training traces from the general/dataset-epqd data source, we measured the share of examples containing more than eight tool calls in a single turn. A small fraction already showed high-volume tool calling at RL step 0. Because behavior below the threshold of 32 was not penalized, it was gradually amplified during training and eventually developed into severe flooding that crossed the threshold. Some flooding traces also contained repeated or highly similar calls, but our analysis here focuses on abnormal call volume and does not equate flooding with repetition.MiMo-V2.6-Flash training traces (general/dataset-epqd): share of turns with more than eight tool calls (left), share of those turns containing duplicate calls (middle), and mean redundancy (right). Duplicates are exact matches on tool name and JSON-normalized argumentsA Costly Fix with Limited GeneralizationThe most direct solution was to lower the flooding-penalty threshold. In a separate experiment on a small, isolated general/dataset-epqd data source, we lowered the threshold from 32 calls to eight and resumed training from the step-28 checkpoint of MiMo-V2.6-Flash. The number of turns containing more than eight calls dropped substantially, showing that the stricter penalty effectively suppressed flooding without a noticeable loss in overall reward.The drawback was that the effect emerged only after approximately 20 training steps. Applying this fix at full scale would therefore require restarting 20 steps of MixRL, at an estimated cost of $2.31 million.Capping tool calls at 8 per turn, resumed from the MiMo-V2.6-Flash step-28 checkpoint (dashed line marks the fork). Top row: training-log metrics; bottom row: offline trace statistics on general/dataset-epqdThe environment-level penalty also generalized poorly to the full internal evaluation set. Replaying the repetition cases with the resulting checkpoint reduced the repetition rate from 13.45% to 3.83%, but did not eliminate the problem.Replay repetition rate of the stricter-penalty checkpoints. History N means the visible history of the replayed request already contains N turns with ≥10 tool callsCheckpointInternal test set 1 · history 0Internal test set 1 · history 1Internal test set 2 · history 0Internal test set 2 · history 1flash-ga-grpo-s302.27% (1/44)28.57% (4/14)13.45% (30/223)25.00% (13/52)flash-ga-grpo-s359.30% (4/43)33.33% (5/15)7.86% (18/229)17.65% (9/51)flash-ga-grpo-s4011.11% (5/45)33.33% (5/15)4.58% (11/240)17.86% (10/56)flash-ga-grpo-s450% (0/45)28.57% (4/14)4.40% (11/250)11.67% (7/60)flash-ga-grpo-s500% (0/43)28.57% (4/14)3.83% (9/235)16.98% (9/53)A More Efficient and Generalizable SolutionWe therefore needed a solution that was both efficient to train and robust in real-world scenarios beyond the training distribution. We ultimately adopted an MOPD-based approach (Multi-teacher On-Policy Distillation).We first used internally collected repetition examples to train a specialized, single-turn RL teacher. A rollout received a reward of 0 when repetition occurred and a reward of 1 only when it contained neither repetition nor erroneous tool use. We also applied a KL loss to keep the teacher close to the original RL policy. After only 12 training steps, comprising approximately 7,000 examples, the teacher reduced replay repetition to zero on both the training and held-out sets.To understand the mechanism at a finer level, we examined one trajectory sampled from the RL traces. Before the fix, the model issued 59 tool calls. At every <tool_call> token position, we compared the probability assigned to <|im_end|>, the end-of-turn token, by the models before and after the fix.Schematic of the example trajectory. At the 12th tool-call position, the model before the fix continues with another tool call with 94.56% probability, while the fixed model emits the end-of-turn token with 92.17% probabilityProbability of predicting the end-of-turn token <|im_end|> at each tool-call position in the example trajectory, before vs. after the fixWe also computed the cumulative stopping probability at position k:Fk = 1 − ∏i=1k (1 − pi)where Fk is the probability that the model stops by the k-th tool call.Cumulative termination probability F_k, before vs. after the fixOn this example, the repaired model had a 99.87% probability of stopping within eight tool calls and showed a strong tendency to stop at every position from five through 20. Before the fix, the cumulative probability of stopping was still only about 50% even after 59 calls.The top-four token probabilities at the 12th tool-call position make the change especially clear. Before the fix, the model had a 94.56% probability of continuing with another tool call. After RL training, it assigned a 92.17% probability to ending the turn. The specialized teacher had learned when to stop; the remaining challenge was to merge this behavior into the main model through MOPD.Top-4 token distribution at the 12th tool-call position, before vs. after the fixSpecifically, we rolled the final MOPD run back by five steps, introduced the repetition-specialized RL teacher, and continued training with teacher-prefix OPD. Additional details are provided in Section 5.6 of the technical report. During training, the repetition-specific flood_opd_loss decreased steadily while the overall opd_loss remained stable.MOPD training dynamics: (a) overall OPD loss; (b) OPD loss on flood-prone data; (c) overall training entropy; (d) tool-call flood rate on flood-prone dataThe final comparison is shown below. After MOPD, repetition rates for both MiMo-V2.6-Pro and MiMo-V2.6-Flash dropped substantially across context lengths and agent harnesses, while performance on the broader benchmark suite held steady. The complete training run cost approximately $90,000, only 4% of the estimated cost of the MixRL alternative.MiMo-V2.6-Pro repetition rate (%) by harness and input length, before and after MOPD. Light-gray cells without values indicate ≤0.001% or no observationsMiMo-V2.6-Flash repetition rate (%) by harness and input length, before and after MOPD. Light-gray cells without values indicate ≤0.001% or no observationsNew Checkpoints Released and MiMo Desktop Quota ResetWe have open-sourced the latest MOPD checkpoints that address tool-call repetition in the MiMo-V2.6 collection on Hugging Face. The corresponding model names carry the MOPD suffix.As an apology to our users, we will reset the remaining quota in the current usage window for all MiMo Desktop users.The updated models have been available on our API platform since September 25 at 06:00 (UTC+8). The model names remain unchanged: mimo-v2.6-pro and mimo-v2.6-flash.We hope this post offers useful lessons for diagnosing and addressing behaviors that emerge during RL: issues that may appear minor and evade standard metrics, yet materially affect the model's real-world performance across diverse scenarios.