OpenClaw auf Main: Memory-Flush nutzt Sitzungsmodell und normale Fallbacks

OpenClaw-Agenten merken sich Dinge laut Dokumentation, indem sie Markdown-Dateien in ihren Arbeitsordner schreiben. Pull Request #182208 wurde am 24. Oktober 2026 in den main-Branch von OpenClaw gemergt. Die Änderung entfernt die separate Modellvorgabe für den Memory-Flush aus der Konfiguration und aus den Plugin-Plänen. Stattdessen nutzen Memory-Flushes das aktive Sitzungsmodell und dessen normale Fallback-Regeln, also die für die Sitzung konfigurierten Ausweichmodelle. Wer die Memory-Extraktion bisher über ein eigenes Flush-Modell lokal gehalten hat, sollte sein Setup prüfen, bevor er auf einen Stand wechselt, der diese Änderung aus main enthält.

Für viele Setups ist das eine Reparatur. Für rein lokale Setups kommt eine Aufgabe hinzu.

Was der Memory-Flush leistet

Bevor die Kompaktierung eine Unterhaltung zusammenfasst, startet OpenClaw laut Memory-Dokumentation einen stillen Zwischenschritt, der den Agenten daran erinnert, wichtigen Kontext ins dauerhafte Gedächtnis zu schreiben. Der Flush ist standardmäßig aktiv; mit agents.defaults.compaction.memoryFlush.enabled: false schaltest du ihn ab. Wird dieser optionale Schritt übersprungen oder scheitert er, verhindert das die Kompaktierung nicht.

Ein fehlgeschlagener Flush hält die Sitzung also nicht an. Verloren geht die Gelegenheit, wichtige Fakten zu sichern, bevor die Kompaktierung die Unterhaltung zusammenfasst.

Warum die alte Flush-Vorgabe scheitern konnte

Das Problem beschreibt die PR knapp: Eine eigene Modellvorgabe für den Memory-Flush konnte ein nicht verfügbares Modell wählen, ohne die Ausweichmodelle der aktiven Sitzung zu probieren, und der Flush blieb erfolglos.

Im Beispiel aus dem Review der PR läuft eine Sitzung mit einem Ollama-Cloud-Modell und einem Anthropic-Modell als Ausweichmodell, während die Flush-Vorgabe auf ein nicht verfügbares Modell zeigt. Vorher fragte der Flush nur diese Vorgabe an und scheiterte, ohne die Ausweichmodelle der Sitzung zu versuchen.

Auch im Praxistest der PR trat der Fehler auf. Auf macOS beantwortete ein veröffentlichtes Stable-Release mit einem echten Ollama-Modell qwen2.5:7b die normale Anfrage, der automatische Flush scheiterte aber an der nicht verfügbaren Vorgabe. Mit der Korrektur probierte der Flush in einem Gateway-Test zuerst das aktive Modell, erhielt eine Model-not-found-Antwort, wich auf das konfigurierte Ausweichmodell aus, rief das echte Schreibwerkzeug auf und verbuchte den Erfolg mit gespeicherter Notiz.

Kosten und Lokalität: der Preis der Vereinfachung

Die alte Vorgabe hatte einen Zweck. Laut der Herkunftsprüfung im Review der PR wurde sie eingeführt, damit lokale Wartungsaufgaben nicht stillschweigend auf kostenpflichtige Gesprächsmodelle ausweichen. Mit der Änderung fällt dieser Schutz weg: Ein Flush kann ein kostenpflichtiges Modell nutzen, wenn es das Modell der Sitzung ist.

Als Ausweg nennen PR und Memory-Dokumentation übereinstimmend ein lokales Sitzungsmodell plus lokale Ausweichmodelle, wenn die Extraktion lokal bleiben soll. Der Flush nutzt laut Dokumentation das aktive Sitzungsmodell und dessen normale Fallback-Kette.

Prüf deshalb jeden Eintrag deiner Fallback-Kette. Steht dort ein Cloud-Modell, kann nach dieser Regel auch der Flush dort landen. Eine neue Option, um nur für den Flush ein anderes Modell zu wählen, gibt es nicht. Ergänzend: Model-Failover in OpenClaw: Fallback-Modelle einrichten und gezielt prüfen.

Migration mit Doctor und Prüfung

Doctor entfernt vorhandene Einstellungen unter agents.defaults.compaction.memoryFlush.model mit einem ausdrücklichen Hinweis. Andere Flush-Einstellungen bleiben erhalten. Im macOS-Test der PR blieben dabei Primärmodell, Fallback, das enabled-Flag und die Schwelle für erzwungene Flushes unverändert.

Nach Upgrade und Doctor-Migration nutzte der automatische Flush dort ollama/qwen2.5:7b, und der Status in SQLite wechselte von failed zu succeeded. Einen dauerhaften Schreibvorgang machte das Modell in diesem Lauf allerdings nicht; die Persistenz belegt die PR mit dem deterministischen Gateway-Test.

Ob ein bestimmter Fakt wirklich gesichert wurde, prüfst du laut Dokumentation in den gespeicherten Notizen oder Einträgen deines Memory-Plugins. Ein erfolgreicher Status allein sagt das nicht.

Plugin-Autoren sind ebenfalls betroffen. Laut PR verlangen die SDK-Migrationshinweise, das Plan-Feld zu entfernen; ältere JavaScript-Pläne, die es noch zurückgeben, wirken sich nicht mehr auf die Ausführung aus. Dass kein externes Plugin das Feld noch nutzt, kann die PR nicht garantieren.

Was die Änderung offen lässt

Die PR adressiert ausdrücklich nur das Modell-Routing des Memory-Flush. Fragen zur CLI-Eignung, zur Compaction-Abrechnung und zum Wasserzeichen für wiederholte Flushes klammert sie aus.

Dazu kommt der Stand: Die Änderung liegt in main. Ebenfalls zum Thema Kompaktierung: OpenClaw: Auth-Cooldown kann Kanalantworten bei der Kompaktierung stoppen.

Lokaler Memory-Flush erfordert durchgehend lokale Sitzungsmodelle

• Mit der in main integrierten Änderung folgt der Memory-Flush dem Sitzungsmodell samt Ausweichmodellen; ein eigenes Flush-Modell gibt es dort nicht mehr.
• Ein Cloud-Modell in der Fallback-Kette macht es möglich, dass ein Flush in der Cloud verarbeitet wird, beweist es aber nicht.
• Doctor räumt das alte memoryFlush.model mit Hinweis ab, die übrigen Flush-Einstellungen bleiben.

Wenn Memory-Inhalte kein Cloud-Modell erreichen sollen, würde ich die gesamte Fallback-Kette der Sitzung als Datengrenze behandeln. Die lokale Extraktion, die die Dokumentation beschreibt, setzt ein lokales Sitzungsmodell und ausschließlich lokale Ausweichmodelle voraus.