Wie passiert das mit OpenClaw und wie kann man das möglicherweise beheben… Mein Bot gibt ständig massive, sich wiederholende Tool-Ergebnisse aus, führt umfangreiche Ausführungsarbeiten durch und gerät in Debug-Schleifen in der gemeinsamen Sitzung, in der sich meine DMs befinden, und bleibt bis zu 10 Minuten lang stecken, bis er ausläuft oder das Gateway abstürzt und neu startet. Das führt zu verlorenen Nachrichten, einem nicht reagierenden Bot und OOM-Abstürzen mehrmals pro Stunde. Selbst wenn ich den Bot dazu bringe, zu delegieren, geben die Subagenten Ergebnisse in das Kontextfenster aus. Ich habe Codex beauftragt, nachzuforschen, und es hat Folgendes gefunden: • 56 Tool-Ergebnisse ≥150k Zeichen bereits in die aktuelle Sitzungsverlauf eingebaut • Pruning funktioniert nicht auf unserem primären Modellpfad (Codex/OpenAI Oauth) • Keine Laufzeitanwendung, um große Tool-Dumps in den Kontext zu stoppen • Die Sitzungswartung räumt nach dem Schaden auf, sie verhindert ihn nicht Ich bin mir ziemlich sicher, dass das Standardverhalten von OpenClaw nicht darin bestehen sollte, 200k Zeichen Tool-Ergebnisse in das Transkript zu dumpen. Etwas in meinem spezifischen Setup muss entweder eine Sicherheitsvorkehrung deaktivieren oder die Trunkierung für Tool-Ergebnisse überspringen… Da ich lossless-claw verwende, darf es sogar noch schlimmer werden: 81MB Sitzungsdatei, 31,6MB sind nur Tool-Ergebnistext 😬 169 Tool-Ergebnisse über 50k Zeichen. Eines hat 285k Zeichen (aus sessions_list.) Es gibt eine Pruning-Logik, die Tool-Ergebnisse aus den Kontextnachrichten trimmt. buildContextPruningFactory Aber Modelle müssen "cache-ttl" sein Die berechtigten Anbieter sind anscheinend nur: anthropic moonshot zai Für mich sagt mein Bot, dass der Pruning-Code sich weigert, bei nicht-Anthropic-Anbietern zu aktivieren. Ich benutze openai-codex 5.3 viel, also wenn Pruning konfiguriert ist, existiert der Code, er aktiviert sich nur stillschweigend nie. Die OpenAI Responses API verwendet serverseitige Kompression & OpenClaw aktiviert dies automatisch für direkte OpenAI-Modelle, sodass OpenAI die Kompression auf ihrer Seite übernimmt. Aber ich bin auf openai-codex/*, nicht openai/*. Der Codex OAuth-Pfad geht durch eine andere Laufzeit (anscheinend pi-ai), nicht die Responses API. Also: • cache-ttl Pruning > Nur Anthropic • OpenAI serverseitige Kompression > Nur direkte OpenAI API • LCM/lossless-claw > schneidet alte Tool-Ergebnisse afaik nicht ab Mein Bot besteht darauf, dass der openai-codex-Pfad keinen der Pruning-Pfade erhält. Also habe ich einen Bot, der viel zu oft auf die Notfall-Trunkierungsfunktion truncateOversizedToolResultsInSession als letzte Rückfallwiederherstellung angewiesen ist, ohne präventives Pruning/Sicherheitsvorkehrungen. Da LCM/lossless-claw kein eigenes Tool-Ergebnismanagement hat, erbt es riesige übergroße Transkripte und muss extra hart arbeiten, um für DAG-Knoten zusammenzufassen. Ich habe keine Sitzungswartung und lange Sitzungen, sodass nichts das Transkript über die Zeit bindet, was zu führt: 4.707 Tool-Ergebnisse, die für immer in einer 81MB-Datei ansammeln, ohne dass ein Laufzeitmechanismus sie tatsächlich bereinigt. Wenn mein Bot mit dem Debuggen beginnt, beginnt er, massive Texte in die Hauptsitzung zu greppen und auszugeben, gerät dann in diese Schleife und stirbt, dann muss er es wieder tun, was das Problem verstärkt. Ich bin ratlos, wie ich dieses Problem angehen soll, es ist mehrere Ebenen tief.

@quinnzeda Aber du könntest recht haben… Ich könnte jedoch eine Woche frei nehmen, bevor ich das versuche.