← all writing
02 · 06 Aug 2026 · 6 MIN READ

Kill the Run, Keep the Diff: A 0.6B Monitor That Knows When Your Coding Agent Is Losing

Most of what showed up in this morning's arxiv list is about making coding agents smarter. This one is about making them quit earlier. A group out of SMU posted a two-stage controller that watches a running SWE agent, predicts from the trajectory prefix alone that it is going to fail, kills it, and then hands the dead run's diff to a fresh attempt as an optional tool. My thesis after reading it: the abort button is the most under-designed surface in every agent harness I have built.

What it does

FailFast-RestartSmart splits the problem in two. FailFast is the monitor: a 0.6B Qwen3 backbone, LoRA-adapted on attention and MLP projections, with linear heads over the pooled last-token hidden state. Its input is the task [ISSUE] plus a [WINDOW] of the last eight steps of thought, action and observation, with a persistent pin of the most recent patch-producing step. What it deliberately does not consume is policy logits or hidden states from the agent model. That constraint is the whole deployment story — a monitor that reads only observable text can sit in front of a closed API you have no access to. Training uses terminal supervision (did the run resolve) plus dense fail-to-pass and pass-to-pass progress targets, obtained by replaying the agent's bash commands and evaluating the intermediate patches.

RestartSmart is what happens on alarm. The run is killed and a fresh same-policy rollout starts with no prompt history at all. But the interrupted repository state is not thrown away: they replay the aborted trajectory's bash commands, capture git diff HEAD after each, and mount the result as a removable, git-apply-backed tool that the new agent can inspect, apply, or revert. The detail that makes the paper is that the overlay starts off. They explicitly refuse to splice the diff into the prompt, because that would anchor the fresh attempt to the reasoning that just failed. The setup is mini-swe-agent on SWE-bench Verified, 500 instances split 350/50/100, with 1,111 independent runs across four policies: Qwen3.5-9B, Qwen3.6-27B, Gemma4-31B, and Gemini 3 Flash.

The key result

At a 5% false-positive target the monitor saves 14.6–20.4% of execution tokens across all four policies — and it was trained exclusively on Qwen3.6-27B trajectories, then transferred to the others with no weight updates, including the closed-API model. On its home policy the 20.4% saving beats their per-step AgentStop adaptation at 12.5% and a plain duration heuristic at 11.4%. The more interesting number is at the other operating point. Push the false-positive target to 25% and RestartSmart lifts Qwen3.6-27B resolve from 66.6% to 71.8%, +5.2 points. Cold restart, firing on exactly the same alarms, manages +0.2 to +1.4. The restart is not what helps. The diff is.

Why it matters

The false-positive threshold turns out to be a business knob, and the same controller is two different products depending on where you set it. At 5% you are running a cost lever: kill the obvious losers, leave anything borderline alone, bank a fifth of your token spend. At 25% you are running a quality lever: be trigger-happy, because a wrong abort only costs you one restart, and a right abort buys a second attempt that inherits the work the first one did. Almost no harness in production has an abort policy in this sense. What we have is a step cap or a token cap, and a duration heuristic is the weakest baseline in their table. If you run agents in CI, or behind a queue, or as fan-out sub-agents, this is a controller you can genuinely build — a small classifier trained on your own trace logs, which you already have sitting in storage.

The overlay-off default is the part I would steal for sub-agent architectures. We keep relearning that feeding a failed attempt's context into the next attempt poisons it; that is the same lesson the multi-agent scaffolding work has been circling with context poisoning. What this paper does is cleanly separate the artifact from the reasoning. The diff is state. The transcript is a story about the state, told by something that was wrong. Only one of those is worth carrying across the retry boundary, and the +5.2 versus +1.4 gap says essentially all of the value lives in the artifact. Concretely: if you have a retry loop that summarizes the failure into the next prompt, that summary is probably costing you. Give the next attempt a clean working tree plus a patch it is free to look at and free to ignore.

The caveats

The takeaway

Two things go in the file. First, abort policy is a design surface with real headroom, and a step cap is not an abort policy. Second, and the one I will actually act on: when an agent run dies, the working tree and the transcript have completely different value, and most retry logic I have written treats them as a single blob to summarize and pass along. I am going to stop doing that — fresh context, clean prompt, and the previous attempt's patch mounted as something the new run can choose to open.


Working on something similar?

Say hello — I read every email.