OpenClaw schärft die Diagnose für Streaming-Modelle

OpenClaw hat am 26. Mai 2026 PR #86504 geschlossen. Laut Pull Request behebt der Patch einen Diagnosefehler bei gestreamten Modellaufrufen: Eingehende Chunks wurden bisher nicht als Fortschritt gezählt, wodurch die aktive Abort-Recovery gesunde Streaming-Calls fälschlich als festgefahren behandeln konnte.

Das betrifft keinen exotischen Randfall. Lange Modellantworten, lokale Provider, selbst gehostete Backends und langsamere Calls gehören zum Alltag vieler Agenten-Runtimes. Die Diagnose muss deshalb sauber unterscheiden: Hängt ein Modell wirklich, oder arbeitet es weiter und liefert nur länger Token?

Der Fehler: Ausgabe lief, Diagnose sah Stillstand

Nach Angaben im Pull Request lag das Problem nicht darin, dass Streaming-Modelle keinen Fortschritt machten. Der Fortschritt kam nur nicht bei der Diagnose an. Gestreamte Antwort-Chunks aktualisierten den Diagnosezustand nicht, deshalb konnte die Stuck-Session-Erkennung einen laufenden Modellaufruf als blockiert einstufen.

Der Fix setzt an dieser Stelle an: Modell-Stream-Chunks zählen nun als Diagnose-Fortschritt. Die PR beschreibt, dass lange Streaming-Calls frisch bleiben, solange sie aktiv Output produzieren. Gleichzeitig bleibt die Recovery für wirklich stille Aufrufe aktiv, einschließlich stream: false-Calls.

Das ist die entscheidende Trennlinie. Eine Agenten-Runtime darf nicht jede lange Modellantwort als gesund durchwinken, nur weil sie von einem lokalen oder selbst gehosteten Provider kommt. Sie darf aber auch keinen laufenden Stream abbrechen, während sichtbar Arbeit passiert.

Warum OpenClaw keine pauschale Local-Ausnahme setzt

Der Pull Request beschreibt ausdrücklich, dass der Fix nicht auf einer generellen Ausnahme für lokale Provider basiert. OpenClaw beobachtet stattdessen tatsächlichen Stream-Fortschritt. Lokale und entfernte Streaming-Provider sollen Chunks oder vergleichbare Fortschrittssignale liefern; wenn sie das tun, erkennt die Diagnose, dass der Call weiterläuft.

Für Agenten-Builder ist das ein kleiner, aber wichtiger Unterschied. Eine pauschale Ausnahme für lokale Provider würde echte Stalls verdecken. Fortschrittsbasiertes Tracking hält die Abort-Recovery dagegen nutzbar: Stille oder nicht streamende Modellaufrufe bleiben nach dem konfigurierten Stuck-Session-Timeout abbrechbar.

Die PR nennt außerdem eine Drosselung der nach außen sichtbaren run.progress-Events. Intern wird die Diagnoseaktivität bei jedem Chunk aktualisiert, aber Beobachter sollen nicht mit Token-Stream-Ereignissen zugespammt werden. Gerade bei längeren Antworten verhindert das, dass Diagnose-Signale selbst zu Rauschen werden.

Was sich im Code geändert hat

Laut GitHub fasst PR #86504 sechs Dateien an, mit 327 hinzugefügten und 39 entfernten Zeilen. Betroffen sind unter anderem Diagnose- und Runner-Dateien wie diagnostic-run-activity.ts, diagnostic.ts, attempt.model-diagnostic-events.ts und llm-idle-timeout.ts sowie zugehörige Tests.

Die Beschreibung nennt fünf konkrete Änderungen: OpenClaw emittiert Stream-Fortschritt aus dem Modell-Diagnose-Wrapper, aktualisiert die In-Memory-Diagnoseaktivität pro Chunk, drosselt externe Fortschrittsereignisse, hält Abort-Recovery für stille lokale und entfernte Calls aktiv und überspringt Stream-Progress-Bookkeeping, wenn Diagnostik deaktiviert ist.

Auch die Testabdeckung wurde erweitert. Der Pull Request nennt Regressionstests für Stream-Fortschritt, stille lokale Modellaufrufe und deaktivierte Diagnostik. Als beobachtetes Ergebnis nach dem Fix wird angegeben, dass gestreamte Chunks lastProgressReason auf model_call:stream_progress setzen, während wirklich festgefahrene Calls weiterhin klassifiziert und zurückgeholt werden können.

Die Betriebsgrenze bleibt: Stille Streams werden abgebrochen

Der Fix entfernt nicht jedes Risiko rund um lange Modellaufrufe. Der Pull Request benennt selbst den wichtigsten Grenzfall: Ein Provider kann eine Streaming-Anfrage öffnen und dann länger als das Stuck-Session-Timeout still bleiben. Dieses Verhalten bleibt absichtlich abbrechbar.

Das ist sinnvoll, verschiebt aber Verantwortung in die Provider- und Deployment-Schicht. Wer lokale Modelle, vLLM-artige Server oder andere selbst gehostete Backends betreibt, sollte nicht nur „Streaming an“ setzen, sondern prüfen, ob während langer Antworten tatsächlich Chunks oder vergleichbare Fortschrittssignale kommen. Sonst sieht die Runtime weiterhin einen stillen Call und behandelt ihn entsprechend.

Die PR nennt als ursprüngliches Repro-Szenario einen langen lokalen LM-Studio/vLLM-ähnlichen Modellaufruf mit stuckSessionWarnMs=2000 und stuckSessionAbortMs=6000. Der vollständige Live-Repro wurde nach dem Patch laut PR nicht erneut ausgeführt; gemeldet wurden gezielte Unit- und Regressionstests für das geänderte Diagnoseverhalten.

Was Agenten-Setups daraus lernen können

Für OpenClaw-Nutzer ist der Fix vor allem ein AgentOps-Signal: Diagnose darf nicht nur messen, ob ein Prozess noch lebt. Sie muss semantischen Fortschritt erkennen. Bei Modellaufrufen ist ein ankommender Stream-Chunk ein stärkeres Lebenszeichen als ein offener HTTP-Request.

Gleichzeitig zeigt der Patch, warum automatische Recovery nicht komplett deaktiviert werden sollte, nur weil ein Provider lokal läuft. Lokale Modelle können genauso hängen wie entfernte APIs. Eine robuste Runtime braucht deshalb beides: Geduld bei echten Streams und klare Abbruchregeln bei Schweigen.

Für produktive Setups heißt das: Lange Antworten werden weniger anfällig für Fehlabbrüche, solange der Provider Fortschritt liefert. Wer selbst hostet, sollte die Diagnosekonfiguration bewusst setzen und neue Modellserver testen, bevor sie produktiv laufen. Besonders relevant ist die Phase, in der der Request schon offen ist, aber noch kein Token zurückkommt. Dort entscheidet sich, ob Abort-Recovery ein Sicherheitsnetz bleibt oder produktive Arbeit versehentlich abschneidet.

Mehr Kontext zum aktuellen OpenClaw-Stand sammelt die laufend gepflegte OpenClaw-Statusseite.