Diagnosing and Mitigating Tool-Call Repetition in MiMo-V2.6

Tracing the Source of Tool-Call Repetition

To 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) / N

This 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.

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.

Further 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.

A Costly Fix with Limited Generalization

The 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.

The 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 calls

A More Efficient and Generalizable Solution

We 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.

We also computed the cumulative stopping probability at position k:

F_k = 1 − ∏_i=1^k (1 − p_i)

where F_k is the probability that the model stops by the k-th tool call.

On 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.

Specifically, 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.

The 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.

New Checkpoints Released and MiMo Desktop Quota Reset

We 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.