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.

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.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. Der Fall ist deshalb 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 keine eigentliche Ursachenbehebung, aber ein sauberer Notausgang für Setups, in denen große Compactions realistisch mehrere Minuten brauchen.

Stand heute ist das noch keine Entwarnung. Eine Lösung ist nicht gemergt, das Fehlerbild bleibt reproduzierbar, und produktionsnahe Umgebungen zahlen den Preis schon jetzt in Zeit und Stabilität.

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. 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.

Noch wichtiger 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 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. Solange das nicht passiert, bleibt das Ticket 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.