Hoe gebeurt dit met OpenClaw en hoe kun je het mogelijk oplossen… Mijn bot dump continu enorme repetitieve toolresultaten, doet zware uitvoeringswerkzaamheden en komt in debugloops in de gedeelde sessie waarin mijn DMs zich bevinden en blijft 10 minuten vastzitten totdat hij time-out of de gateway crasht en opnieuw opstart. Dit veroorzaakt verloren berichten, een niet-reagerende bot en OOM-crashes meerdere keren per uur. Zelfs wanneer ik de bot laat delegeren, dumpen de subagenten resultaten in het contextvenster. Ik heb Codex laten onderzoeken en het vond: • 56 toolresultaten ≥150k tekens al ingebakken in de huidige sessiegeschiedenis • Pruning werkt niet op ons primaire modelpad (Codex/OpenAI Oauth) • Geen runtime handhaving om enorme tool dumps in de context te stoppen • Sessiebeheer ruimt de schade op, het voorkomt het niet Ik ben er vrij zeker van dat het standaardgedrag van OpenClaw niet zou moeten zijn om 200k tekens toolresultaten in het transcript te dumpen. Iets in mijn specifieke setup moet ofwel een beveiliging uitschakelen of truncatie voor toolresultaten overslaan… Aangezien ik lossless-claw gebruik, mag het zelfs nog erger worden: 81MB sessiebestand, 31,6MB is alleen al tekst van toolresultaten 😬 169 toolresultaten van meer dan 50k tekens. Eén is 285k tekens (van sessions_list.) Er is pruninglogica die toolresultaten uit de contextberichten trimt. buildContextPruningFactory Maar modellen moeten "cache-ttl" zijn De in aanmerking komende aanbieders zijn blijkbaar alleen: anthropic moonshot zai Voor mij vertelt mijn bot dat de pruningcode weigert te activeren op niet-Anthropic aanbieders. Ik gebruik openai-codex 5.3 veel, dus wanneer pruning is geconfigureerd, bestaat de code, het activeert gewoon stilzwijgend nooit. OpenAI Responses API gebruikt server-side compaction & OpenClaw schakelt dit automatisch in voor directe openai-modellen, zodat OpenAI de compaction aan hun kant afhandelt. Maar ik ben op openai-codex/*, niet openai/*. Het Codex OAuth-pad gaat door een andere runtime (blijkbaar pi-ai), niet de Responses API. Dus: • cache-ttl pruning > Alleen Anthropic • OpenAI server-side compaction > alleen directe openai API • LCM/lossless-claw > prune oude toolresultaten afaik niet Mijn bot volhardt dat het openai-codex pad geen van beide pruningpaden krijgt. Dus ik blijf achter met een bot die te vaak afhankelijk is van de noodtruncatiefunctie truncateOversizedToolResultsInSession als laatste redmiddel voor overflowherstel zonder preventieve pruning / beveiligingen. Aangezien LCM/lossless-claw geen eigen toolresultaatbeheer heeft, erft het enorme oversized transcripts en moet het extra hard werken om samen te vatten voor DAG-knooppunten. Ik heb geen sessiebeheer en lange sessies, dus er is niets dat het transcript in de loop van de tijd beperkt, wat resulteert in: 4.707 toolresultaten die voor altijd opstapelen in een bestand van 81MB, zonder dat er een runtime-mechanisme is dat ze daadwerkelijk opruimt. Wanneer mijn bot begint met debuggen, begint hij enorme tekst in de hoofdsectie te greppen en te dumpen, komt dan vast te zitten in die lus en sterft dan en moet het opnieuw doen, wat het probleem verergert. Ik weet niet hoe ik dit probleem moet aanpakken, het is meerdere lagen diep.

@quinnzeda Maar je zou wel eens gelijk kunnen hebben... Ik moet misschien wel een week vrij nemen voordat ik dit probeer.