/p/2026-08-06 · explainer
Paper explainer · 2608.03222 · Wang et al.

Kill the run
before it fails.

A coding agent that is going to fail usually fails slowly: the trajectory stretches, exploration starts looping, and tokens burn until it gives up. A 0.6-billion-parameter monitor reading nothing but the visible transcript — the issue text plus the last eight steps — calls the run doomed mid-flight, saving 14.6% to 20.4% of execution tokens at a 5% false-alarm rate, and transferring unchanged from the policy it was trained on to three others including a hosted model. Restarting on that alarm with a clean context but the abandoned diff still on offer lifts issues resolved from 66.6% to 71.8%, where restarting from nothing reaches 66.8%.

01 · The problem

Failure is slow, and slow is what you pay for

The asymmetry that makes this worth building: a run that succeeds tends to be short, and a run that fails tends to be long. It reads a file, tries a patch, the tests still fail, it reads another file, tries again, and the context grows more expensive per step the whole time. By the end you have paid the maximum price for the minimum outcome. The claim tested here is that the doom is visible from the transcript well before the run admits it. Scrub through a trajectory and watch the monitor's score climb. illustrative trajectory

Interactive · scrub the trajectorythe failure signature the paper describes, on a generic run
tokens spent so far
of the run still ahead

Two things about this deserve emphasis. Early termination is not free: an interrupted trajectory may have been about to succeed, and it may also contain repository edits that were genuinely good. Any stopping rule therefore has to be judged on both axes at once — tokens saved and tasks still resolved — which is exactly why the paper reports two operating points rather than one number.

02 · The mechanism

A monitor that reads only what you could read

The design constraint is the whole reason this is usable. The monitor never touches the policy's logits or hidden states — it sees the issue text, the last eight steps of thought, action and observation, and a persistent pin to the most recent step that produced a patch, so the current diff never scrolls out of view. That is a 0.6-billion-parameter model adapted with low-rank fine-tuning on a frozen backbone, small enough to run beside the agent for a rounding error. Because the input is text a hosted model also emits, the same monitor works on a policy whose internals you cannot see at all. Step through what it is trained on.

Interactive · the three headstap a supervision signal

    

The dense supervision is the part worth stealing even if you never build the monitor. Rather than training only on whether the run eventually passed — one label per trajectory, arriving hours late — the authors replay each prefix's shell commands in a fresh container and score the intermediate patch against the real evaluator, so every prefix gets its own label. That turns a few hundred trajectories into tens of thousands of training examples, which is what makes a 0.6B model enough.

03 · The method

Throw away the context, keep the code

When the alarm fires, the naive move is to restart from nothing, and the paper measures exactly what that buys: almost nothing. The trajectory failed, but the edits it produced were not all worthless — the agent may have fixed a real thing on the way to getting stuck. RestartSmart separates the two: the fresh rollout gets no prompt history at all, and gets the abandoned repository diff as an optional, unverified overlay it can look at, apply, or throw away. The overlay starts disabled. Tap through what the restarted agent can do with it.

Interactive · the overlay commandstap a command

      
inherited context
inherited code
Issues resolved after an alarm25% false-positive target · three policies
406080%

Cold restart — same alarm, same fresh rollout, no overlay — reaches 66.8% against a 66.6% baseline on the strongest policy. With the diff on offer it is 71.8%. Nearly the entire gain comes from the inherited edits, not from the stopping rule.

04 · The proof

Two operating points, two different products

One knob decides what this system is. Tune the alarm to fire rarely — a 5% false-positive target — and it is a cost control: it kills a minority of runs, almost all of them genuinely doomed, and saves a sixth to a fifth of your token spend. Open it up to 25% and it becomes a quality control: it interrupts far more runs, some of which would have succeeded, but the restarts recover more than the false alarms cost. You do not get both from the same setting. Switch the bars.

Interactive · switch the operating pointfour policies · one monitor, trained on one of them
0

The transfer is the load-bearing result. The monitor was trained on trajectories from one open policy and then applied, with no weight updates, to two other open models and one hosted model — and it still saved 14.6% to 16.0% on the three it had never seen. If the doom signature were policy-specific you would expect that number to collapse; it does not.

05 · In your stack

What the knob is worth on your volume illustrative

The measured rates are per-run percentages, so pointing them at your own throughput is straightforward arithmetic. Pick a policy, set how many agent runs you fire a month, and move the false-alarm dial between the two measured settings. The savings and resolution figures come from the paper; the multiplication by your volume is illustrative, and the middle of the dial interpolates between two measured points rather than reporting a third.

Interactive · your throughput at the paper's measured ratesper-run rates measured · the arithmetic is illustrative
runs the monitor stops
execution tokens you keep

The numbers

What the paper actually reports

What this does not show

In practice