Runaway-Loops verhindern (Teil 1)
Sie wachen auf, schauen ins Modell-Provider-Dashboard und sehen Tausende Dollar an API-Aufrufen von der letzten Nacht. Eine Schleife. Sie lief weiter, während Sie geschlafen haben.
Umfragen bei Engineering-Teams zeigen: Die meisten haben das schon erlebt. Durchschnittlicher Überziehung rund 7.200 $. Manche über 20.000 $. Bei frühen Startups hat eine einzige Schleife einige in den Ruin getrieben.
Die gute Nachricht: Sie sind größtenteils vermeidbar. Dieser Leitfaden erklärt Ursachen und Gegenmaßnahmen.
Was ist ein Runaway-Loop?
Ein Runaway-Loop ist jeder autonome Workflow, der in eine wiederholende Schleife von API-Aufrufen ohne eingebaute Ausstiegsbedingung gerät. Jeder Zyklus erzeugt mehr Aufrufe, mehr Tokens, mehr Kosten. Weil er autonom ist, kann er Stunden oder Tage laufen.
Häufige Arten:
- Retry-Loops – Tool-Aufruf schlägt fehl, Agent wiederholt endlos
- Workflow-Restart-Loops – Workflow schlägt fehl, Agent startet von vorn, wiederholt
- Verschachtelte Agent-Loops – primärer Agent startet sekundären, der weitere startet, Kaskade
- Halluzinations-Loops – Modell erfindet Tool-Aufruf oder Anfrage und versucht sie weiter zu erfüllen
- Kontext-Overflow-Loops – Kontext wächst jeden Zyklus, bis das Limit erreicht ist, Workflow startet neu, wiederholt
Sie alle verbrennen Ihr Budget ohne Mehrwert.
Warum sie entstehen
Die meisten Loops haben dieselbe Ursache: Teams optimieren nur den Happy Path.
Sie testen hauptsächlich den Fall, in dem alles funktioniert. Nutzer schickt klare Anfrage, Tools erfolgreich, Modell liefert gute Ausgabe, Workflow endet. Für Randfälle planen sie zu wenig: Was wenn ein Tool fehlschlägt? Wenn das Modell Müll zurückgibt? Wenn die API timeout? Wenn der Agent die Anfrage nicht erfüllen kann?
Teams bauen Retry-Logik ein, aber keine harten Limits, Circuit Breaker oder Exit-Bedingungen. Sie nehmen an, der Workflow wird irgendwann erfolgreich sein. Diese Annahme startet Loops.
Der 10k-Loop aus dem früheren Artikel entstand, weil Retries pro Aufruf limitiert waren, nicht pro Workflow. Nach 10 fehlgeschlagenen Versuchen startete der Agent den gesamten Workflow neu. Niemand hatte diese Absicherung ergänzt.
Schritt 1: Harte Retry-Limits auf jeder Ebene
Retry-Logik verursacht die meisten Runaway-Loops. Harte Limits stoppen sie.
Die meisten Teams limitieren nur Retries pro Tool-Aufruf. Sie brauchen Limits auf vier Ebenen:
- Pro Tool-Aufruf: max. 3 Retries. Nach 3 Fehlern schlägt der Aufruf fehl, der Workflow geht in Fehlerbehandlung – keine weiteren Retries.
- Pro Aktion: max. 2 Retries. Kann der Agent die Aktion nach 2 Versuchen nicht abschließen, Eskalation an Menschen.
- Pro Workflow: max. 1 Neustart. Scheitert der Workflow einmal, ein Neustart erlaubt. Scheitert er erneut, stoppen.
- Global: Obergrenze für Retries pro Stunde oder Tag. Erreicht → Retries für den Rest der Periode deaktiviert.
Diese auf Infrastrukturebene durchsetzen, bevor Aufrufe den Provider erreichen. Stehen sie nur im Agent-Code, können Bugs oder fehlerhafte Antworten sie umgehen. ClawFirewall setzt Retry-Limits auf API-Gateway-Ebene durch.
Schritt 2: Circuit Breaker für jeden Workflow
Ein Circuit Breaker stoppt einen Workflow, wenn ein Schwellenwert überschritten wird. Bei Auslösung: Workflow stoppt, keine weiteren API-Aufrufe, Eskalation. Nicht neu starten, bis jemand geprüft hat.
Sinnvolle Auslösebedingungen:
- Fehlerrate – z.B. >20 % Fehler in 10 Minuten
- Retry-Volumen – z.B. >10 Retries in 5 Minuten
- Token-Verbrauch – z.B. 2x Durchschnitt für einen Lauf
- Ausgaben – z.B. 10x Durchschnittskosten oder 50 % des Tagesbudgets
- API-Aufruf-Volumen – z.B. 5x durchschnittliche Aufrufe pro Minute
Auch wenn etwas Retry-Limits umgeht, kann ein Breaker die Schleife stoppen, bevor das Budget verbrennt. ClawFirewall bringt konfigurierbare Circuit Breaker mit.