The abstract of the PAUSE paper says steering raised resolution by 16.8% on SWE-bench Verified. The tables say 16.8 percentage points, from 45.4% to 62.2%. The intro quotes SWE-agent at 14.8%, which is also points. I would not normally open a post on a unit slip, but it tells you how to read this paper: trust the tables, ignore the adjectives, and check every comparison for significance.
With that done, the idea is still one of the cheaper steering tricks I have seen. In PAUSE: Search-Free Steering of Coding Agents Before Their First Source-Code Edit, Patel, Tan, Xue and Sun intercept the agent's first edit request, hand the transcript so far to a separate Planner model, and inject one repair plan. Then they get out of the way.
One interception, at the moment the agent is most informed and least committed#
The authors measured where the first source-code edit lands in a trajectory: a median of 60% of the way through, after the agent has explored, reproduced the bug and run tests. Their argument for that spot is short:
an earlier intervention gives the Planner too little of the investigation to ground a plan
and a later one arrives after the agent has built on its own changes, which the plan must then overturn. I find that convincing as design reasoning. It is also testable, but I only saw the 60% median reported for Qwen3-coder on Verified, so the timing claim rests on one model.
The mechanics are simple:
The harness blocks the first source-code file-editor call before it executes.
The Planner reads the task and the history up to that point, without the pending edit, and writes one plan.
The plan is appended as a user message to the same Executor conversation. Context and workspace stay intact, and the interceptor switches off.
No learned monitor, no checkpoint search, no repeated advisor calls. PAUSE makes 0.93 Planner calls per task on Verified, against 2.33 for the rule-triggered LivePlan baseline.
The numbers, in points#
Executor is Qwen3-coder, Planner is GPT-5.6 Sol. Online results from the tables:
SWE-agent, Verified: 50.2% to 65.0%.
SWE-agent, Multilingual: 28.3% to 43.0%.
OpenHands, Verified: 45.4% to 62.2%.
Pi, Verified: 37.0% to 43.0%, the weakest gain at 6 points.
Offline, replaying a recorded prefix and resuming with the plan recovered 35.4% of 223 eligible failures with Qwen3-coder and 30.5% of 174 with Devstral-small. Resuming used 33 to 41% fewer Executor tokens than restarting from scratch, which is the part I would use first: you do not have to re-run the expensive investigation to try a better plan.
The cost story is the real headline, and the statistics are softer than it#
On SWE-agent Verified, the Planner bill was $26.13 for PAUSE and $231.71 for SICA, a periodic overseer. That is about 11%, or 15% on Multilingual. PAUSE was roughly level with SICA on accuracy and ahead of LivePlan by 3.2 and 3.7 points at similar cost.
Here is where I slow down. PAUSE against LivePlan has p=0.11 on Verified and p=0.18 on Multilingual. Against SICA it is p=0.18 and p=0.71. So "matches the expensive overseer for a ninth of the price" is a fair reading, and "beats the cheap advisor" is not established. The large gains over the unsteered baseline are the solid result.
Why the plan is a one-shot, and why that is a feature#
Most steering work I have seen keeps a second model in the loop: review every N steps, or call an advisor whenever a monitor fires. That is expensive, and silence from a monitor does not mean the agent is on track. PAUSE makes a different bet, that one well-timed plan carries most of the value. The cost table backs the bet up. Planner spend per task was between $0.037 and $0.052 across harnesses, which is small next to the Executor's own trajectory.
The flip side is that a wrong plan is also a single point of failure. The Executor still has to implement and validate it, and nothing corrects the plan afterwards. I would want to see how often a bad plan sends a previously solving agent the wrong way, and the paper's regression analysis, run once per task offline, only partly answers that.
What would break it in a real setup#
Edits through the shell get no intervention, because PAUSE keys on the file-editor request. In Pi, some source changes happened before the first edit call, so no plan was inserted, which probably explains its small gain. The Planner also cannot run commands or inspect the workspace, and the plan is never updated. The paper notes benchmark data may overlap with Planner training data, and the offline numbers use one run per task.
There is also a ceiling I would flag on my own: the Executor here is a mid-size open model. A stronger Executor has less headroom, and I would not assume gains of this size carry over.
Where I would try it#
If you run a harness with an edit hook, which Claude Code's pre-tool-use hooks resemble, the experiment is cheap: block the first Edit or Write, ask a stronger model for a plan from the transcript, inject it, log both arms. I would run it on your own failing tasks first. My bet is that the benefit concentrates on weaker Executors, and that the offline replay trick matters more than the online one for anyone paying for long trajectories.