A coding agent fails a test. The orchestration layer immediately sends the same task to the most expensive model available.
That can be the right move. It should not be the automatic one.
The failed run produced evidence: a compiler error, a failing assertion, an execution trace, a tool fault, or a boundary case the original plan missed. The task is no longer in its original state. The system now has to decide what that evidence means and which next action—if any—is worth its cost.
An identical retry ignores that change. It repeats materially the same attempt without a new reason to expect a different result. A corrected retry uses the failure signal to change the context, implementation, plan, environment, or model capability.
That distinction turns coding-agent recovery into a routing problem.
Failure creates a new decision state
A common implementation pattern makes the first routing decision before execution: choose a model, assemble context, expose tools, and set a budget. After failure, the policy can collapse into one of two defaults:
- run the same thing again;
- send everything to a stronger model.
Both policies discard information.
A failed execution can tell you that the model misunderstood a requirement, lacked a repository fact, chose a brittle approach, encountered a broken tool, or reached a problem beyond its current capability. Those conditions call for different interventions. More inference does not repair a missing dependency. More context does not fix a broken test harness. A cheaper model can repair a local off-by-one error, while a harder algorithmic gap may justify immediate escalation.
The mature question is not, “Which model should get the retry?”
It is, “Which intervention now has enough expected value to justify its marginal cost?”
What CodeRescue adds to the evidence
The CodeRescue preprint gives this problem a useful experimental shape. The authors model one decision after a cheap coding attempt fails. Their router receives the problem statement, execution verdict, stderr, and metadata, then chooses among three actions:
- reflect: ask the lower-cost model to repair its answer using execution feedback;
- replan: ask the lower-cost model to start again from a fresh plan;
- escalate: send the problem and feedback to a stronger model.[^1]
That action set matters because every route changes a material condition. Reflect changes the evidence available to the next attempt. Replan changes the strategy. Escalation changes the available capability. Pressing run again without one of those changes is not one of the tested recovery actions.
The paper also reports complementary success patterns. Across the held-out GPT failures that at least one recovery action could solve, some were solved only by lower-cost recovery, some only by escalation, and some by either route.[^1] That is a stronger operating signal than “cheap is better” or “stronger is safer.” Different failures favor different interventions.
In the authors’ primary setup, GPT-5.4-nano handled the lower-cost recovery actions, GPT-5.4 handled escalation, and a fine-tuned Qwen3.5-4B model routed among them. On a 360-example held-out test split drawn from failures across APPS, TACO, BigCodeBench, LiveCodeBench, and CodeContests, one calibrated operating point reached a reported solve rate of 0.717 at a mean recovery cost of 2.56 millidollars per example. Always escalating reached 0.686 at 7.22 millidollars.[^1]
Those numbers belong to that model pairing, filtered benchmark setup, and operating point. They are not a universal savings estimate for production coding agents.
The guarantee is about average recovery cost under the paper's exchangeability assumption. In plain language, future recovery cases need to resemble the examples used to calibrate the policy. It does not guarantee solve rate, cap the cost of an individual run, or establish production reliability.[^1]
The study is intentionally narrower than an operating system for real repositories. It models one post-failure choice, not a multi-round recovery trajectory. Its public code repository makes the authors’ implementation available, but it is not independent validation.
The useful conclusion is bounded: execution feedback can support a budget-aware choice among meaningfully different recovery actions.
The Recovery Budget Router
I extend that idea into a broader operating model: the Recovery Budget Router, a post-failure policy that classifies evidence, prices materially different interventions, and chooses whether to retry, repair, replan, escalate, or stop. This is my synthesis, not a framework proposed or validated by the CodeRescue authors.
The router has five stages:
- Classify the failure. Does the evidence point to missing context, a bad plan, a tool or environment fault, an implementation defect, or insufficient model capability?
- Extract the new evidence. What did execution reveal that was unavailable before the failed run?
- Enumerate changed interventions. Which actions would materially change the evidence, context, strategy, environment, or capability?
- Price the next attempt. What inference, tool, latency, and human-review budget remains? What outcome is still worth buying?
- Route or stop. Which action has enough expected value to justify its marginal cost? If none does, stop.
The router should be allowed to choose among six outcomes:
| Route | Use it when | Do not use it when |
|---|---|---|
| Corrected low-cost retry | The failure exposed a specific, local repair and the current model remains plausibly capable. | The next prompt and conditions would be materially identical. |
| Context repair | Required repository, task, dependency, or acceptance information was missing or malformed. | The trace points to a capability or environment fault instead. |
| Strategy change | The approach appears wrong, but a fresh plan may still make the task solvable at the current capability level. | The defect is local and already has a clear correction. |
| Tool or environment repair | The compiler, test harness, dependency state, permissions, sandbox, or another execution component caused the failure. | The environment is healthy and the generated solution is wrong. |
| Capability escalation | The evidence points to an algorithmic, reasoning, context-window, or tool-use demand the current model cannot resolve. | A lower-cost intervention still has credible expected value. |
| Stop | No intervention clears the expected-value threshold, or the remaining budget cannot buy a justified attempt. | A specific, safe correction still has credible value within budget. |
Stop has to be a real route. Otherwise a “budget” is only a meter attached to an unbounded retry loop.
Escalation has to be a real route too. A recovery policy designed to avoid expensive models at all costs is just another ideology. If the trace shows that the current model repeatedly fails to maintain a required invariant across a complex change, while the tools and context are sound, stronger capability may be the least expensive path to a correct result.
An identical retry and a corrected retry are different products
Consider an illustrative case: a coding agent implements a parser and fails an automated boundary-case test.
The error shows that an empty trailing field is being discarded.
An identical retry sends the same task and context back to the same model. Nothing in the attempt explains why the next sample should differ from the last one.
A corrected low-cost retry adds the failing input, expected output, and relevant parser function to the context. It asks for the smallest change that preserves the other cases. The failure has become a local repair signal.
A strategy change is appropriate if the parser was built from a chain of string splits that cannot represent escaped delimiters reliably. The next run should begin from a different parsing approach, not another patch on the same brittle plan.
A tool repair wins if the test command is loading the wrong fixture version. Changing the model would spend more money against invalid evidence.
Capability escalation wins if the task requires a nontrivial grammar transformation, the lower-cost model has already received correct context and feedback, and its revisions continue to violate the same structural constraints.
Stop wins if the expected value of further autonomous work falls below the cost or risk of handing the case to a human, narrowing the task, or deferring it.
The same failed test can therefore produce several legitimate routes. The route depends on the diagnosis, not on a universal model hierarchy.
Price recovery in more than tokens
Inference cost is the easiest number to collect, so it often becomes the whole budget. That is too narrow for an operating policy.
A recovery attempt can consume:
- model inference;
- tool and sandbox execution;
- queue time and user-visible latency;
- repository or environment capacity;
- human review;
- risk from another incorrect change;
- opportunity cost from delaying other work.
The router does not need a perfect dollar value for every item before it becomes useful. It does need consistent measurements and explicit tradeoffs.
For a low-risk internal task, another two-minute attempt may be cheap. For a change blocking a deployment, latency can dominate token cost. For a security-sensitive migration, the cost of an incorrect patch and its review burden can dominate both.
Expected value also includes the value of information. A small diagnostic run can be worthwhile even when it is unlikely to solve the task if it sharply distinguishes a context failure from a capability failure. The next decision becomes better because the action bought evidence, not just another answer.
Start with rules before training a router
CodeRescue trains a learned router from offline rollouts, labeling recoverable failures with the cheapest action that succeeded.[^1] Most teams do not need to begin there.
Start by making the post-failure state observable.
For each failed run, record:
failure_class:
verdict:
diagnostic_evidence:
material_change_for_next_attempt:
candidate_actions:
incremental_cost_by_action:
selected_action:
selection_reason:
outcome:
stop_condition:
Then write a small rule layer around the most obvious cases:
- authentication, dependency, or sandbox failures route to environment repair;
- a specific compiler or test diagnostic can permit one corrected retry;
- a structurally invalid plan routes to replanning;
- repeated failure after sound context and strategy can permit escalation;
- no material change or exhausted value routes to stop.
Do not assign a fixed retry count and call it a stopping rule. Two attempts can be too many when neither changes the conditions. Five can be rational when each cheaply removes a different uncertainty. The stop condition should follow remaining expected value, risk, and budget for the workload.
After enough routed failures accumulate, compare policy decisions with outcomes. Which classes were misdiagnosed? Which cheap interventions solved the task? When did escalation save time? Which actions created useful evidence even when they did not produce a solution? Where did the system continue after the economic case had disappeared?
That history is the beginning of a trainable recovery policy. It is also useful without one.
Make recovery policy explicit
Even as first-pass generation improves, production-minded infrastructure still has to govern what happens when a run fails.
The default should not be an identical retry. It should not be automatic escalation either. It should be a new decision made from new evidence.
The first implementation step is concrete: log the failure evidence, enumerate materially different recovery actions, record each action’s incremental cost, and define the condition under which the system stops.
Once those decisions are visible, recovery stops being an improvised loop. It becomes an operating policy you can measure, challenge, and improve.
[^1]: Qijia He et al., “CodeRescue: Budget-Calibrated Recovery Routing for Coding Agents”, arXiv:2607.19338v1, July 21, 2026. Preprint; paper states it is under review.