Your Coding Agent Re-Thinks Every Step — This Tsinghua Trick Cut Its Token Bill by 88%

Watch your coding agent work for five minutes and you will see the waste. It writes a file, then stops to think about what to do next. It runs the compiler, then stops to think again. It sees the tests pass, then stops to think about whether to run the next command — a command it already knew it would run before it wrote the first line of code.

Every one of those pauses is a full reasoning call: the model re-reads the whole conversation, re-derives a decision it already made, and bills you for the tokens. A new paper from Tsinghua University and Microsoft Research Asia puts a number on that waste — and then removes most of it. On the same 98 coding tasks, one popular harness went from 96,280 tokens per task to 11,620. That is an 87.93% cut, and the agent actually got better at the job.

The paper is "HarnessMM: Recursive Self-Improvement for Harness Token Efficiency" by Yuhua Jiang, Chang Xu, Feifei Gao and Li Zhao (arXiv:2610.32813, submitted 23 October 2026, revised 6 November 2026). It does not touch the model at all — no fine-tuning, no new weights, no new tools. It changes one thing: when the harness is allowed to call the reasoning model.

What the researchers did

Start with the observation. An agent harness — the software that connects a model's reasoning to tool execution — follows a simple loop: reason, act, observe the tool result, reason again. The problem is that the second reasoning call is often pointless. As the paper puts it, harnesses "invoke reasoning after each tool result, even when earlier calls have already determined subsequent actions." The decision was already made; only the permission to execute it was missing.

The researchers draw a useful line between two kinds of uncertainty. Semantic uncertainty is about the action itself: what should I do, and with what arguments? Execution uncertainty is only about readiness: is it time to do it yet? Once the reasoning model has fixed an action and its literal arguments, the semantic part is resolved. All that remains is waiting for a tool result that says "go". Re-thinking the action at that point adds nothing — it just re-spends tokens.

HarnessMM (short for HarnessMinusMinus) captures that idea in three pieces:

1. Executable Decision Graphs (EDGs). When the agent reasons, it does not just produce one next action. It writes down a small graph of resolved decisions: the action, its literal arguments, what it depends on, and a public guard — the observable condition that must be true before the action may run. The paper's own example: after writing a program, the compile command can already be specified; after compilation, a successful return code activates an already-specified test command.

2. Guarded Decision Reuse (GDR). A lightweight controller watches the tool feedback coming back. When an observed result satisfies a stored decision's guard, that decision activates — no reasoning call needed. The decision is reused across tool transitions instead of being re-derived.

3. Certified Callback Substitution (CCS). This is the step that actually saves the money. The activated decision is executed through the harness's native tool interface, and the reasoning callback it replaces is formally removed from the run. The paper names the trap this avoids the Substitution Paradox: adding a fast decision step saves nothing if it does not also delete the slow reasoning call it replaces. A substitution only counts when the computation removed is bigger than the computation added — authorship, selection, fallback and recovery included.

A typed selector picks an eligible decision, or abstains. Whenever new reasoning is genuinely required, or the evidence is insufficient, control returns to the original actor immediately. Nothing is forced: the guard either holds or it does not.

On top of that sits Recursive Self-Improvement (RSI): the harness's own prompts, context settings and adapter rules are iteratively refined using training feedback, with validation picking the deployment configuration. The actor's weights stay fixed throughout — this is harness optimisation, not model training.

Then the results, all on the same 98 HumanEval coding tasks, each harness compared against its own original version:

Codex: success preserved at 90.82%, tokens per task down from 66.72k to 47.02k — a 29.54% saving.

DeepSeek Harness: success rose from 71.43% to 85.71% while tokens per task fell from 96.28k to 11.62k — an 87.93% saving, roughly 8× fewer tokens per task.

An MBPP ablation isolates the two mechanisms: persistent decision reuse alone costs 26.91% less than single-use graphs, and callback removal costs 19.52% less than keeping the callbacks. A companion study, HarnessMM-V, applies the same idea to visual agents. The code is open at https://github.com/YuhuaJiang2002/HarnessMM

Why it matters

First, the biggest token cost in agentic coding is not thinking — it is re-thinking. Prompt compression and context trimming shrink each call; HarnessMM asks whether the call needs to happen at all. For anyone running coding agents at scale, that is the difference between a tool that is impressive in a demo and one that is affordable in production.

Second, cheaper did not mean dumber here. The DeepSeek Harness result is the one to sit with: tokens down nearly 88% while success went up by 14 points. Fewer reasoning calls meant fewer chances for the model to second-guess a correct plan into a wrong one. Re-deriving a decision is not just expensive — it is a fresh opportunity to make a mistake.

Third, the idea transfers beyond this paper. Any workflow with a predictable chain — write, compile, test; fetch, transform, load; draft, check, send — contains resolved decisions waiting on guards. You do not need HarnessMM's code to use its logic, only the discipline of writing the plan down before you execute it.

Finally, it reframes the "smarter model" reflex. When your agent bill spikes, the instinct is to switch to a cheaper or faster model. HarnessMM suggests checking the harness first: how many of your reasoning calls were deciding something already decided?

How YOU can use it

You do not need to install the research code to start saving tokens today. Here is the practical version:

Step 1: Count your redundant reasoning calls. Log one week of agent runs and tag each reasoning call: did it decide something new, or did it re-derive an action the previous call had already fixed? In most coding harnesses the second category is the majority. That ratio is your HarnessMM opportunity — if half your calls are re-derivations, your bill is roughly twice what it needs to be.

Step 2: Make your agent pre-commit the plan with guards. This is the single highest-value habit from the paper, and it works with any agent today. Ask for the whole chain up front, with the condition for each step stated explicitly. The prompt template below is illustrative — it is the shape of the discipline, not the paper's code:

Before you execute anything, write the full plan as steps with guards:

1. ACTION: write the fix in auth.py
   GUARD: none — execute now.
2. ACTION: run pytest tests/test_auth.py
   GUARD: step 1 completed without error.
3. ACTION: run the full test suite
   GUARD: step 2 exit code is 0.
4. ACTION: summarise the result to me
   GUARD: step 3 finished, pass or fail.

Rule: if a step's guard is satisfied, execute it immediately.
Do NOT call reasoning again to re-decide a step whose
action and arguments are already written above.
Only stop and reason if a guard FAILS or a result is
unexpected.

Step 3: Build the guard check into your own scripts. If you run agents through your own tooling, the miniature version of an Executable Decision Graph is a few lines of code. The sketch below is illustrative — it shows the shape of a guard-gated executor, not the paper's implementation:

# Guard-gated executor: the HarnessMM idea in miniature
# (Illustrative sketch — not the paper's code.)
plan = [
    {"action": "compile", "args": ["main.py"],
     "guard": lambda r: r["write_ok"]},
    {"action": "run_tests", "args": ["tests/"],
     "guard": lambda r: r["compile_exit"] == 0},
]

results = {"write_ok": True}
for step in plan:
    if step["guard"](results):
        # execute directly — no reasoning call to re-decide
        results.update(run_tool(step["action"], step["args"]))
    else:
        # guard failed: THIS is when reasoning earns its keep
        results.update(reason_and_recover(step, results))

Step 4: Apply the Substitution Paradox test before you optimise. Every shortcut you add — a cache, a fast router, a pre-computed plan — must remove a reasoning call, not sit on top of it. If your "optimisation" still lets the model re-think the step afterwards, you have added cost, not removed it. Audit for the deleted call, not the added feature.

Step 5: Try the real thing. Clone https://github.com/YuhuaJiang2002/HarnessMM and run it against your own harness on a small benchmark first — the paper's own evaluation was 98 HumanEval tasks, so a comparable smoke test is cheap. Measure tokens per task and success rate before and after, exactly as the paper does. If your harness is the DeepSeek-style kind that re-reasons after every tool result, expect the biggest win.

Key takeaways

• Agent harnesses waste most of their tokens re-thinking decisions they already made — reasoning after every tool result, even when the next action was already fixed.
• HarnessMM stores resolved decisions in Executable Decision Graphs with guards, reuses them when tool feedback satisfies the guard, and deletes the redundant reasoning callback — nothing else changes, not even the model weights.
• On HumanEval: Codex kept 90.82% success with 29.54% fewer tokens (66.72k → 47.02k); DeepSeek Harness improved from 71.43% to 85.71% success with 87.93% fewer tokens (96.28k → 11.62k).
• The Substitution Paradox is the rule to remember: a shortcut only saves money if it actually removes a reasoning call.
• Your move today: make your agent pre-commit plans with guards, and stop paying it to re-decide what it already decided.

Read the original paper: HarnessMM: Recursive Self-Improvement for Harness Token Efficiency (arXiv:2610.32813) by Yuhua Jiang, Chang Xu, Feifei Gao and Li Zhao. Link: https://arxiv.org/abs/2610.32813 — code: https://github.com/YuhuaJiang2002/HarnessMM