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 openclaw@2026.6.9.

Stand 24. August 2026: Issue #95553 ist weiterhin offen und als P1 eingestuft. Alle im Juni gestarteten Reparatur-PRs wurden ohne Merge geschlossen, darunter #95590 und #95648. Ein Konfigurationsschalter compaction.preflight.enabled existiert nicht. Die Details stehen unten in den beiden Abschnitten zum Reparaturstand.

Für den Betrieb ist der Schaden ziemlich konkret. OpenClaw versucht eine fast volle Session noch vor dem eigentlichen Overflow zu entschärfen, verliert dabei erst einmal Zeit, hält die Session fest und steht danach oft trotzdem noch vor demselben Platzproblem. Das ist kein kosmetischer Fehler aus dem Tracker, sondern ein Muster, das unter Last direkt auffällt.

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 auf diesem Vorab-Pfad kippt das Verhalten. Laut Beschreibung hängt die Compaction dort am 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.

Diese Verteilung macht den Fehler greifbar. Wenn erfolgreiche Compactions auf derselben Infrastruktur regelmäßig mehrere Minuten brauchen, wirkt eine harte Grenze bei ungefähr einer Minute nicht wie ein eng gesetztes Timeout, sondern wie ein systematischer Abbruch. 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 zählt vor allem das Muster: große Kontexte, eher langsame Self-Hosted-Modelle und Sessions, die schon vor dem eigentlichen Overflow in eine Vorab-Compaction laufen. Ich würde genau diese Kombination im Blick behalten, auch wenn die eigene Hardware anders aussieht.

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 mehr als ein Performance-Bug. In einer Einzelsession ist eine verlorene Minute lästig. In Cron-, Heartbeat- oder Multi-Worker-Setups kann dieselbe Minute Prozesse gegeneinander laufen lassen, obwohl die Compaction eigentlich Stabilität herstellen soll.

Von diesem Ticket bleibt deshalb mehr hängen als nur „Timeout falsch gesetzt“. Der Engpass verlängert die Vorarbeit, blockiert die Session und verschärft unter Last genau die Konflikte, die er verhindern sollte.

Die naheliegenden Schalter helfen laut Bericht nicht sauber weiter

Auch die Workaround-Lage ist unschön. Compaction global abzuschalten würde zwar die problematische Vorab-Compaction abräumen, nimmt aber gleichzeitig die Overflow-Recovery weg. memoryFlush.enabled: false hilft laut Report ebenfalls nicht, weil dieser Schalter den Preflight-Pfad gar nicht deaktiviert. Einen gezielten Schalter nur für den Preflight-Pfad gibt es bis heute nicht.

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

Die Juni-PRs sind alle ohne Merge gescheitert

Unter dem Issue hingen im Juni gleich mehrere Reparaturansätze. Ein ClawSweeper-Review vom 22. Juni hielt das Ticket ausdrücklich offen und beschrieb es als zentralen Tracker für den Abort-Signal-Fehler. Nach dieser Einordnung reichten Mainline und letztes Release das Reply-Abort-Signal weiterhin in die notwendige Preflight-Compaction durch.

Ein Kandidat war PR #95590. Er sollte ReplyOperation ein separates explicitAbortSignal geben. Die Idee: Preflight-Compaction hängt nicht mehr am normalen Lifecycle-Timeout der Reply-Operation, respektiert echte Stop- oder Restart-Abbrüche aber weiter. Am 19. Juli 2026 wurde der PR ohne Merge geschlossen.

Der zweite Ansatz kam mit PR #95648 und dem Duplikat #95675. Beide ergänzten einen Schalter agents.defaults.compaction.preflight.enabled: false, der den Vorab-Pfad komplett übersprungen hätte. Keine Ursachenbehebung, aber ein Notausgang für Setups mit mehrminütigen Compactions. Auch dieser Weg endete am 22. Juni ohne Merge. In der heutigen Compaction-Konfiguration gibt es den Schalter nicht; dort stehen weiterhin timeoutSeconds mit einem Default von 180 Sekunden, mode, memoryFlush und midTurnPrecheck.

Insgesamt sind sechs Juni-PRs an diesem Issue gescheitert. Das ist kein Zufall. Der Fehler sitzt an einer Stelle, an der Abbruchsignale mehrerer Subsysteme zusammenlaufen.

Wo die Reparatur im August steht

Das Fehlerbild hat sich seit Juni verschoben. Ein Feldbericht im Ticket vom 13. August 2026 bezieht sich auf die Version 2026.7.1-2. Dort liegen die Abbrüche bei den konfigurierten 180 Sekunden statt bei 60. Derselbe Betreiber erhöhte compaction.timeoutSeconds von 180 auf 600. Die nächste overflow-getriggerte Compaction lief danach in rund 118 Sekunden durch. Der Auto-Pfad respektiert das konfigurierte Budget also. Der budgetgetriggerte Preflight-Pfad endete in denselben Logs weiterhin an der Obergrenze.

Der aktuelle Reparaturkandidat ist PR #125929, offen seit dem 18. August 2026. Er setzt an einer anderen Stelle an als die Juni-Versuche: beim Watchdog statt beim geteilten Reply-Abort-Signal. Laut Beschreibung kann der diagnostische Heartbeat eine hängende Session auf allowActiveAbort: true hochstufen. Dabei bricht er eine Reply-Operation ab, die gerade erst in die Preflight-Compaction eingetreten ist. Das Alter der Diagnoseanfrage taugt schlicht nicht als Uhr für die Preflight-Phase.

Der Vorschlag schützt eine Operation in der Phase preflight_compacting, solange die Aktivität ihres Besitzers unter dem bestehenden Lane-Release-Fenster liegt: max(5 Minuten, Compaction-Timeout + 15 Sekunden). Ob das reicht, ist offen. Der PR ist nicht gemergt, und das Ticket trägt weiterhin P1.

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 mit trigger=budget oder trigger=cli_budget, gefolgt von Overflow-Versuchen oder Lock-Fehlern auf derselben Session. Achte dabei nicht auf die 60 Sekunden aus dem ursprünglichen Bericht. Entscheidend ist, ob die Abbrüche sich um einen festen Wert häufen. Das passt besonders zu Setups, in denen du OpenClaw bereits mit eigenen Modellen betreibst; die Grundlagen dazu stehen im Guide zu lokalen Modellen mit Ollama.

Ein billiger Test steht seit August im Ticket: Erhöhe compaction.timeoutSeconds deutlich und schau, welche Pfade danach durchlaufen. Zieht der Auto-Pfad mit, während der budgetgetriggerte Pfad weiter an der alten Grenze endet, hast du genau dieses Fehlerbild vor dir.

Noch wichtiger ist die Form des Symptoms: Vorab-Compaction startet, 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 musst du wissen, welcher Pfad gerade gewinnt und welches Timeout in der eigenen Runtime tatsächlich wirksam ist.

Für mich ist genau das die Mindestregel aus Issue #95553: Preflight-Compaction muss entweder das konfigurierte Zeitbudget respektieren oder einen klar dokumentierten Abschalter bekommen. Zwei Monate und sechs gescheiterte PRs später gilt beides noch nicht. Das Ticket bleibt damit ein belegter Hinweis auf eine Stelle, an der OpenClaw unter Last erst Zeit verbrennt und danach trotzdem in denselben Engpass läuft.