OpenClaw meldet frische Heartbeat-Sessions, führt aber alte Transkripte weiter

Ein Heartbeat startet scheinbar frisch, die Session-ID ist neu, und trotzdem wächst der Modellkontext weiter. Im Betrieb entsteht damit eine gefährliche Diskrepanz: Die Oberfläche signalisiert Isolation, während gespeicherter Verlauf möglicherweise an der nächsten Ausführung hängt.

Ein GitHub-Issue beschreibt genau dieses Verhalten in einer konkreten Debian-Umgebung. Der Bericht ist eine Fallstudie, keine Aussage über jede OpenClaw-Installation und kein Beleg für einen Fehler im aktuellen Stable-Stand. Er liefert dennoch einen brauchbaren Test für Heartbeats, bei denen Kosten, Kontext und Sitzungsgrenzen eng kontrolliert werden sollen.

Der passende Betriebsrahmen steht im Guide zu Cron-Jobs, Heartbeats und Automationen in OpenClaw.

Der gemeldete Ablauf

Im Fallbericht läuft ein dedizierter Heartbeat-Agent mit isolatedSession: true und lightContext: true zweimal hintereinander. Danach werden Session-Store und Transcript-Datei verglichen.

Die Erwartung ist klar: Der zweite Lauf erhält eine neue Kennung und startet ohne alten Verlauf. Im Report wechselt die Session-ID von 31ec7166-6c8c-4730-b136-e5a4110fc3a8 auf 6e1f19ae-991f-4053-b8a2-a7c8a0864a9a. Gleichzeitig wächst dieselbe Transcript-Datei von 177126 auf 178358 Byte.

Das ist eine relevante Abweichung. Eine neue Kennung ist sichtbar, der gespeicherte Verlauf offenbar nicht. Wenn ein früher Modellturn alte Informationen übernimmt, können Kosten steigen und der Agent auf überholte Zustände reagieren.

Drei Werte für den lokalen Test

Der Fallbericht nennt auch steigende Eingabetoken: 12314, dann 13753 und später 17190. Diese Werte sind kein Benchmark für andere Umgebungen. Als Messmethode sind sie nützlich.

Ein lokaler Test braucht zwei aufeinanderfolgende Heartbeat-Läufe und drei Vergleiche:

1. Ändert sich die Session-ID?
2. Beginnt ein neues Transcript oder wächst ein bestehendes weiter?
3. Bleibt die Tokenzahl des frühen Modellturns in derselben Größenordnung?

Die Auswertung entscheidet über die nächste Maßnahme. Neue ID, neues Transcript und stabile Tokenzahl sprechen für eine saubere Trennung. Eine neue ID bei wachsendem Transcript ist dagegen ein Grund, die Isolation nicht als bestätigt zu behandeln. Steigen nur die Token, lohnt der Blick auf den tatsächlich an das Modell übergebenen Kontext und auf weitere Kontextquellen.

Für mich ist dabei die Kombination aus neuer ID und wachsendem Transcript der wichtige Alarm. Sie rechtfertigt einen Stopp für teure Folgeaufgaben, bis ein weiterer Lauf den Befund entkräftet oder die Ursache klar ist.

Wichtig ist der Vergleich mit einem zweiten, möglichst gleichartigen Lauf. Einzelwerte erzählen wenig; die Veränderung zwischen den Läufen zeigt, ob der Heartbeat wirklich bei null beginnt.

Was bis zur Klärung hilft

Zeigt ein Heartbeat wachsenden Startkontext, sollte er vorerst keine sensiblen oder teuren Aufgaben ausführen. Ein kurzer Statuscheck mit festen Output-Limits begrenzt die mögliche Wirkung. Für wichtige Automationen ist ein separater Lauf ohne wiederverwendeten Verlauf die vorsichtigere Wahl.

Auch das Browser- oder Monitoring-Dashboard sollte nicht der einzige Prüfpunkt bleiben. Transcript-Größe und Tokenentwicklung gehören in die Betriebsbeobachtung. So fällt ein schleichender State-Fehler auf, bevor ein Heartbeat viele Läufe lang unnötigen Kontext sammelt.

Warum das für AgentOps zählt

Der beschriebene Fall endet nicht zwangsläufig mit einem Absturz. Gerade dieser leise Fehler ist tückisch. Ein Job kann weiter erfolgreich aussehen, während seine Sitzungsgrenze langsam verwischt.

Für OpenClaw-Heartbeats gehört deshalb nach einer Konfigurationsänderung oder einem Update ein kurzer Wiederholungstest zum Ablauf. Session-ID, Transcript und Tokenentwicklung liefern zusammen ein belastbareres Bild als ein grüner Erfolgsstatus. Die Mindestregel lautet: Erst wenn diese drei Werte zusammenpassen, darf eine isolierte Session auch als isoliert gelten.

Für angrenzende Kontrollen helfen Sandboxing & Exec-Approvals und Dashboard, Monitoring und Agenten-Sichtbarkeit.