Xiaomi’s MiMo-V2.6 update tackles a costly AI failure: working without making progress

The most revealing detail in Xiaomi’s latest MiMo-V2.6 update is not a benchmark rank. It is an admission that an agent could keep invoking tools without advancing the task. Xiaomi’s 27 September account describes a repair, released as MOPD checkpoints, that targets this behaviour. Its API had received the update on 25 September while keeping the same model identifiers.[1]

That is a meaningful distinction for anyone buying AI work. A stream of activity can resemble diligence: files open, searches run and terminal messages accumulate. But the customer needs a repaired program, a reconciled report or an answered question. Time spent displaying effort has value only when it improves the result or establishes something necessary about it.

The key question is whether the next call can change the answer

Consider an illustrative coding job. Reading a configuration file again after editing it is verification. Repeating the identical read five times before receiving any result is not. Polling a running build may be appropriate after a wait; starting the same expensive build repeatedly without checking its state can instead create a queue. The tool name alone cannot tell these situations apart.

A useful action therefore has a reason. It should obtain missing evidence, modify the intended state, verify a change or resolve a documented failure. A reviewer need not demand a lengthy explanation for every call. The execution record can carry the necessary context: what was known, what changed and which result the next action was waiting for.

Xiaomi’s diagnostic metric counts exact duplicate tool names and JSON-normalised arguments within one assistant turn. It is deliberately narrower than all wasted activity: near-duplicates and loops spanning several turns can escape it. Legitimate retries should not be treated as failures merely because they revisit the same operation.[1]

Why the repair strategy matters

The Pro model card describes a broad reinforcement-learning stage followed by multi-teacher on-policy distillation: learning from specialist teachers while the student generates its own trajectories. The Flash-MOPD documentation describes complementary streams using student-generated work and teacher or supervised prefixes. These are distinct training arrangements, not alternative names for a bigger prompt.[2][3]

The intuition is useful beyond this release. A student can look competent when following an expert’s clean demonstration and still become stuck after its own earlier mistake. Training on states the student actually reaches addresses that mismatch. Specialist feedback then has an opportunity to correct a recurring behavioural weakness without redefining every part of the model’s job.

Xiaomi reports roughly $90,000 for the MOPD repair run, versus an estimated $2.31 million to extend the alternative full-scale reinforcement-learning approach. Those are its reported experiment economics, not independently audited costs or the total cost of developing MiMo.[1]

The business lesson is not that every model can be fixed cheaply. It is that a narrowly diagnosed failure may call for a narrowly targeted intervention. Before increasing training expenditure, an engineer needs to know whether the failure comes from missing knowledge, an unsuitable reward, a tool interface, or the absence of a clear stopping condition. More of the wrong training can reinforce the wrong habit.

Two percentages that should never share an unlabelled chart

Suppose a turn contains 12 calls but only eight distinct requests. Four of its calls are redundant, so the within-turn fraction is 4 divided by 12: 33.3%. Now suppose only 10 out of 1,000 turns contain any duplication. The affected-turn rate is 1%. Both numbers can describe the same hypothetical workload; they answer different questions.

For a purchasing decision, add the consequences. Did those ten turns consume a minute or an hour? Did they merely repeat a search, or trigger duplicate external operations? Did the task eventually pass? The average can conceal a small set of disproportionately expensive failures. Our proposed scorecard would retain affected-turn frequency, duplicate-call volume, elapsed time and independently accepted outcomes together.

The useful next benchmark is progress

Our assessment is that this release deserves attention because it makes a practical failure inspectable. A strong trial would replay troublesome jobs, retain legitimate verification steps and check that lower activity does not simply mean premature stopping. Faster abandonment would be a cosmetic improvement; the goal is fewer pointless operations on the way to the same or a better accepted result.

For users, the best question is straightforward: after the update, does the agent spend less time circling a problem and more time resolving it? That test is more demanding than watching the tools move, and closer to what an AI assistant is being hired to do.

Report an error or suggest a correction