Technisches Resümee: CodeRescue: Budget-kalibrierte Recovery-Routing für Coding-Agenten

1. Problemformulierung

Die Arbeit adressiert die Herausforderung beim Einsatz von Coding-Agenten, die in ausführbaren Umgebungen operieren, in denen fehlgeschlagene Versuche handlungsrelevante Rückmeldungen (z. B. Compiler-Fehler, fehlgeschlagene Tests, stderr-Traces) statt nur falscher Ausgaben generieren. Bestehende kostenbewusste Systeme behandeln das Scheitern eines Modells typischerweise als binäre Entscheidung: sofort zu einem stärkeren, teureren Modell eskalieren.

Die Autoren argumentieren, dass dieser Ansatz für das Programmieren suboptimal ist, da das Ausführungs-Feedback weitere Versuche durch ein günstiges Modell lohnenswert machen kann. Dies führt zu einer budgetierten Deployment-Frage: Wenn ein Agent scheitert, sollte er mehr günstige Rechenleistung aufwenden, um die Lösung zu reparieren (Reflect), oder neu zu planen (Replan), oder sollte er an ein stärkeres Modell eskalieren?

Das Problem wird als Post-Failure-Recovery-Routing formuliert. Nach einem gescheiterten ersten Versuch eines günstigen Modells muss das System zwischen drei heterogenen Aktionen wählen:

1. Reflect (Reflektieren): Die bestehende Lösung unter Verwendung des Ausführungs-Feedbacks überarbeiten.
2. Replan (Neu planen): Eine frische Lösung basierend auf einem anderen Plan mit dem günstigen Modell generieren.
3. Escalate (Eskalieren): Das Problem (inklusive Feedback) an ein stärkeres, teureres Modell delegieren.

Das Ziel ist es, die Lösungsrate zu maximieren, unterliegt dabei jedoch einem benutzerdefinierten mittleren Recovery-Budget ($B$), ohne die Policy für jedes neue Budget-Constraint neu trainieren zu müssen.

2. Methodik

2.1 Supervised Recovery Router

Die Kernkomponente ist ein Supervised Router, der auf Offline-Execution-Rollouts trainiert wurde.

• Input: Ein Recovery-Kontext $x = (q, v_0, e_0)$, bestehend aus der Aufgabenstellung, dem Ausführungsurteil und dem stderr-Trace.
• Labeling: Für jeden fehlgeschlagenen Fall wird das „Oracle“-Label als die günstigste erfolgreiche Aktion ($a^\dagger$) unter der Menge der Aktionen definiert, die den Fall lösen ($S(x)$). Fälle, in denen keine Aktion erfolgreich ist, werden ausgeschlossen.
• Training: Ein Sprachmodell (z. B. Qwen3.5-4B) wird mittels Cross-Entropy darauf feinjustiert, die günstigste erfolgreiche Aktion vorherzusagen. Der Router bewertet Aktionen basierend auf Log-Wahrscheinlichkeiten und normalisiert diese via Softmax.

2.2 Cost-Regularized Policy

Um ein Deployment unter variierenden Budgets ohne erneutes Training zu ermöglichen, führen die Autoren eine Kostenstrafe $\lambda \ge 0$ ein. Die Policy $\pi_\lambda(x)$ wählt die Aktion, die folgendes maximiert:
$$s_\theta(a | x) - \lambda c(a, x)$$
wobei $s_\theta$ der Score des Routers ist und $c(a, x)$ die geschätzten Deployment-Kosten darstellt.

• Mit steigendem $\lambda$ verschiebt sich die Policy hin zu günstigeren Aktionen (Reflect/Replan).
• Dies erzeugt eine diskrete Menge von Betriebspunkten (eine Kosten-Qualitäts-Frontier), die aus einem einzigen trainierten Router abgeleitet werden.

2.3 Conformal Budget Calibration (CRC)

Um das passende $\lambda$ für ein spezifisches Benutzerbudget $B$ mit statistischen Garantien auszuwählen, wenden die Autoren Conformal Risk Control (CRC) an.

• Mechanismus: Unter Verwendung eines gehaltenen Kalibrierungssets von fehlgeschlagenen Instanzen berechnet das System den empirischen mittleren Kostenwert für verschiedene $\lambda$-Werte.
• Selektionsregel: Es wählt die am wenigsten restriktive Strafe $\hat{\lambda}$, sodass die endliche Stichproben-Budget-Bedingung erfüllt ist:
  $$\frac{n \hat{C}_n(\lambda) + c_{\max}}{n + 1} \le B$$
  wobei $c_{\max}$ eine bekannte Kostenobergrenze ist und der additive Term eine Leave-one-out-konforme Korrektur bereitstellt.
• Garantie: Unter der Annahme der Austauschbarkeit garantiert dieses Verfahren, dass die erwarteten mittleren Recovery-Kosten der eingesetzten Policy auf zukünftigen Testdaten den Wert $B$ nicht überschreiten. Entscheidend ist, dass diese Garantie für die Kosten gilt, nicht für die Lösungsrate, was nicht-monotone Erfolgsmuster über Aktionen hinweg ermöglicht.

3. Zentrale Beiträge

1. Post-Failure Recovery Routing: Die Arbeit formuliert die Recovery eines Coding-Agenten als Routing-Problem über heterogene Aktionen (Reflect, Replan, Escalate) statt als einfachen Kaskaden-Übergang zu einem stärkeren Modell.
2. Budget-kontrollierbares Deployment: Es wird ein CRC-kalibrierter Kosten-Penalty eingeführt, der es ermöglicht, einen einzigen trainierten Router an mehreren Budget-Punkten einzusetzen, wobei die erwarteten Kosten marginal kontrolliert werden, was das Retraining für unterschiedliche Budget-Constraints überflüssig macht.
3. Empirische Recovery-Trade-offs: Die Studie liefert empirische Belege dafür, dass günstige Recovery und Modell-Eskalation komplementäre Erfolgsmuster aufweisen (d. h. einige Fehler sind nur durch günstige Aktionen lösbar, andere nur durch Eskalation und einige durch beides), was eine diskrete Kosten-Qualitäts-Frontier bildet.

4. Experimentelle Ergebnisse

Das System wurde auf fünf Coding-Benchmarks (APPS, TACO, BigCodeBench, LiveCodeBench, CodeContests) unter Verwendung von GPT-5.4-NANO als günstiges Modell und GPT-5.4 als starkes Modell evaluiert.

• Router-Effektivität: Ein gelernter Router schneidet signifikant besser ab als Fixed-Action-Baselines. Der unbeschränkte gelernte Router erreichte eine Lösungsrate von 81,7 % bei mittleren Kosten von 5,51 m$, verglichen mit 68,6 % für „Always-Escalate“ bei 7,22 m$.
• Komplementarität: Die Analyse der „Oracle“-günstigsten Aktionen zeigte, dass 28 % der Fehler nur durch günstige Aktionen lösbar waren, 45 % nur durch Eskalation und 27 % durch beides. Diese Heterogenität rechtfertigt den Einsatz eines Routers gegenüber einer festen Kaskade.
• Budget-Kalibrierung: Die CRC-kalibrierte Frontier zeigte, dass das System bei einem Budget von 2,56 m$ eine Lösungsrate von 71,7 % erreichte. Dies übertraf die „Always-Escalate“-Baseline (68,6 %), während es nur 35 % der mittleren Kosten der Always-Escalate-Strategie verbrauchte.
• Baselines: Der gelernte Router übertraf Prompt-only-Router (Zero-Shot-LLMs, die als Router fungieren) sowie binäre Kaskaden-Baselines, was bestätigt, dass das Routing-Signal das Lernen aus Rollouts und nicht nur Prompt-Engineering erfordert.

5. Bedeutung und Behauptungen

Die Arbeit behauptet, dass die Behandlung von Coding-Fehlern als ein diagnostisierbares Reparaturproblem statt als einfacher Kapazitätsmangel eine effizientere Ressourcenallokation ermöglicht. Durch die Entkopplung des Trainings des Routers vom Deployment-Budget via CRC bietet das System einen praktischen Mechanismus für budgetkontrollierte Inferenz.

Die Autoren betonen, dass ihr Ansatz nicht beansprucht, die Lösungsrate konform zu kontrollieren; vielmehr bietet er eine Kosten-Garantie, während die Verbesserungen der Lösungsrate empirischer Natur sind. Die Arbeit legt nahe, dass für Coding-Agenten der „günstigste nützliche nächste Schritt“ oft nicht das stärkste Modell ist, sondern eine spezifische Recovery-Aktion, die auf den Fehlermodus zugeschnitten ist, und dass diese Entscheidung dynamisch unter strikten Budget-Constraints getroffen werden kann.

Vom Autor angemerktes Limit:

• Die Recovery wird als eine einzige Post-Failure-Entscheidung modelliert, während reale Agenten über mehrere Runden iterieren können.
• Das „günstigste erfolgreiche“ Label ist ein Proxy und keine kalibrierte Wahrscheinlichkeitsschätzung.
• CRC kontrolliert die erwarteten Kosten, nicht die Lösungsrate, was bedeutet, dass Qualitätsverbesserungen rein empirische Beobachtungen bleiben.