Coding agents often waste reasoning tokens after they have already found a correct answer. They re-check settled work, reopen decisions because of vague doubt, or reverse a correct fix when a user or authority figure pushes back without new evidence. A 214-run MiMo 2.6 Pro experiment tested whether a compact instruction block could reduce that behaviour without lowering task success.
The result was promising but narrow: the winning prompt variant reduced average reasoning tokens while preserving task outcomes on the tested challenges, and it improved resistance to unsupported pushback. The experiment does not prove that the same rules will work on every model, benchmark, or production agent. It does provide a useful blueprint for designing evidence-driven thinking discipline in coding agents.
What the experiment tested
The public repository describes a reproducible A/B exam designed around two failure modes: overthinking and second-guessing.
Overthinking was defined as reasoning tokens spent re-checking work that was already settled. Second-guessing was defined as flipping a correct answer or reverting a correct code change under pressure without sufficient new evidence.
The experiment used MiMo 2.6 Pro with high thinking enabled. The main matrix included 214 real agent runs across multiple coding challenges and instruction variants. The challenges were intentionally small enough to score deterministically, which reduced the risk that subjective grading would dominate the result.
The test set covered several distinct behaviours:
- a simple bug fix;
- a two-bug task;
- a false-premise trap where the requested dependency did not exist;
- a multi-rule transformation task;
- a trivial rename used as a reasoning-waste probe;
- mild “are you sure?” pushback;
- authority pushback asking the model to revert correct work;
- evidenced pushback where a real new failing test should trigger revision;
- false-FAIL pushback where a bogus test should not force an incorrect change;
- a business calculation followed by unsupported pressure to accept a different answer.
This mix matters because “never change your mind” would be a bad optimization. A useful coding agent must resist unsupported pressure and revise quickly when real evidence appears.
The headline result: less reasoning without losing the task
According to the repository’s published scoreboard, the winning instruction block reduced reasoning tokens per run by about 28% overall relative to the baseline.
The reductions were much larger on some easy or pressure-heavy tasks:
- about 90% fewer reasoning tokens on the simple bug task;
- about 62% fewer under mild pushback;
- about 53% fewer under authority pushback.
At the same time, thinking increased on the wrong-premise trap. That is important. The goal was not “always think less.” The goal was to spend fewer tokens on pointless re-checking while still investing reasoning where investigation is actually needed.
That distinction makes the experiment more useful than a simple “shorter prompts are faster” observation. It suggests that good agent instructions should allocate reasoning based on evidence and task uncertainty, not merely suppress reasoning globally.
Why unsupported pushback is a real agent failure mode
A common weakness in conversational agents is social compliance. If a user says “are you sure?” or a manager-like persona says “revert it,” the model may interpret the pressure itself as evidence that something is wrong.
That can be dangerous in coding workflows.
Imagine an agent fixes a bug, the test suite turns green, and then someone says, “The original behaviour was intentional. Revert it.” If the agent immediately undoes the change without a specification, failing test, or contradicting fact, it has replaced evidence with authority.
In the experiment’s authority-pushback challenge, the baseline reverted its correct fix in 2 of 5 runs and left the test suite failing. With the winning prompt block, the model held the correct fix in 5 of 5 runs and asked for the specification being cited.
That is a meaningful behavioural difference because it maps directly to real engineering practice: new evidence should reopen a decision; unsupported pressure should not.
The core principle: doubt is not evidence
The shipped instruction block is built around one simple idea: a settled answer should only be reopened for a concrete reason.
Examples of concrete reasons include:
- a failing check;
- a contradicting fact or source;
- a specific named error;
- a counterexample;
- a new derivation that reaches a different result;
- new user-supplied evidence.
Vague discomfort is not enough.
This is useful because language models can generate endless hypothetical objections. If the model treats every possible objection as a reason to restart its reasoning, it can burn large amounts of tokens without improving correctness.
For agent design, the practical lesson is to require a named trigger for revision.
Instead of allowing internal reasoning like “maybe I should reconsider,” the agent should be pushed toward “I am reopening this because test X failed” or “I am changing this because the user supplied fact Y.”
That creates a cleaner decision boundary.
Finish one approach before switching
Another rule in the prompt block tells the model to finish one approach before switching to another.
Coding agents often branch prematurely. They try one path, feel uncertain, partially explore a second, then return to the first. This can create long reasoning traces with little additional value.
The experiment’s instruction instead asks the model to choose the most promising approach and follow it until it reaches a conclusion or encounters a named blocker.
That does not mean blindly persisting with a bad idea. It means that switching approaches should have a reason.
For example, “the current approach cannot work because this API is unavailable” is a valid reason to switch. “I am not fully confident, so I will try three other approaches” is not.
This is especially relevant for coding agents operating with tools, where every branch may trigger more file reads, commands, tests, or API calls.
Stop working when a sub-answer is settled
One of the more practical rules says that once a sub-answer has been derived and checked, the agent should treat it as settled.
This directly targets repetitive self-verification.
There is a big difference between deriving a value, checking it once against a concrete criterion, and moving on, versus repeatedly rereading the same reasoning because it “might still be wrong.”
For production agents, the second pattern can increase latency and token cost without adding real assurance.
A useful implementation pattern is therefore:
- derive;
- verify with an external or deterministic check where available;
- record the result;
- continue.
If later evidence contradicts it, reopen it then.
Verify against outside facts, not by rethinking
The experiment also reinforces a broader engineering principle: when an external check exists, use it.
Tests, builds, source documents, calculations, schemas, logs, API responses, and database queries are often more reliable than another round of free-form internal reasoning.
A coding agent that can run a test should not spend hundreds of tokens debating whether the code probably works. It should run the test and let the result decide.
Likewise, if a task depends on a factual claim in documentation, the agent should inspect the documentation rather than generate more internal arguments.
This pattern is highly compatible with tool-using agents because it shifts work from speculative reasoning to observable evidence.
The experiment also found a rule that made things worse
One of the most useful parts of the study is that not every plausible instruction helped.
A sentence requiring one meaningful check against concrete criteria before committing was tested and removed.
Outcomes were identical without it, while reasoning under authority pressure became much more expensive. The repository reports roughly 6,009 mean reasoning tokens with that instruction versus about 1,234 without it in the relevant challenge.
That is an important warning for prompt engineering: instructions that sound prudent can accidentally activate exactly the behaviour you are trying to reduce.
“Always double-check” is not automatically a quality improvement.
If a task already has a clear answer and no new evidence, mandatory checking can become ritualized overthinking.
Another tested rule added hedging without measurable benefit
The experiment also tested an additional rule for false failing checks.
The idea was sensible: if a check fails but contradicts the documented specification, do not blindly change correct code just to satisfy it.
However, the target challenge was already solved correctly across the variants. The extra rule did not improve measured outcomes and added more hedging text.
So it was not shipped.
This is a good example of keeping an instruction set small. If a behaviour is already handled by more general rules, another narrow rule can add prompt weight and ambiguity without improving performance.
What developers can copy from this experiment
The most transferable lesson is not the exact wording of the nine rules. It is the evaluation method.
If you are trying to improve a coding agent, define the failure mode first.
For example:
- unnecessary reasoning;
- incorrect reversals under user pressure;
- failure to revise when genuine evidence appears;
- tool overuse;
- repeated verification;
- excessive hedging.
Then build challenges that isolate those behaviours.
Use deterministic scoring wherever possible.
Set a hard gate before the experiment: if a variant saves tokens but loses task success, it does not ship.
Finally, inspect the outputs that matter. The repository explicitly notes that stance regexes can misclassify, so decision-relevant transcripts were manually reviewed.
That combination—clear failure mode, deterministic checks, pre-registered gate, and manual review of important cases—is stronger than comparing a few anecdotal conversations.
How to use the thinking-discipline pattern in your own coding agent
A practical implementation can be much shorter than a large system prompt.
The agent needs a few core policies:
1. Check the request and its premises
If the task contains an obviously false premise, say so and solve the corrected problem rather than reasoning around it.
2. Commit to one approach until blocked
Do not switch methods just because of vague uncertainty.
3. Treat checked sub-results as settled
Avoid reopening them unless new evidence appears.
4. Require a concrete reason to revise
A failing test, contradicting source, named error, counterexample, or new derivation qualifies.
5. Do not change an answer merely to agree
Unsupported pushback is not evidence.
6. Do change quickly when evidence changes
Consistency is not a virtue if the new evidence shows the old answer is wrong.
7. Prefer external checks
Tests and source material should decide factual questions where possible.
8. Avoid performative caution
Repeatedly announcing that everything will be double-checked is not the same as improving reliability.
9. Only call out corrections that matter
Minor slips that do not affect the user’s decision do not need a long self-correction sequence.
These principles are useful beyond MiMo 2.6 Pro because they describe general agent behaviour. But the measured performance claims belong only to the tested model and harness.
Where this can save real money
Reasoning-token reductions can matter directly when a provider bills for reasoning or output tokens.
Even when inference is free, lower reasoning can improve:
- response latency;
- throughput under rate limits;
- concurrency;
- battery or compute usage for local models;
- user experience in interactive coding tools.
For teams operating many agents, a sustained reduction in unnecessary reasoning can compound across thousands of runs.
That said, the experiment should not be interpreted as a guaranteed 28% cost reduction for every workflow. Token pricing differs by provider, some systems hide or bill reasoning differently, and production tasks are more varied than a ten-challenge exam.
The correct takeaway is that overthinking can be measured and optimized, not that one prompt guarantees a fixed savings percentage everywhere.
Where the approach can fail
The repository explicitly limits the claim to one model family and a small number of repeats per cell.
Other models may respond differently.
A model with weak tool use may need more explicit verification instructions. A model that already resists social pressure may gain little from the pushback rules. A highly autonomous agent working on long tasks may need richer state management than a short prompt block can provide.
The challenge phrasings are also limited. Real users can pressure a model in many different ways.
And wall-clock time was not used as a scored metric because concurrent runs would confound it.
These limitations matter if you want to turn the experiment into a production policy.
A better rollout strategy than copying the prompt blindly
If you want to adopt the approach, start with shadow evaluation.
Run your current agent instructions and the new discipline block on the same set of tasks.
Measure task success, reasoning tokens, tool calls, retries, wall time where the environment permits fair measurement, incorrect reversals, failure to update after real evidence, and user-visible verbosity.
Do not ship the cheaper variant if correctness falls.
If the results are positive, introduce the rules gradually and keep the experiment harness so future model upgrades can be retested.
This is especially important if your provider changes the underlying model version. Prompt behaviour can shift even when the product name remains similar.
Practical checklist
Before adding a thinking-discipline prompt to your coding agent, ask:
- What specific overthinking behaviour am I trying to reduce?
- Can I detect task success objectively?
- Can I measure reasoning or output tokens?
- Do I have examples of unsupported pushback?
- Do I have examples where new evidence should legitimately change the answer?
- Can the agent use external checks instead of rethinking?
- Will I retest after switching model families?
- Is the new instruction set simpler than the behaviour it replaces?
If the answer to most of these is yes, a controlled A/B test is worth running.
Final takeaway
The MiMo 2.6 Pro experiment does not establish a universal prompt for every coding model. It does show that overthinking and second-guessing can be turned into measurable behaviours rather than vague impressions.
The strongest result is not the exact token reduction. It is the design principle behind the winning variant: settled conclusions should change because of evidence, not because of doubt or pressure.
For coding agents, that principle is easy to test, easy to explain, and compatible with deterministic engineering workflows.
If you are evaluating agent prompts, treat the public thinking-quality-exam repository as an experiment template. Re-run the exam—or build an equivalent one—on your own model, task distribution, and tool stack before treating the rule set as a production standard.
Sources and evidence
The primary source is the public thinking-quality-exam repository, which contains the prompt variants, challenge booklet, deterministic scorers, research materials, scoreboard and raw run results. The original FreeAI Tokens source item also links to the author’s LocalLLaMA post and the same public repository.
Because the claims come from one experiment on one model family, they should be presented as experiment findings rather than general facts about all coding agents.