Cum se întâmplă asta cu OpenClaw și cum poți să o rezolvi... Botul meu afișează constant rezultate masive și repetitive ale uneltelor, face muncă grea de executiv și intră în bucle de depanare în sesiunea partajată în care sunt DM-ii mei și rămâne blocat 10 minute până când expiră timpul sau gateway-ul se blochează și repornește. Acest lucru cauzează mesaje pierdute, bot nereceptiv și blocarea OOM de mai multe ori pe oră. Chiar și când reușesc să dau delegării botului, subagenții afișează rezultatele în fereastra de context. L-am pus pe Codex să investigheze și a găsit: • 56 de rezultate ale uneltelor ≥150k caractere deja integrate în istoricul actual al sesiunilor • Tăierea nu funcționează pe calea principală a modelului (Codex/OpenAI Oauth) • Nicio aplicare la runtime pentru a opri dump-uri uriașe de unelte în context • Întreținerea în sesiune curăță după deteriorare, nu o previne Sunt destul de sigur că comportamentul implicit al OpenClaw nu ar trebui să arunce rezultatele uneltei de 200k caractere în transcriere. Ceva în configurația mea specifică trebuie să fie fie dezactivarea unei măsuri de siguranță, fie sărirea peste trunchiere pentru rezultatele uneltei... Deoarece folosesc lossless-claw, are voie să crească și mai rău: 81MB fișier de sesiune, 31,6MB sunt doar text 😬 pentru rezultatul uneltei 169 de rezultate ale uneltelor peste 50.000 de personaje. Unul are 285.000 de caractere (din sessions_list). Există logică de tăiere care reduce rezultatele uneltelor din mesajele contextuale. buildContextPruningFactory Dar modelele trebuie să fie "cache-ttl" Furnizorii eligibili sunt aparent doar: Antropic Moonshot Zai Pentru mine, botul meu îmi spune că codul de tăiere refuză să se activeze pe furnizorii non-Anthropic. Folosesc mult openai-codex 5.3, așa că atunci când tăierea este configurată, codul există, doar că nu se activează în liniște. API-ul OpenAI Responses folosește compactarea pe partea serverului și OpenClaw permite automat acest lucru pentru modelele OpenAI directe, astfel încât OpenAI gestionează compactarea pe partea lor. Dar eu sunt pe openai-codex/*, nu pe openai/*. Calea Codex OAuth trece printr-un alt runtime (aparent pi-ai), nu prin API-ul Responses. Deci: • tăiere cache-ttl > doar anthropic • Compactare OpenAI pe partea de server > doar API OpenAI directă • LCM/lossless-claw > nu taie rezultatele vechilor unelte, din câte știu Botul meu insistă că linia openai-codex nu primește niciuna dintre căile de tăiere. Așadar, am rămas cu un bot care se bazează prea des pe funcția de trunchiare de urgențăOversizedToolResultsInSession ca ultimă soluție de recuperare prin prea mult, fără tăiere preventivă sau măsuri de siguranță. Deoarece LCM/lossless-claw nu are propriul său instrument de management al rezultatelor, moștenește transcripturi uriașe și supradimensionate și trebuie să muncească din greu pentru a rezuma nodurile DAG. Nu am întreținere de sesiune și sesiuni lungi, așa că nimic nu limitează transcrierea în timp, rezultând în: 4.707 rezultate ale uneltelor se adună la nesfârșit într-un fișier de 81MB, fără niciun mecanism de rulare care să le curețe efectiv. Când botul meu începe să depaneze, începe să facă grepping și să arunce text masiv în sesiunea principală, apoi rămâne blocat în acea buclă și moare și trebuie să o facă din nou, agravând problema. Nu știu cum să abordez această problemă, este în mai multe straturi.

@quinnzeda Dar s-ar putea să ai dreptate... Totuși, s-ar putea să trebuiască să iau o săptămână liberă înainte să încerc asta.