Openclaw verliert in kurzen Abständen den Gesprächsfaden | Friends of the Crustacean 🦞🤝 | Page 1

cinder compass Apr 23, 2026, 10:01 AM

#

Es kommen in kurzen Abständen commpactions. Im webui sieht es so aus, als ob er mehrmals hintereinander compactiert oder versucht zu compactieren, dann verschwindet die chat historie und als erster eintrag erscheint: [chat.history omitted: message too large] Der Agent hat dann den kompletten Gesprächsfaden verloren.

supple stoneBOT Apr 23, 2026, 10:01 AM

#

blissful heartBOT Apr 23, 2026, 10:01 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

supple stoneBOT Apr 23, 2026, 10:01 AM

#

quaint epochBOT Apr 23, 2026, 10:03 AM

#

Ich schau kurz in die Compaction-Doku und in den Codepfad für diesen Placeholder, dann kann ich gezielter sagen, ob das UI-Artefakt oder echter Kontextverlust ist.

#

Ich hab einen ziemlich guten Treffer gefunden: Es gibt einen Reset-Pfad, bei dem OpenClaw bei Context-Overflow während/nach der Compaction die Session frisch startet. Das würde exakt erklären, warum der Faden komplett weg ist. Ich prüfe gerade die genauen Bedingungen.

#

Das klingt nach zwei getrennten Effekten:

[chat.history omitted: message too large] ist erstmal ein UI-Platzhalter, nicht automatisch echter Datenverlust.
Die Web/UI-History ist absichtlich größenbegrenzt. Siehe https://docs.openclaw.ai/web/webchat.
Der echte Gesprächsverlust passt zu einem Context-Overflow rund um die Compaction.
Im Code gibt es dafür sogar einen Reset-Pfad: Wenn Compaction/Retry den Context nicht mehr sauber klein bekommt, wird die Session frisch gestartet. Das würde genau erklären, warum der Faden plötzlich weg ist.
Doku: https://docs.openclaw.ai/concepts/compaction
Deep dive: https://docs.openclaw.ai/reference/session-management-compaction

Was ich als Nächstes prüfen würde:

openclaw --version
openclaw status
beim Reproduzieren: openclaw logs --follow

Und bitte diese Punkte mit posten:

#

welches Modell/Provider ihr nutzt
eure agents.defaults.compaction
eure agents.defaults.contextPruning
ob ihr gateway.webchat.chatHistoryMaxChars gesetzt habt

Wahrscheinliche Fixes:

{
  agents: {
    defaults: {
      contextPruning: {
        mode: "cache-ttl",
        ttl: "5m",
      },
      compaction: {

#

        mode: "safeguard",
        reserveTokensFloor: 20000,
        // optional: besseres Modell nur für Compaction
        // model: "..."
      },
    },
  },
  gateway: {
    webchat: {
      // nur falls das Problem primär die UI-History ist
      // chatHistoryMaxChars: 20000,
    },
  },
}

#

Besonders wichtig:

Pruning aktivieren, damit alte Tool-Outputs nicht ständig die Context-Window aufblasen
https://docs.openclaw.ai/concepts/session-pruning
Falls ihr ein kleines/lokales Hauptmodell nutzt, ein besseres Compaction-Modell separat setzen
Falls ihr reserveTokensFloor mal abgesenkt habt, wieder auf mindestens 20000

Wenn du magst, poste hier openclaw --version, openclaw status und die drei Config-Blöcke, dann geh ich es gezielt mit dir durch.

cinder compass Apr 23, 2026, 10:12 AM

#

ist das ein webui thema, wenn ja, dann wechsle ich zur tui.

quaint epochBOT Apr 23, 2026, 10:13 AM

#

Eher teils ja, teils nein.

Ja: Der Eintrag [chat.history omitted: message too large] ist WebUI/WebChat-spezifisch. Das ist die größenbegrenzte chat.history-Darstellung.
Doku: https://docs.openclaw.ai/web/webchat
Nein: Das eigentliche Vergessen / der Gesprächsverlust ist sehr wahrscheinlich nicht nur ein WebUI-Thema. Wenn im Backend die Compaction bzw. der Overflow-Reset zuschlägt, dann hilft ein UI-Wechsel allein nicht.

Kurz gesagt:

Nur der Placeholder nervt? Dann kann TUI angenehmer sein.
Der Agent verliert wirklich den Faden? Dann liegt das Problem eher bei Compaction/Context, nicht bei der Oberfläche.

Ich würde also nicht blind auf TUI als Fix setzen. Als schneller Test ist es aber sinnvoll:

gleiche Unterhaltung / ähnlicher Workload in TUI testen
/status anschauen
wenn die Compactions weiter hochzählen oder der Faden wieder weg ist, ist es kein reines WebUI-Problem

#

Wenn du magst, poste einmal:

openclaw --version
openclaw status
Modell/Provider
agents.defaults.compaction
agents.defaults.contextPruning

Dann kann ich dir sagen, ob TUI nur ein Workaround wäre oder ob ihr die eigentliche Ursache schon in der Config seht.

cinder compass Apr 23, 2026, 10:21 AM

#

agents.defaults.models.
"compaction": {
"reserveTokensFloor": 20000,
"memoryFlush": {
"enabled": true,
"softThresholdTokens": 4000,
"prompt": "Write lasting notes to memory/YYYY-MM-DD.md; reply NO_REPLY if nothing to store."

quaint epochBOT Apr 23, 2026, 10:22 AM

#

Danke, der Ausschnitt hilft.

reserveTokensFloor: 20000 sieht erstmal vernünftig aus, also nicht der offensichtliche "Compaction-Buffer zu klein"-Fall.

Damit bleiben die wahrscheinlicheren Ursachen:

zu viel Context-Bloat, oft durch Tool-Outputs
kleines / ungeeignetes Hauptmodell für lange Sessions oder Compaction-Zusammenfassungen
WebUI zeigt den Placeholder, aber das eigentliche Problem sitzt im Backend

Der wichtigste fehlende Block ist jetzt agents.defaults.contextPruning. Wenn das aus ist, kommt man viel schneller in dauernde Compactions.

Wenn noch nicht gesetzt, würde ich testweise genau das aktivieren:

#

  agents: {
    defaults: {
      contextPruning: {
        mode: "cache-ttl",
        ttl: "5m",
      },
    },
  },
}

Und bitte poste noch:

openclaw --version
das konkrete Modell unter agents.defaults.model
agents.defaults.contextPruning

#

optional gateway.webchat.chatHistoryMaxChars

Wichtig: Dein Snippet entlastet die WebUI nicht als alleinige Ursache.
Es spricht eher dafür, dass die WebUI nur den Effekt sichtbar macht, während die eigentliche Ursache wahrscheinlich Context/Compaction ist.

Wenn du nur schnell testen willst, würde ich so vorgehen:

TUI testen, ja
gleichzeitig Pruning aktivieren
wenn es dann immer noch passiert, ist es ziemlich sicher kein WebUI-only Bug

Wenn du die restlichen Blöcke postest, kann ich dir ziemlich genau sagen, wo ich ansetzen würde.

cinder compass Apr 23, 2026, 10:49 AM

#

Was macht:
agents: {
defaults: {
contextPruning: {
mode: "cache-ttl",
ttl: "5m",
},
},
},
}

quaint epochBOT Apr 23, 2026, 10:50 AM

#

Das schaltet Session Pruning ein.

Kurz gesagt:

es kürzt alte Tool-Outputs im Prompt, bevor der nächste LLM-Call gebaut wird
normale Unterhaltung bleibt unangetastet
die gespeicherte History auf Platte bleibt auch erhalten
Ziel: weniger Context-Bloat, also weniger frühe Compactions

ttl: "5m" heißt dabei:

nach ca. 5 Minuten darf OpenClaw die alten Tool-Ergebnisse erneut zusammenstutzen
praktisch ist das vor allem gut bei Sessions mit viel exec, read, Websuche, großen Tool-Resultaten usw.

Also nicht:

kein Löschen der Session

#

kein Verlust der eigentlichen Chat-Historie
keine Änderung am UI direkt

Sondern:

Prompt schlanker machen, damit Compaction später oder seltener nötig wird

Wenn dein Problem von großen Tool-Outputs kommt, hilft das oft spürbar.

Doku: https://docs.openclaw.ai/concepts/session-pruning

Faustregel:

viel Tool-Nutzung / lange Sessions → meistens sinnvoll
fast nur normaler Chat → bringt weniger

Wenn du willst, schicke ich dir direkt den kompletten JSON5-Block, den du in openclaw.json einfügen kannst.

cinder compass Apr 23, 2026, 10:51 AM

#

Context overflow ... provider=ollama/glm-5.1:cloud ... messages=145
Auto-compaction failed ... Restarting session

quaint epochBOT Apr 23, 2026, 10:51 AM

#

Jep, das ist der eigentliche Fehler:

Context overflow ... provider=ollama/glm-5.1:cloud
Auto-compaction failed ... Restarting session

Damit ist klar:

nicht primär WebUI
der Agent verliert den Faden, weil die Compaction selbst scheitert
danach startet OpenClaw die Session neu, deshalb ist der Verlauf weg

Der [chat.history omitted: message too large]-Eintrag ist dann eher Begleiterscheinung im UI, nicht die Ursache.

Ich würde jetzt genau das tun:

#

{
  agents: {
    defaults: {
      contextPruning: {
        mode: "cache-ttl",
        ttl: "5m",
      },
      compaction: {
        reserveTokensFloor: 20000,
        model: "EIN ANDERES, ZUVERLÄSSIGERES MODELL NUR FÜR COMPACTION",
      },
    },
  },
}

#

Warum:

GLM über Ollama läuft bei langen agentischen Sessions oft nicht stabil genug
wenn dieselbe Modellkette auch noch die Compaction machen soll, knallt es genau in solchen Fällen
Pruning reduziert den Context vorher
ein separates Compaction-Modell macht die Zusammenfassung robuster

Wichtig: TUI allein fixt das nicht.
Mit derselben Session/Backend-Konfiguration würdest du sehr wahrscheinlich denselben Reset bekommen.

Doku:

Compaction: https://docs.openclaw.ai/concepts/compaction
Session pruning: https://docs.openclaw.ai/concepts/session-pruning
Config: https://docs.openclaw.ai/gateway/configuration

Wenn du magst, poste dein aktuelles openclaw --version und den kompletten agents.defaults-Block, dann sag ich dir, wie ich ihn für deinen Fall konkret umbauen würde.

cinder compass Apr 23, 2026, 10:53 AM

#

meine openclaw.json ist keine json5

quaint epochBOT Apr 23, 2026, 10:54 AM

#

Kurz prüfen, damit ich dir keinen Quatsch erzähle: Ich ziehe die Doku zum Config-Format nach.

#

Alles gut, normales JSON geht auch. 🙂

openclaw.json wird laut Doku als JSON5 gelesen, aber reguläres JSON ist völlig gültig.
Heißt praktisch:

Kommentare nur in JSON5
Trailing commas nur in JSON5
normales JSON funktioniert ganz normal

Dann nimm einfach diese JSON-Variante:

{
  "agents": {
    "defaults": {
      "contextPruning": {

#

        "mode": "cache-ttl",
        "ttl": "5m"
      },
      "compaction": {
        "reserveTokensFloor": 20000
      }
    }
  }
}

Wenn du zusätzlich ein separates Modell nur für Compaction setzen willst, dann so:

#

  "agents": {
    "defaults": {
      "contextPruning": {
        "mode": "cache-ttl",
        "ttl": "5m"
      },
      "compaction": {
        "reserveTokensFloor": 20000,
        "model": "..."
      }
    }
  }
}

Doku:

#

Konfiguration: https://docs.openclaw.ai/gateway/configuration
Config reference: https://docs.openclaw.ai/gateway/configuration

Wenn du willst, formatiere ich dir deinen bestehenden Config-Block direkt in korrektes JSON um.

cinder compass Apr 23, 2026, 11:04 AM

#

Hast du einen Empfehlung, welches ollama cloud modell gut geeignet ist. Ich gehe davon aus, dass die folgenden kriterien ausschlaggebend sind:

starke logische Schlussfolgerung
hohes Kontextfenster
gute Fähigkeiten zur Zusammenfassung von Text, Auflistungen und Code

quaint epochBOT Apr 23, 2026, 11:07 AM

#

Ich würde dir da ungern einen konkreten Modellnamen aus dem Bauch heraus nennen, weil die Ollama-Cloud-Auswahl und die praktischen Erfahrungen schnell veralten.

Für deinen speziellen Use Case, nur für compaction.model, würde ich diese Prioritäten setzen:

großes Kontextfenster
starke Zusammenfassungen über lange, gemischte Eingaben
also Fließtext, Listen, Logs, Code
saubere Instruktionsbefolgung
stabile Qualität bei langen Prompts

Weniger wichtig als beim Hauptmodell:

Tool-Calling
Agentenverhalten
super kreative Generierung

Für Compaction ist es im Kern ein Summarizer mit langem Atem.

#

Meine praktische Empfehlung wäre daher:

kein kleines/sparsames Modell für compaction.model
lieber ein größeres Cloud-Modell mit großem Kontextfenster
Hauptmodell und Compaction-Modell ruhig trennen

Der beste Ort für die aktuelle konkrete Ollama-Cloud-Empfehlung ist wirklich #models, weil dort die Leute frische Hands-on-Erfahrungen haben.
Bitte nimm diese Links dazu:

Modelle-Doku: https://docs.openclaw.ai/concepts/models
Community notes: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

Wenn du in #models fragst, würde ich es genau so formulieren:

Suche ein Ollama Cloud Modell für agents.defaults.compaction.model
Anforderungen:

starke logische Schlussfolgerung

#

hohes Kontextfenster

sehr gute Zusammenfassung von Text, Listen, Logs und Code

robust für lange Sessions / Compaction, Tool-Calling ist zweitrangig

Wenn du willst, formuliere ich dir auch direkt den finalen openclaw.json-Block für contextPruning + compaction.model.

cinder compass Apr 23, 2026, 11:25 AM

#

Ich finde keine „models“ section hier bei Friends of the Crustacean es gibt eine #1478196963563409520 dort darf habe ich aber keine Berechtigung.

quaint epochBOT Apr 23, 2026, 11:26 AM

#

Ah, danke, dann war mein Hinweis dahin Mist. Wenn du da keinen Zugriff hast, würde ich hier nicht blockieren.

Dann meine praktische Empfehlung ohne konkreten Modellnamen:

Für agents.defaults.compaction.model in Ollama Cloud würde ich nehmen:

das stärkste allgemeine Instruct-Modell
mit dem größten verfügbaren Kontextfenster
kein kleines / sparsames / distilled Modell
eher general-purpose als rein code-spezialisiert

Für Compaction zählt vor allem:

lange Eingaben stabil verarbeiten
sauber zusammenfassen
IDs, Dateinamen, Listen und Code nicht verhunzen
auch bei 100k+ Tokens noch brauchbar bleiben

#

Ich würde also nicht nach "billig und schnell" auswählen, sondern nach:

größtes Kontextfenster
beste Summaries auf langen Inputs
stabile Instruktionsbefolgung

Wenn du mehrere Kandidaten in Ollama Cloud hast, würde ich sie so testen:

denselben langen Transcript-Ausschnitt nehmen
jeden Kandidaten exakt dieselbe Summary machen lassen
prüfen:
- bleiben wichtige Details erhalten?
- bleiben Dateinamen / IDs / Schritte korrekt?
- wird Code sinnvoll zusammengefasst?
- halluziniert er wenig?

Wenn du nur einen pragmatischen Default willst, dann ist meine Faustregel:

#

Nimm in Ollama Cloud eher das größte brauchbare allgemeine Modell für Compaction, nicht das kleinste günstige.

Und ganz ehrlich, wenn die Resets weitergehen, obwohl contextPruning an ist, würde ich Compaction als erstes von GLM/Ollama Cloud wegziehen, selbst wenn das Hauptmodell dort bleibt.

Wenn du magst, kann ich dir als Nächstes einen fertigen JSON-Block bauen für:

contextPruning
compaction.reserveTokensFloor
compaction.model

und dir auch sagen, wie du 2 bis 3 Kandidaten systematisch gegeneinander testest.

cinder compass Apr 23, 2026, 11:59 AM

#

Ist das so erstmal plausibel?

...
"ollama": {
"baseUrl": "http://█",
"apiKey": "█",
"api": "ollama",
"models": [
{
"id": "kimi-k2.6:cloud",
"name": "kimi k2.6 (Cloud)",
"api": "ollama",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 190000,
"contextTokens": 190000,
"maxTokens": 10000
},
{
█
}
]

...

"agents": {
    "defaults": {
      "contextPruning": {
    "mode": "cache-ttl",
    "ttl": "5m"
      },
      "compaction": {
    "reserveTokensFloor": 20000,
    "model": "kimi k2.6 (Cloud)",
    "memoryFlush": {
      "enabled": true,
      "softThresholdTokens": 4000,
      "prompt": "Write lasting notes to memory/YYYY-MM-DD.md; reply NO_REPLY if nothing to store."
    }
      }
    }
},

...

quaint epochBOT Apr 23, 2026, 12:00 PM

#

Das sieht fast richtig aus, ich prüfe nur kurz den entscheidenden Punkt, ob compaction.model den Display-Namen oder die provider/id-Form erwartet. Das ist genau die Sorte Detail, bei der man sich sonst schnell vertut.

#

Ja, fast. Der Aufbau ist plausibel, aber es gibt einen wichtigen Haken:

compaction.model sollte nicht der Anzeigename sein, sondern am besten die provider/model-id.

Also eher so:

{
  "agents": {
    "defaults": {
      "contextPruning": {
        "mode": "cache-ttl",
        "ttl": "5m"
      },
      "compaction": {
        "mode": "safeguard",

#

        "reserveTokensFloor": 20000,
        "model": "ollama/kimi-k2.6:cloud",
        "memoryFlush": {
          "enabled": true,
          "softThresholdTokens": 4000,
          "prompt": "Write lasting notes to memory/YYYY-MM-DD.md; reply NO_REPLY if nothing to store."
        }
      }
    }
  }
}

Wichtig dabei:

richtig: ollama/kimi-k2.6:cloud

#

riskant/falsch: "kimi k2.6 (Cloud)"

Der name ist eher für Anzeige/UI.
Für Agent-Konfig ist normalerweise die provider/model-id-Form richtig.

Zusätzlich würde ich dir empfehlen:

mode: "safeguard" explizit zu setzen
contextPruning drin zu lassen
erst mal nur ein Compaction-Modell zu testen, damit du Effekte sauber vergleichen kannst

Der Rest sieht erstmal vernünftig aus:

reserveTokensFloor: 20000 passt
memoryFlush passt
contextPruning passt
contextWindow: 190000 klingt für den Zweck grundsätzlich plausibel

#

Doku:

Wenn du magst, bau ich dir im nächsten Schritt einen kompletten minimierten agents.defaults-Block, den du 1:1 reinkopieren kannst.

cinder compass Apr 23, 2026, 12:03 PM

#

was macht safeguard?

quaint epochBOT Apr 23, 2026, 12:04 PM

#

safeguard ist der robustere Compaction-Modus für lange/vertrackte Sessions.

Kurz gesagt:

default = normale Compaction
safeguard = vorsichtigere, chunk-basierte Compaction für lange Histories

Was safeguard praktisch macht:

zerlegt lange History eher stufenweise / in Chunks
ist vorsichtiger bei sehr großen Transcripts
achtet darauf, dass Tool-Calls und Tool-Resultate zusammenbleiben
lässt den aktuellen, frischen Gesprächs-Tail eher unangetastet

Warum das für dich sinnvoll ist:

du hast schon Overflow + Auto-compaction failed + Restarting session

#

genau da ist safeguard die bessere Wahl als der normale Modus

Wichtig:

safeguard ist kein Wundermittel
wenn das Modell selbst bei langen Zusammenfassungen schwächelt, kann es trotzdem scheitern
aber es ist in deinem Fall die plausiblere und stabilere Einstellung

Kurzform:
safeguard = defensivere Compaction für lange Sessions, mit weniger Risiko, dass die Verdichtung selbst entgleist.

Doku: https://docs.openclaw.ai/concepts/compaction

Wenn du willst, schicke ich dir direkt einen kleinen finalen Config-Block mit:

contextPruning
compaction.mode = "safeguard"
compaction.reserveTokensFloor

#

compaction.model

cinder compass Apr 23, 2026, 12:06 PM

#

Dann würde ich jetzt den doctor checken lassen, und einen Gateway restart machen. Oder sollte ich vorher noch etwas beachten?

quaint epochBOT Apr 23, 2026, 12:06 PM

#

Ja, das ist ein sinnvoller nächster Schritt. Ich würde vorher nur kurz 4 Dinge sichern, damit ihr im Zweifel nicht im Nebel stochert:

openclaw --version
openclaw status
die relevanten Logzeilen mit
- Context overflow
- Auto-compaction failed
- Restarting session
den aktuellen agents.defaults-Block aus der Config

Dann mein Ablauf wäre:

Config anpassen (contextPruning, compaction.mode = "safeguard", compaction.model)
openclaw doctor laufen lassen
openclaw gateway restart
für den Test lieber eine frische Session / neuen Thread nehmen

#

Der letzte Punkt ist wichtig, weil die alte Session schon "angeknackst" sein kann.
Zum Verifizieren würde ich nicht direkt im bereits problematischen Verlauf weiterprüfen.

Also kurz:

Ja, Doctor + Restart passt
vorher Logs/Version sichern
danach am besten in frischer Session testen

Wenn du magst, schreibe ich dir die Reihenfolge auch noch als copy-paste Kommando-Liste zusammen.

cinder compass Apr 23, 2026, 12:09 PM

#

Ich will nicht verifizieren, ich glaube Kimi ist das Richtige. Ich weiß nur noch nicht wie ich die think parameter für kimi setzen sollte.

quaint epochBOT Apr 23, 2026, 12:10 PM

#

Lass mich das kurz in der Doku verifizieren, bevor ich dir den falschen Param-Namen sage.

#

Ich hab den Param-Namen, ich prüfe noch kurz die erlaubten Werte, damit ich dir direkt die richtige Form geben kann.

#

Für Kimi nur als compaction.model würde ich ganz klar mit wenig oder gar keinem Thinking starten.

Meine Empfehlung:

erstmal thinking: "off"
wenn du merkst, dass die Zusammenfassungen zu flach werden, dann "low"

Warum ich nicht hoch gehen würde:

Compaction ist primär strukturierte Verdichtung, nicht tiefes Problemlösen
mehr Thinking heißt oft mehr Tokens, mehr Latenz, mehr Risiko, dass genau diese Compaction wieder unnötig fett wird
dein Problem war ja bereits Overflow bei der Compaction

Wichtig ist auch wo du das setzt:
Nicht in compaction selbst, sondern beim Modell-Eintrag unter agents.defaults.models["ollama/kimi-k2.6:cloud"].params.

Also z. B. so:

#

{
  "agents": {
    "defaults": {
      "models": {
        "ollama/kimi-k2.6:cloud": {
          "params": {
            "thinking": "off"
          }
        }
      },
      "contextPruning": {
        "mode": "cache-ttl",
        "ttl": "5m"
      },
      "compaction": {

#

        "mode": "safeguard",
        "reserveTokensFloor": 20000,
        "model": "ollama/kimi-k2.6:cloud",
        "memoryFlush": {
          "enabled": true,
          "softThresholdTokens": 4000,
          "prompt": "Write lasting notes to memory/YYYY-MM-DD.md; reply NO_REPLY if nothing to store."
        }
      }
    }
  }
}

Faustregel:

#

Kimi nur für Compaction → thinking: "off" oder "low"
Kimi als Hauptmodell für normale Agent-Arbeit → eher "low" oder "medium"

Wenn du willst, baue ich dir jetzt einen kompletten finalen Config-Block mit Kimi als Compaction-Modell und sinnvollen Defaults.

cinder compass Apr 23, 2026, 12:13 PM

#

Wenn ich mit diesen einstellungen in der Main-Session /compact eingabe, wird dann auch mit kimi compactiert?

quaint epochBOT Apr 23, 2026, 12:13 PM

#

Ja, genau dafür ist agents.defaults.compaction.model da.

Wenn das gesetzt ist, dann wird sowohl bei:

manuellem /compact
als auch bei Auto-Compaction

das Compaction-Modell verwendet, also in deinem Fall Kimi, nicht das normale Hauptmodell.

Kurz:

normales Antworten → Hauptmodell
/compact → agents.defaults.compaction.model
Auto-Compaction → agents.defaults.compaction.model

Vorausgesetzt natürlich:

#

der Modell-Ref stimmt, also z. B. ollama/kimi-k2.6:cloud
und das Modell ist in deiner Config korrekt vorhanden / erlaubt

Also: Ja, wenn du in der Main-Session /compact eingibst, sollte mit Kimi compactiert werden.

cinder compass Apr 23, 2026, 12:26 PM

#

Hauptagent ist nicht ansprechbar. was ist besser /reset oder /new

quaint epochBOT Apr 23, 2026, 12:27 PM

#

Ich prüfe kurz die Doku für den genauen Unterschied, damit ich dir nicht die falsche Recovery-Empfehlung gebe.

#

In deinem Fall würde ich /new nehmen.

Der wichtige Punkt aus der Doku:

/new startet eine neue Session
/reset ist dafür nur ein Alias
/reset soft ist der Sonderfall, der im selben Verlauf bleibt und nur Session-/Backend-Zustand weich zurücksetzt

Also praktisch:

kaputte / festgefahrene Session, sauber neu anfangen → /new
gleichen Verlauf behalten, nur weich zurücksetzen → /reset soft

Da du gerade schon Compaction-/Overflow-/Restart-Probleme hattest, würde ich nicht im alten Verlauf herumdoktern, sondern einfach:

/new

#

nehmen und mit der neuen Config frisch starten.

cinder compass Apr 23, 2026, 12:35 PM

#

Er arbeitet wieder aber ich kann nicht weitermachen, weil das system bei jeder nachricht von mier eine Anweisung ergänzt, dass er den Heartbeat checken soll:

Wenn ich Hallo schreibe kommt das hier raus.

System: [2026-04-23 14:14:34 GMT+2] HEARTBEAT: Lies HEARTBEAT.md und befolge die Regeln.
[Thu 2026-04-23 14:25 GMT+2] Hallo.

quaint epochBOT Apr 23, 2026, 12:35 PM

#

Ich ziehe kurz die Doku/den Code nach, ob das als bekanntes Heartbeat-Routing-Thema auftaucht. Das klingt eher nach falsch klassifizierten Eingängen als nach deinem Agenten selbst.

#

Das ist nicht normales Verhalten.

Der Heartbeat-Prompt soll nur bei echten Heartbeat-Runs auftauchen, nicht vor jeder normalen Nachricht.
Wenn bei Hallo wieder HEARTBEAT: Lies HEARTBEAT.md ... mit reinkommt, wirkt die aktuelle Session verdorben / mit hängendem System-Event belegt.

Meine ehrliche Empfehlung:

sofort /new
nicht in dieser Session weiterkämpfen

Für dein akutes Weiterarbeiten ist /new die beste Abkürzung.

Wenn das Problem auch in der neuen Session wieder auftaucht, dann ist es eher ein Heartbeat-/Routing-Bug oder eine Config-Sache. Dann würde ich als Nächstes:

openclaw --version
openclaw doctor
openclaw gateway restart

#

machen.

Wenn du Heartbeats testweise komplett rausnehmen willst, dann vorübergehend:

{
  "agents": {
    "defaults": {
      "heartbeat": {
        "every": "0m"
      }
    }
  }
}

Kurzfassung:

#

nur diese Session betroffen → /new
jede neue Session auch betroffen → Heartbeat temporär aus + Doctor/Restart

Wenn das nach /new wieder passiert, würde ich das als Bug-Kandidat sehen.

cinder compass Apr 23, 2026, 12:39 PM

#

Nach /new kommt wieder [chat.history omitted: message too large]

#

Ich habe den Heartbeat jetzt mit openclaw system heartbeat disable abgestellt.

quaint epochBOT Apr 23, 2026, 12:40 PM

#

Okay, das ist ein wichtiger Unterschied. Wenn es direkt nach /new wieder kommt, ist die alte Session ziemlich sicher nicht mehr die Hauptursache. Ich prüfe kurz, welche Startup-Blöcke OpenClaw auf einer frischen Session zusätzlich reinzieht.

#

Ich hab den wahrscheinlichsten Treffer: /new kann einen Startup-Context-Block mit recent daily memory voranstellen. Wenn der fett geworden ist, kann schon die frische Session direkt mit diesem Placeholder starten. Ich prüfe kurz die genauen Config-Schalter, dann gebe ich dir die sauberste Sofortmaßnahme.

#

Okay, das ist jetzt ein starkes Indiz, dass nicht nur die alte Session kaputt war.

Wenn es direkt nach /new wieder passiert, dann ist sehr wahrscheinlich einer dieser beiden Blöcke zu groß:

startupContext auf /new
Der kann laut Doku recent daily memory vor den ersten Turn hängen.
Heartbeat-Bootstrap / HEARTBEAT.md
Vor allem, weil du vorher schon diese Heartbeat-Leak-Symptome hattest.

Ich würde zum schnellen Entstören testweise beides ausknipsen:

{
  "agents": {
    "defaults": {
      "startupContext": {

#

        "enabled": false
      },
      "heartbeat": {
        "every": "0m"
      }
    }
  }
}

Dann:

Gateway restart
/new
nochmal schauen, ob der Placeholder weg ist

#

Warum genau diese zwei Schalter:

startupContext.enabled: false
stoppt den /new-Prelude mit Daily Memory
heartbeat.every: "0m"
deaktiviert Heartbeats, und laut Doku wird dann HEARTBEAT.md auch nicht mehr in normale Runs injiziert

Wenn das danach weg ist, dann würde ich als Nächstes diese Dateien prüfen/trimmen:

memory/YYYY-MM-DD.md
MEMORY.md oder memory.md
HEARTBEAT.md

Wenn es trotzdem sofort wieder kommt, dann sieht es eher nach einem WebUI/chat.history-Problem aus, nicht mehr nach Session-Compaction.

Doku:

Startup context: https://docs.openclaw.ai/gateway/configuration

#

Heartbeat: https://docs.openclaw.ai/gateway/heartbeat

Wenn du willst, formuliere ich dir direkt einen kompletten minimalen Diagnose-Config-Block, den du 1:1 testen kannst.

#

Gut, das ist ein sinnvoller Schritt.

Dann würde ich jetzt sofort den sauberen Gegentest machen:

/new
schauen, ob [chat.history omitted: message too large] noch direkt wieder auftaucht

Interpretation:

wenn es jetzt weg ist
dann war Heartbeat sehr wahrscheinlich mitverursachend
wenn es immer noch sofort kommt
dann ist der nächste Verdächtige startupContext / Daily Memory, nicht mehr Heartbeat

Dann wäre mein nächster Test:

#

{
  "agents": {
    "defaults": {
      "startupContext": {
        "enabled": false
      }
    }
  }
}

Wenn du magst, geh die Schritte einfach nacheinander durch und poste nur kurz:

weg
oder immer noch da

#

Dann kann ich dir direkt den nächsten saubersten Schritt sagen.

cinder compass Apr 23, 2026, 1:02 PM

#

Ichabe jetzt mehrfach /new gemacht. über die WEBUI nutzt er sofort toolcalls:
z.B.:
Read

with from /home/X/.openclaw/workspace/MEMORY.md
Tool input
{
"path": "/home/X/.openclaw/workspace/MEMORY.md"
}

quaint epochBOT Apr 23, 2026, 1:03 PM

#

Oh, das ist ein richtig guter Hinweis. Sofortige read-Toolcalls auf Workspace-Dateien nach jedem /new riechen stark nach Bootstrapping statt normalem Chat-Start. Ich prüfe kurz, ob die Doku genau dieses BOOTSTRAP.md-Verhalten beschreibt.

#

Das ist ein sehr guter Fund.

Ein read auf MEMORY.md direkt nach /new ist an sich nicht völlig absurd, aber wenn das bei jedem neuen Start sofort passiert, dann riecht das stark nach Bootstrap-/Session-Startup-Modus, nicht nach normalem Chat.

Der wichtigste Check ist jetzt:

Existiert noch ~/.openclaw/workspace/BOOTSTRAP.md?

Warum ich darauf komme:

Laut Doku ist BOOTSTRAP.md nur für brandneue Workspaces
wenn sie noch da ist, behandelt OpenClaw die Session weiter wie bootstrap pending
dann liest der Agent beim Start wieder Workspace-Dateien statt normal weiterzulaufen

Und das passt auch zu deinem WebUI-Symptom:

wenn der Agent sofort MEMORY.md liest

#

und die Datei groß ist
dann kann genau dieser Tool-Output in chat.history zu
[chat.history omitted: message too large] führen

Mein nächster Ablauf wäre daher:

prüfen, ob BOOTSTRAP.md noch existiert
wenn ja und das Setup längst durch ist, weg damit / beiseite legen
Gateway restart
/new
falls er dann immer noch sofort MEMORY.md liest, MEMORY.md selbst auf Größe prüfen

Kurz:
Der read MEMORY.md-Call ist wahrscheinlich nicht die Ursache, sondern der Hinweis auf einen noch aktiven Bootstrap-/Startup-Pfad.

Wenn du magst, kann ich dir direkt die 2-3 Prüfkommandos dafür in der richtigen Reihenfolge aufschreiben.

cinder compass Apr 23, 2026, 1:08 PM

#

Bootstrap.md gibt es nicht mehr.
.../workspace/Memory.md ist ca. 8200 Zeichen lang und hat 8.1 KiB. Enthält aber auch Verweise auf andere .md Dateien.

quaint epochBOT Apr 23, 2026, 1:09 PM

#

Ah, das ist wahrscheinlich der Durchbruch.

MEMORY.md mit ca. 8200 Zeichen ist sehr nah bzw. leicht über der WebUI-History-Grenze.
Die Doku nennt für chat.history standardmäßig 8000 Zeichen Textlimit.

Heißt konkret:

der Agent liest direkt MEMORY.md
der Tool-Output landet in der Transcript-/History-Darstellung
die WebUI ersetzt das dann mit
[chat.history omitted: message too large]

Das erklärt sehr gut, warum es direkt nach /new wieder auftaucht, auch ohne kaputte Session.

Also aktuell sieht es nach zwei getrennten Dingen aus:

WebUI-Placeholder wegen zu großem MEMORY.md-Read

#

frühere Compaction-Probleme wegen Modell/Context-Bloat

Meine Empfehlung jetzt:

Option A, schnellster UI-Fix

gateway.webchat.chatHistoryMaxChars erhöhen, z. B.:

{
  "gateway": {
    "webchat": {
      "chatHistoryMaxChars": 20000
    }
  }
}

#

Option B, saubererer Langzeit-Fix

MEMORY.md kürzer und indexartiger machen:

nur Kernfakten / kurze Zusammenfassung
Details in andere Dateien oder memory/YYYY-MM-DD.md
nicht zu viele lange Verweislisten oder große Blöcke

Für OpenClaw ist MEMORY.md als kompakter Orientierungsspeicher meist besser als als große Sammeldatei.

Kurz gesagt:

Ja, 8.2k Zeichen reichen sehr plausibel aus, um genau diesen WebUI-Placeholder auszulösen.

Doku:

WebChat/History-Limits: https://docs.openclaw.ai/web/webchat
Config: https://docs.openclaw.ai/gateway/configuration

#

Wenn du willst, helfe ich dir jetzt beim Umbau von MEMORY.md in eine kurze, UI-freundliche Struktur.

cinder compass Apr 23, 2026, 1:11 PM

#

[chat.history omitted: message too large] kam jetzt nicht mehr nach /new

Erste Nachricht vom System:
A new session was started via /new or /reset. Execute your Session Startup sequence now - read the required files before responding to the user. If BOOTSTRAP.md exists in the provided Project Context, read it and follow its instructions first. Then greet the user in your configured persona, if one is provided. Be yourself - use your defined voice, mannerisms, and mood. Keep it to 1-3 sentences and ask what they want to do. If the runtime model differs from default_model in the system prompt, mention the default model. Do not mention internal steps, files, tools, or reasoning.
Current time: Thursday, April 23rd, 2026 - 15:00 (Europe/Berlin) / 2026-04-23 13:00 UTC

Danach die toolcalls vom agenten.

quaint epochBOT Apr 23, 2026, 1:12 PM

#

Ja, das sieht jetzt deutlich normaler aus. 👍

Wichtigster Punkt:

[chat.history omitted: message too large] kommt nach /new nicht mehr
das ist ein gutes Zeichen, dass der akute WebUI-/History-Blocker erst mal weg ist

Und die neue erste Systemnachricht ist plausibel / erwartet:

/new startet eine frische Session
OpenClaw gibt intern genau so einen Session-Startup-Prompt
danach liest der Agent oft erst die relevanten Workspace-Dateien
die Toolcalls direkt danach sind also erstmal normal

Kurz gesagt:

System-Startup-Prompt + anschließende Reads nach /new = erwartbares Verhalten

#

message too large direkt nach /new = das ungesunde Verhalten, und das scheint gerade weg zu sein

Ich würde jetzt einfach den echten Praxistest machen:

normale Nachricht schicken
5 bis 10 Turns arbeiten
beobachten, ob
- wieder schnelle Compactions kommen
- wieder ein kompletter Gesprächsverlust passiert

Wenn das jetzt stabil bleibt, wart ihr wahrscheinlich bei mehreren Ursachen gleichzeitig:

WebUI-History-Limit
Heartbeat-/Startup-Verhalten
ungeeignetes Compaction-Modell

Wenn es jetzt funktioniert: super.
Wenn nicht, dann sind wir immerhin schon deutlich näher dran.

#

Wenn das Problem jetzt wirklich weg ist, bitte Rechtsklick auf die Lösungsnachricht → Apps → ✅ Mark Solution. Das hilft Answer Overflow später enorm.

cinder compass Apr 23, 2026, 1:17 PM

#

Habe ich es jetzt richtig verstanden dass die einstellung aber verhindert, dass die anderen Bootstrap dateien gelesen werden?

quaint epochBOT Apr 23, 2026, 1:17 PM

#

Nicht alle. Es kommt darauf an, welche Einstellung du meinst:

1. `heartbeat.every: "0m"`

Das deaktiviert Heartbeats.
Laut Doku wird dann bei normalen Runs auch HEARTBEAT.md nicht mehr injiziert.

Aber:
die anderen Bootstrap-Dateien wie z. B.

AGENTS.md
SOUL.md
TOOLS.md
IDENTITY.md
USER.md
MEMORY.md (wenn vorhanden)

werden dadurch nicht pauschal abgeschaltet.

#

2. `startupContext.enabled: false`

Das betrifft nur den zusätzlichen /new-//reset-Startup-Prelude mit recent daily memory.

Also:

kein extra Startup-Context auf /new
aber nicht generell alle Bootstrap-Dateien aus

Kurz gesagt:

Heartbeat aus → vor allem HEARTBEAT.md raus
StartupContext aus → nur der zusätzliche /new-Vorlauf raus
die normalen Bootstrap-Dateien bleiben grundsätzlich aktiv

#

Also ja, du hast es teilweise richtig verstanden, aber nicht so, dass damit alle Bootstrap-Dateien komplett unterbunden würden.

cinder compass Apr 23, 2026, 1:22 PM

#

Was genau ist denn der StartupContext?

quaint epochBOT Apr 23, 2026, 1:24 PM

#

Der startupContext ist ein zusätzlicher Einmal-Kontext für den ersten Turn nach /new oder /reset.

Also nicht der normale Dauer-Bootstrap, sondern eher:

„Bevor die neue Session richtig loslegt, gib dem Agenten noch kurz etwas Startkontext mit.“

Typisch steckt da drin:

recent daily memory
also z. B. Inhalte aus memory/YYYY-MM-DD.md
begrenzt über Größenlimits, damit der erste Turn nicht ausufert

Wichtig ist der Unterschied:

Normaler Bootstrap

Das sind die üblichen Workspace-Dateien wie:

#

AGENTS.md
SOUL.md
TOOLS.md
IDENTITY.md
USER.md
MEMORY.md

Die gehören generell zum normalen Kontext.

`startupContext`

Das ist zusätzlich und nur:

bei /new
bei /reset
für den ersten Turn

Danach ist er wieder weg.

#

Darum ist startupContext.enabled: false oft ein guter Test, wenn man prüfen will:

ob der erste Turn zu fett wird
ob /new direkt komische Nebeneffekte erzeugt
ob recent daily memory den Start verschmutzt

Kurzform:

StartupContext = einmaliger Zusatz-Kontext für den Session-Start, nicht der normale Dauer-Bootstrap.

Wenn du willst, schreibe ich dir noch die 5 wichtigsten startupContext-Felder in ganz einfacher Sprache auf.

cinder compass Apr 23, 2026, 1:26 PM

#

Bei einem Gateway neustart bleiben aber weiterhin alle sessioncontexte ehalten? Oder hat dieser Parameter auch darauf einfluss?

#

Wo liegt die sessions.json? Er sagt die sei riesig.

quaint epochBOT Apr 23, 2026, 1:33 PM

#

Standardmäßig liegt sie hier:

~/.openclaw/agents/<agentId>/sessions/sessions.json

Für den Default-Agent ist das oft einfach:

~/.openclaw/agents/main/sessions/sessions.json

Wichtig:

sessions.json = Session-Metadaten
die eigentlichen Session-Dateien / Transcripts liegen im selben Bereich unter
~/.openclaw/agents/<agentId>/sessions/

#

Falls du eine ältere / Legacy-Struktur hast, kann auch noch sowas relevant sein:

~/.openclaw/agent/

Am sichersten ist:

openclaw status

Da siehst du die aktive State-/Store-Umgebung.

Doku:

#

Wenn du an der Datei irgendwas ändern willst, würde ich vorher den Gateway stoppen und erst mal nur Größe + Inhalt prüfen, nicht blind editieren.

cinder compass Apr 23, 2026, 1:40 PM

#

Die sessions.json ist 129000 Zeichen lang.

quaint epochBOT Apr 23, 2026, 1:41 PM

#

129000 Zeichen ist auffällig, aber noch nicht automatisch „kaputt“.

Wichtiger Punkt:

sessions.json ist eher die Session-Metadatei, nicht die eigentliche Chat-History.

Darum würde ich sagen:

ja, recht groß
nein, wahrscheinlich nicht die Hauptursache für
[chat.history omitted: message too large]

Für dein konkretes Symptom sind meistens interessanter:

die einzelnen Session-Transcripts
oder große Tool-Resultate innerhalb einer Session

#

Also eher:

~/.openclaw/agents/main/sessions/

und dort die größten Dateien anschauen, nicht nur sessions.json.

Ich würde als Nächstes nicht blind an sessions.json herumeditieren, sondern erst prüfen:

du -ah ~/.openclaw/agents/main/sessions | sort -h | tail -20

Damit siehst du schnell, welche Dateien wirklich groß sind.

Meine Einschätzung gerade:

#

129k sessions.json = nicht schön, aber noch nicht der Smoking Gun
riesige einzelne Session-Dateien / Tool-Blöcke = deutlich verdächtiger

Wenn du magst, gehen wir als Nächstes genau die größten 3 Dateien durch.

cinder compass Apr 23, 2026, 1:51 PM

#

du -ah ~/.█/█/█/sessions | sort -h | tail -20
1.7M /home/█/.█/█/█/sessions/█-█-█-█-█.checkpoint.█-█-█-█-█.jsonl.deleted.2026-04-23T09-26-26.786Z
2.1M /home/█/.█/█/█/sessions/█-█-█-█-█.checkpoint.█-█-█-█-█.jsonl.deleted.2026-04-20T12-18-39.899Z
2.2M /home/█/.█/█/█/sessions/█-█-█-█-█.jsonl.deleted.2026-04-23T12-01-12.515Z
2.7M /home/█/.█/█/█/sessions/█-█-█-█-█.checkpoint.█-█-█-█-█.jsonl.deleted.2026-04-20T12-18-39.899Z
3.2M /home/█/.█/█/█/sessions/█-█-█-█-█.jsonl.deleted.2026-04-23T09-26-26.786Z
3.4M /home/█/.█/█/█/sessions/█-█-█-█-█.checkpoint.█-█-█-█-█.jsonl.deleted.2026-04-20T12-18-39.899Z
3.9M /home/█/.█/█/█/sessions/█-█-█-█-█.checkpoint.█-█-█-█-█.jsonl.deleted.2026-04-20T12-18-39.899Z
4.4M /home/█/.█/█/█/sessions/█-█-█-█-█.checkpoint.█-█-█-█-█.jsonl.deleted.2026-04-21T13-01-51.663Z
6.2M /home/█/.█/█/█/sessions/█-█-█-█-█.checkpoint.█-█-█-█-█.jsonl.deleted.2026-04-22T19-25-32.225Z
8.6M /home/█/.█/█/█/sessions/█-█-█-█-█.checkpoint.█-█-█-█-█.jsonl.deleted.2026-04-22T19-25-32.225Z
9.2M /home/█/.█/█/█/sessions/█-█-█-█-█.checkpoint.█-█-█-█-█.jsonl.deleted.2026-04-22T19-25-32.225Z
9.8M /home/█/.█/█/█/sessions/█-█-█-█-█.checkpoint.█-█-█-█-█.jsonl.deleted.2026-04-22T19-25-32.225Z
11M /home/█/.█/█/█/sessions/█-█-█-█-█.checkpoint.█-█-█-█-█.jsonl.deleted.2026-04-22T19-25-32.225Z
11M /home/█/.█/█/█/sessions/█-█-█-█-█.checkpoint.█-█-█-█-█.jsonl.deleted.2026-04-22T19-25-32.225Z
12M /home/█/.█/█/█/sessions/█-█-█-█-█.checkpoint.█-█-█-█-█.jsonl.deleted.2026-04-22T19-25-32.225Z
13M /home/█/.█/█/█/sessions/█-█-█-█-█.checkpoint.█-█-█-█-█.jsonl.deleted.2026-04-22T20-22-41.406Z
13M /home/█/.█/█/█/sessions/█-█-█-█-█.checkpoint.█-█-█-█-█.jsonl.deleted.2026-04-22T20-22-41.406Z
13M /home/█/.█/█/█/sessions/█-█-█-█-█.checkpoint.█-█-█-█-█.jsonl.deleted.2026-04-22T20-22-41.406Z
13M /home/█/.█/█/█/sessions/█-█-█-█-█.jsonl.reset.2026-04-22T20-17-18.142Z
161M /home/█/.█/█/█/sessions

quaint epochBOT Apr 23, 2026, 1:52 PM

#

Das ist jetzt ziemlich eindeutig. Ich prüfe kurz die Doku, ob es für diese *.jsonl.deleted.* / *.jsonl.reset.* Dateien einen vorgesehenen Cleanup-Pfad gibt, bevor ich dir was Riskantes rate.

#

Ja, das ist jetzt der eigentliche Brocken.

Die auffälligen Dateien sind nicht sessions.json, sondern vor allem:

*.jsonl.deleted.*
*.jsonl.reset.*
*.checkpoint.*.jsonl.deleted.*

Also archivierte / gelöschte / zurückgesetzte Session-Transcripts.

Meine Einschätzung:

161 MB im sessions/-Ordner ist deutlich zu viel
das erklärt sehr gut, warum bei dir alles nach viel Reset-/Delete-/Checkpoint-Churn aussieht
sessions.json war eher Nebengeräusch, die Archive sind der eigentliche Ballast

Wichtig dabei:

#

diese Dateien sind nicht die aktive Live-Session
ich würde daher nicht an sessions.json herumdoktern
sondern, wenn überhaupt, an den alten *.deleted.* / *.reset.*-Archiven

Eine wichtige Nuance aus der Doku:

cron.sessionRetention räumt Cron-/isolierte Run-Sessions auf
das ist nicht automatisch ein allgemeiner Putzdienst für alle normalen Session-Archive

Also mein pragmatischer Rat:

Gateway stoppen
die alten *.jsonl.deleted.* / *.jsonl.reset.* Dateien erst mal nur wegsichern / auslagern, nicht blind endgültig löschen
Gateway wieder starten
neu testen

Wenn danach wieder schnell neue Archive in Massen entstehen, würde ich das als Bug-Kandidat sehen und auf GitHub melden: https://github.com/openclaw/openclaw/issues

#

Kurz:

Ja, das Sessions-Verzeichnis ist das Problemfeld.
Nein, sessions.json ist nicht der Haupttäter.
Die alten archivierten Transcript-Dateien sind viel verdächtiger.

Wenn du willst, sage ich dir als Nächstes genau, welche Dateimuster ich gefahrlos zuerst auslagern würde.

supple stoneBOT Apr 23, 2026, 1:53 PM

#

#Openclaw verliert in kurzen Abständen den Gesprächsfaden

Option A, schnellster UI-Fix

Option B, saubererer Langzeit-Fix

1. heartbeat.every: "0m"

2. startupContext.enabled: false

Normaler Bootstrap

startupContext

1. `heartbeat.every: "0m"`

2. `startupContext.enabled: false`

`startupContext`