¿Cómo sucede esto con OpenClaw y cómo puedes solucionarlo… Mi bot continuamente arroja enormes resultados de herramientas repetitivas, realiza un trabajo de ejecución pesado y entra en bucles de depuración en la sesión compartida en la que están mis DMs y se queda atascado durante 10 minutos a la vez hasta que se agota o el gateway se bloquea y reinicia. Esto causa mensajes perdidos, un bot que no responde y fallos de OOM múltiples veces por hora. Incluso cuando logro que el bot delegue, los subagentes arrojan resultados en la ventana de contexto. Hice que Codex investigara y encontró: • 56 resultados de herramientas ≥150k caracteres ya incorporados en el historial de la sesión actual • La poda no funciona en nuestra ruta de modelo principal (Codex/OpenAI Oauth) • No hay aplicación en tiempo de ejecución para detener grandes volúmenes de resultados de herramientas en el contexto • El mantenimiento de la sesión limpia después del daño, no lo previene Estoy bastante seguro de que el comportamiento predeterminado de OpenClaw no debería estar arrojando resultados de herramientas de 200k caracteres en la transcripción. Algo en mi configuración específica debe estar desactivando una salvaguarda o saltándose la truncación de los resultados de herramientas… Dado que estoy usando lossless-claw, se permite que crezca aún más: Archivo de sesión de 81MB, 31.6MB es solo texto de resultados de herramientas 😬 169 resultados de herramientas de más de 50k caracteres. Uno tiene 285k caracteres (de sessions_list.) Hay lógica de poda que recorta los resultados de herramientas de los mensajes de contexto. buildContextPruningFactory Pero los modelos tienen que ser “cache-ttl" Los proveedores elegibles son aparentemente solo: anthropic moonshot zai Para mí, mi bot me dice que el código de poda se niega a activarse en proveedores que no son de Anthropic. Estoy usando openai-codex 5.3 mucho, así que cuando la poda está configurada, el código existe, simplemente nunca se activa en silencio. La API de Respuestas de OpenAI utiliza compactación del lado del servidor y OpenClaw lo habilita automáticamente para modelos directos de openai, por lo que OpenAI maneja la compactación de su lado. Pero estoy en openai-codex/*, no en openai/*. La ruta de OAuth de Codex pasa por un tiempo de ejecución diferente (aparentemente pi-ai), no por la API de Respuestas. Así que: • poda cache-ttl > solo Anthropic • compactación del lado del servidor de OpenAI > solo API directa de openai • LCM/lossless-claw > no poda resultados de herramientas antiguos que yo sepa Mi bot insiste en que el carril openai-codex no recibe ninguno de los caminos de poda. Así que me quedo con un bot que depende de la función de truncamiento de emergencia truncateOversizedToolResultsInSession con demasiada frecuencia como recuperación de desbordamiento de último recurso sin poda preventiva / salvaguardas. Dado que LCM/lossless-claw no tiene su propia gestión de resultados de herramientas, hereda transcripciones enormes y sobredimensionadas y tiene que trabajar más duro para resumir para los nodos DAG. No tengo mantenimiento de sesión y sesiones largas, así que nada limita la transcripción con el tiempo resultando en: 4,707 resultados de herramientas acumulándose para siempre en un archivo de 81MB, sin ningún mecanismo de tiempo de ejecución que realmente los limpie. Cuando mi bot comienza a depurar, comienza a buscar y arrojar texto masivo en la sesión principal, luego se queda atascado en ese bucle y muere y tiene que hacerlo de nuevo, agravando el problema. Estoy perdido sobre cómo abordar este problema, es múltiple capas de profundidad.

@quinnzeda Pero podrías tener razón... Tal vez tenga que tomarme una semana libre antes de intentar esto.