Retry-Loops: Warum freie Inferenz nicht den Kontrollpfad besitzen

Neuer Ansatz: Retry-Loops ohne Modellsteuerung

Der Kern des neuen Ansatzes: Freie Inferenzmodelle sollten den Retry-Loop nicht besitzen, da sie zusätzliche Risiken und Verzögerungen einführen. Stattdessen reichen Statuscodes, Idempotenzschlüssel und harte Budgets für Wiederholungsentscheidungen. Ein Retry-Loop, der vor jedem erneuten Versuch eine Inferenzanfrage stellt, sei keine Resilienz, sondern ein zweiter Ausfall, verzögert durch einen Modellaufruf, der stocken, abdriften oder sich selbst widersprechen kann. Statuscodes, Idempotenzschlüssel und ein hartes Budget entschieden bereits, ob Arbeit sicher wiederholt werden kann. Das Modell verbessere diese Entscheidung nicht, wenn es das unzuverlässigste Glied im Pfad ist. Live-Retries seien eine Kontrollflächen-Aufgabe: Sie duplizieren Seiteneffekte, verbrauchen nachgelagerte Kontingente und verlängern die nutzersichtbare Latenz. Freie Inferenz sei dagegen ein Best-Effort-Textgenerator. Beide Aufgaben teilten kein gemeinsames Service-Level-Ziel. Timeouts, 429-Antworten und Verbindungsabbrüche trügen bereits verstandene Codes; deren Abbildung über einen Completion-Endpunkt füge Tail-Latenz, Nichtdeterminismus und eine Abhängigkeit hinzu, die in derselben Fehlerklasse wie der ursprüngliche Aufruf ausfalle. Der Loop wiederhole dann sowohl die Arbeit als auch den Berater. Die Analogie: Ein Rauchmelder, der eine entfernte Zentrale fragt, ob der Rauch interessant ist, mache das Gebäude nicht sicherer, sondern es gebe mehr Rauch.

Kostenexplosion: Der OpenClaw-Vorfall als Warnung

Wie teuer unkontrollierte Retry-Loops werden können, zeigt ein Vorfall mit OpenClaw. Im Mai 2026 dokumentierte ein Bug-Report zwei Idle-Timeout-Vorfälle: Ein einzelner Fehler löste innerhalb von 60 Sekunden 761 beziehungsweise 1.384 Modellaufrufe aus. Der Reporter schätzte die Kosten auf etwa 30 Dollar pro Ereignis, bevor ein externer Monitor eingriff. OpenClaw integrierte am nächsten Tag einen Circuit-Breaker-Fix. Der Vorfall illustriert das Retry-Kostenproblem: Ein normaler Fehler wird zum Ausgabenereignis, weil nichts das System am erneuten Versuch hindert. Laut Bug-Report verarbeitete jeder Retry den vollen Session-Kontext, was hunderte oder tausende bezahlte Aufrufe erzeugte, bevor ein externer Monitor einschritt. Nicht jeder Agent sende bei jedem Retry einen wachsenden Vollkontext; das Kostenverhalten hänge von Architektur, Provider, Caching und Kontextstrategie ab. Doch jeder bezahlte Modellaufruf verbrauche Budget, und lange Agentenläufe mit großen Kontexten könnten wiederholte Aufrufe erheblich verteuern.

Die empirische Basis gegen modellbasierte Selbstreparatur liefert eine Studie zu Blind Resampling versus Self-Repair bei Code-Modellen. Auf MBPP+ verglich sie bei drei Modellgrößen (1,5B, 3B, 7B Parameter) vier Bedingungen mit gleichem Budget: blindes Resampling, eine inhaltsleere Fehlermeldung, echtes Ausführungsfeedback und Feedback mit verbaler Selbstreflexion. Blind Resampling war unter 7B Parametern die stärkste Bedingung und blieb bei 7B statistisch gleichauf mit der besten Bedingung, verbrauchte aber weniger Tokens. Die Konditionierung auf den eigenen fehlgeschlagenen Versuch kostete bei 1,5B Punkte; der Informationsgehalt von Ausführungsfeedback fügte gegenüber dem Placebo nichts Messbares hinzu. Die Autoren führen das auf Ankern zurück: Wird dem Modell sein vorheriger Versuch gezeigt, reproduziert es in vielen Retries ein nahezu identisches Programm, unter blindem Resampling deutlich seltener. Der Anker-Effekt bedeutet, dass das Modell durch den eigenen fehlgeschlagenen Versuch kognitiv verankert wird und dazu neigt, ähnliche Lösungen zu reproduzieren, statt neue Wege zu suchen. Blind Resampling vermeidet diesen Anker, indem es ohne vorherigen Kontext neu sampelt, was zu diverseren und häufiger korrekten Programmen führt. Das stellt die Effektivität modellbasierter Reparaturversuche bei kleinen Modellen infrage.

Kontext-Kontamination: Fehlerrate steigt um das 7,1-Fache

Eine Rutgers-Studie quantifiziert einen weiteren negativen Effekt von Retry-Schleifen: die Kontamination des Konversationsverlaufs. Bleibt der fehlgeschlagene Versuch im Verlauf, erbt der nächste Versuch einen kontaminierten Kontext. Die Fehlerrate pro Schritt steigt dadurch um das 7,1-Fache über den Ausgangswert. Das sei keine sanfte Degradation, sondern jeder weitere Retry arbeite in einer schlechteren Umgebung als der vorherige. Die Ökonomie sei brutal: Jeder Retry koste mehr Tokens als der letzte, weil der Kontext gewachsen ist, und sei zugleich wahrscheinlicher fehlzuschlagen, weil der Kontext vergiftet ist. Man zahle einen steigenden Preis für eine sinkende Erfolgswahrscheinlichkeit. Die Lösung sei nahezu trivial: Das Löschen des Kontexts vor einem Retry löse im selben Budget 21 Prozent mehr Aufgaben. Das Löschen des Kontexts entfernt den kontaminierten Verlauf und startet den Retry mit einem sauberen Kontext, wodurch die Fehlerrate wieder auf das Ausgangsniveau sinkt und die Erfolgswahrscheinlichkeit steigt. Die 21%ige Verbesserung ergibt sich aus demselben Budget, weil die Tokens nicht für die Verarbeitung des fehlgeschlagenen Versuchs verschwendet werden. Gleiches Geld, gleiches Modell, nur eine architektonische Entscheidung darüber, was der Agent weiterträgt.

Gegenposition: Begrenzter Loop mit Validierung als Systemmerkmal

Die Gegenposition hält einen kleinen, begrenzten Loop mit Validierung und Fehler-Feedback für notwendig. Jede Structured-Output-Pipeline brauche eine Antwort auf die Frage, was passiert, wenn die Ausgabe falsch ist. Die reife Antwort sei ein kleiner, begrenzter Loop: validieren, die Fehler als Instruktionen zurückspielen, erneut versuchen und schnell aufgeben. Das sei der Unterschied zwischen einer Demo und einem System. Das Muster umfasst etwa dreißig Zeilen Code: Ein Modellaufruf erzeugt einen Versuch, eine Validierung prüft Struktur und Typen, bei Fehlern wird ein formatiertes Feedback erzeugt und das Modell mit vorherigem Versuch und Feedback erneut aufgerufen. Die maximale Anzahl an Retries liege bei zwei oder drei; danach greife ein definierter Fallback. Entscheidend seien drei Entscheidungen: was validiert wird, wie Fehler formatiert werden und wie viele Retries erlaubt sind. Diese Sicht betont den Nutzen gezielter Korrekturen durch das Modell, solange der Loop strikt begrenzt bleibt.

Alternative: DSAP-Framework mit dreistufiger Hierarchie

Eine Alternative zum naiven Retry bietet das Dual-State Action Pair (DSAP) Framework. Es koppelt stochastische Generierung mit deterministischer Nachbedingungsprüfung und führt eine dreistufige Wiederherstellungshierarchie ein, um eine naive Retry-Explosion über mehrstufige Workflows zu verhindern. Die erste Stufe ist Kontextverfeinerung: ein Retry innerhalb des Schritts. Die zweite Stufe ist informiertes Backtracking: Stagnationserkennung mit kaskadierender Invalidierung und Kontextinjektion in vorgelagerte Schritte. Die dritte Stufe ist menschliche Eskalation. Das Framework wurde in einem Preprint vom 24. August 2026 beschrieben und experimentell über 13 LLMs mit 1,3 bis 15 Milliarden Parametern validiert; die Autoren berichten von Zuverlässigkeitsgewinnen von bis zu 66 Prozentpunkten bei 1,2- bis 2,1-fachen Basiskosten. DSAP ersetzt den unkontrollierten Loop durch eine strukturierte Hierarchie, die Eskalation erst dann vorsieht, wenn günstigere Wiederherstellungsversuche ausgeschöpft sind.

Abwägung: Wann lohnt sich Modellsteuerung im Retry?

Die Debatte um modellgesteuerte Retry-Loops offenbart einen grundlegenden Widerspruch. Die eine Position lehnt freie Inferenz im Kontrollpfad ab, weil das Modell das unzuverlässigste Glied sei und Live-Entscheidungen über Statuscodes, Idempotenzschlüssel und harte Budgets getroffen werden sollten. Die andere Position hält einen kleinen, begrenzten Loop mit Validierung und Fehler-Feedback für unverzichtbar, weil er gezielte Korrekturen ermögliche und eine Demo von einem System unterscheide. Der Unterschied liegt in der Bewertung der Modellzuverlässigkeit: Wer das Modell als unzuverlässigsten Teil betrachtet, lehnt es für Live-Entscheidungen ab; wer es als nützlich für gezielte Korrekturen ansieht, akzeptiert es, solange der Loop begrenzt ist. Die empirischen Befunde stützen Skepsis: Blind Resampling übertrifft Self-Repair bei kleinen Code-Modellen, und die Rutgers-Studie zeigt, dass ein im Kontext verbleibender Fehlversuch die Fehlerrate um das 7,1-Fache erhöht. Der OpenClaw-Vorfall belegt zudem die finanziellen Risiken unkontrollierter Loops. Für Live-Retries im Kontrollpfad spricht vieles dafür, deterministische Signale zu nutzen und das Modell nur nachträglich zur Fehleranalyse einzusetzen. Für strukturierte Ausgaben kann ein eng begrenzter Validierungsloop mit Fehler-Feedback sinnvoll sein, sofern Kontextkontamination vermieden und ein Fallback definiert wird. Das DSAP-Framework bietet dafür eine dreistufige Hierarchie, die Eskalation erst nach Ausschöpfung günstigerer Stufen vorsieht. Die informierte Entscheidung hängt damit vom Einsatzzweck ab: Kontrollpfad ohne Modell, Korrekturschleifen nur mit harten Grenzen und Kontextbereinigung.