OpenClaw stolpert bei Budget-Compaction über eine harte 60-Sekunden-Grenze

OpenClaw hat seit dem 21. Juni ein P1-Thema auf dem Tisch, das für Betreiber großer Sessions sofort relevant ist: Die budgetgetriggerte Preflight-Compaction bricht laut GitHub-Issue #95553 nach ungefähr 60 Sekunden ab, obwohl für diesen Pfad eigentlich ein längeres Compaction-Timeout greifen sollte. Der gemeldete Stand bezieht sich auf [email protected] und ist laut Issue weiterhin reproduzierbar.

Warum das heute wichtig ist, liegt nicht in einer unschönen Fehlermeldung, sondern im Ablauf davor: Genau an der Stelle, an der OpenClaw eine Session noch vor dem eigentlichen Overflow entschärfen will, verliert die Runtime erst Zeit und hält dabei auch noch die Session fest. Danach ist das Platzproblem oft nicht einmal gelöst.

Das Problem steckt in zwei ähnlichen, aber unterschiedlich getakteten Pfaden

Laut Issue unterscheidet OpenClaw zwischen Overflow-Recovery und Preflight-Compaction. Overflow-Recovery greift erst beim echten Überlauf und läuft dem Bericht zufolge mit einem deutlich längeren Budget. Die Preflight-Compaction springt früher an, sobald die Session gefährlich nah an die verfügbare Kontextgrenze rückt.

Genau dort kippt das Verhalten. Laut Beschreibung gewinnt auf diesem Vorab-Pfad nicht das konfigurierte Compaction-Timeout, sondern das Abort-Signal der laufenden Reply-Operation. In betroffenen Setups endet der Versuch deshalb regelmäßig nach rund 60 Sekunden. Im Issue steht ausdrücklich, dass compaction.timeoutSeconds auf diesem Pfad keine Wirkung zeigt.

Der praktische Effekt ist unerquicklich: Ein Schutzmechanismus, der Lastspitzen abfangen soll, produziert selbst neue Vorarbeit. Erst scheitert die Vorab-Compaction, dann bleibt die Session fast voll, und der nächste Turn kann trotzdem noch in die eigentliche Overflow-Recovery rutschen.

Die gemeldeten Laufzeiten machen den Fehler greifbar

Der Bericht ist hier ungewöhnlich konkret. Genannt werden 22 erfolgreiche Compactions mit Laufzeiten zwischen 54 und 954 Sekunden und einem Median von 278 Sekunden. Daneben stehen 26 unvollständige Läufe, davon 24 fast exakt bei 60 bis 61 Sekunden.

Gerade diese Verteilung macht den Fall interessant. Wenn erfolgreiche Compactions auf derselben Infrastruktur regelmäßig mehrere Minuten brauchen, ist eine harte Grenze bei ungefähr einer Minute nicht bloß knapp gewählt. Sie schneidet einen Teil der realen Arbeitslast systematisch ab. Laut Issue lief das auf Linux aarch64 mit einem Kontextfenster von 196608 Tokens und einem vLLM-Backend mit vllm/qwen3.6-fp8-fast.

Für andere Betreiber ist weniger die exakte Hardware entscheidend als das Muster: große Kontexte, eher langsame Self-Hosted-Modelle und Sessions, die schon vor dem eigentlichen Overflow in eine Vorab-Compaction laufen.

Der eigentliche Schaden zeigt sich im laufenden Betrieb

Laut Issue kostet jeder Turn oberhalb der Preflight-Schwelle erst einmal ungefähr eine Minute in Vorarbeit, bevor das Modell überhaupt antwortet. Dazu kommt der wichtigere Nebeneffekt: Während dieser Phase hält die Compaction den Session-Write-Lock. Der Report verknüpft das direkt mit SessionWriteLockTimeoutError und EmbeddedAttemptSessionTakeoverError bei konkurrierendem Traffic auf derselben Session.

Damit ist das nicht mehr nur ein Performance-Bug. In einer Einzelsession ist eine verlorene Minute lästig. In Cron-, Heartbeat- oder Multi-Worker-Setups kann dieselbe Minute dafür sorgen, dass Prozesse sich gegenseitig in die Quere kommen, obwohl das eigentliche Ziel der Compaction Stabilisierung wäre.

Genau deshalb bleibt von diesem Ticket mehr hängen als nur „Timeout falsch gesetzt“. Der Engpass erzeugt nicht nur Wartezeit, sondern verschlechtert unter Last auch das Verhalten der Session selbst.

Die naheliegenden Schalter helfen laut Bericht nicht sauber weiter

Auch die Workaround-Lage ist unschön. compaction.enabled: false würde zwar die problematische Vorab-Compaction abräumen, nimmt aber gleichzeitig auch die Overflow-Recovery weg. memoryFlush.enabled: false hilft laut Report ebenfalls nicht, weil dieser Schalter den Preflight-Pfad gar nicht deaktiviert.

Für betroffene Deployments heißt das: Wer heute auf dieses Muster läuft, hat keinen einfachen Weg, nur den riskanten Teil abzuschalten und den Rest der Schutzmechanik intakt zu lassen. Genau das macht den Fall operativ relevant.

Die offenen PRs zeigen Richtung, aber noch keine Entwarnung

Unter dem Issue hängen bereits mehrere Reparaturansätze. Ein ClawSweeper-Review vom 22. Juni hält das Ticket ausdrücklich offen und beschreibt es als zentralen Tracker für den Abort-Signal-Fehler. Nach dieser Einordnung reichen aktuelle Mainline und letzte Release das Reply-Abort-Signal weiterhin in die notwendige Preflight-Compaction durch.

Als ein Kandidat gilt PR #95590. Laut PR-Beschreibung soll ReplyOperation dort ein separates explicitAbortSignal bekommen. Die Idee dahinter: Preflight-Compaction soll nicht mehr am normalen Lifecycle-Timeout der Reply-Operation hängen, echte Stop- oder Restart-Abbrüche aber weiter respektieren.

Daneben steht mit PR #95648 ein anderer Ansatz im Raum. Dieser Vorschlag ergänzt laut Kommentar einen Schalter agents.defaults.compaction.preflight.enabled: false, der den Vorab-Pfad komplett überspringen würde. Das wäre weniger eine Behebung der Ursache als ein sauberer Notausgang für Setups, in denen große Compactions realistisch mehrere Minuten brauchen.

Beides ist Stand heute offen. Genau deshalb lohnt sich der Blick jetzt: nicht weil schon eine fertige Lösung da wäre, sondern weil das aktuelle Verhalten in produktionsnahen Umgebungen spürbar Zeit und Stabilität kostet.

Was Betreiber jetzt konkret prüfen sollten

Wer große Sessions oder langsamere Compaction-Modelle fährt, sollte die eigenen Logs auf ein recht klares Muster abklopfen: wiederkehrende Budget- oder CLI-Compaction-Fehler bei ungefähr 60 Sekunden, gefolgt von Overflow-Versuchen oder Lock-Fehlern auf derselben Session.

Noch wichtiger als die konkrete Infrastruktur ist die Form des Symptoms: Vorab-Compaction startet, läuft etwa eine Minute, bricht ab, und die Session bleibt trotzdem zu voll. Wenn das im eigenen Betrieb auftaucht, geht es nicht mehr um die Grundsatzfrage, ob Compaction sinnvoll ist. Dann geht es um die viel konkretere Frage, welcher Pfad gerade gewinnt und welches Timeout in der eigenen Runtime tatsächlich wirksam ist.

Der Kern des Problems ist damit ziemlich klar umrissen: Preflight-Compaction muss entweder das konfigurierte Zeitbudget respektieren oder einen klar dokumentierten Abschalter bekommen. Solange das nicht passiert, bleibt Issue #95553 keine Randnotiz aus dem Tracker, sondern ein brauchbarer Frühhinweis auf eine Stelle, an der OpenClaw unter Last erst Zeit verbrennt und danach trotzdem in denselben Engpass läuft.