¿Cómo puede pasar esto con OpenClaw y cómo se puede arreglar... Mi bot continuamente genera resultados enormes y repetitivos de herramientas, hace trabajo pesado de ejecutivos 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 hasta que se apaga el tiempo o el gateway se cierra y se reinicia. Esto provoca mensajes perdidos, bots no responsivos y caídas de OOM varias veces por hora. Incluso cuando consigo que el bot delegue, los subagentes volcan los resultados en la ventana de contexto. Pedí a Codex que investigara y encontró: • 56 resultados de herramientas ≥150.000 caracteres ya integrados en el historial actual de la sesión • La poda no funciona en nuestro camino principal del modelo (Codex/OpenAI Oauth) • No hay aplicación en tiempo de ejecución para evitar grandes volcados de herramientas en contexto • El mantenimiento de sesión limpia después del daño, no lo previene Estoy bastante seguro de que el comportamiento por defecto de OpenClaw no debería estar vertiendo resultados de la herramienta de 200k caracteres en la transcripción. Algo en mi configuración específica debe ser desactivar una salvaguarda o saltarse el truncamiento para obtener resultados de herramientas... Como uso garra sin pérdida, se permite que crezca aún peor: Archivo de sesión de 81MB, 31,6MB es solo texto 😬 de resultados de herramientas 169 resultados de herramientas en 50.000 caracteres. Uno tiene 285.000 caracteres (de sessions_list). Hay una lógica de poda que recorta los resultados de la herramienta a partir de los mensajes contextuales. buildContextPodingFactory Pero los modelos tienen que ser "cache-ttl" Los proveedores elegibles aparentemente son solo: Antrópico Moonshot Zai En mi caso, mi bot me dice que el código de poda se niega a activarse en proveedores no antrópicos. Uso mucho openai-codex 5.3, así que cuando se configura la poda, el código existe, simplemente nunca se activa en silencio. La API de OpenAI Responses utiliza compactación en el lado del servidor y OpenClaw habilita esto automáticamente para modelos OpenAI directos, de modo que OpenAI gestiona la compactación por su lado. Pero estoy en openai-codex/*, no en openai/*. La ruta de Codex OAuth 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 en el lado del servidor > solo API OpenAI directa • LCM/lossless-claw > no poda resultados de herramientas antiguas que yo sepa Mi bot insiste en que la línea openai-codex no recibe ninguna de las dos rutas de poda. Así que me quedo con un bot que depende demasiado a menudo de la función de truncamiento de emergencia de OversizedToolResultsInSession como último recurso para la recuperación de desbordamiento, sin poda preventiva ni salvaguardas. Como LCM/lossless-claw no tiene su propia herramienta de gestión de resultados, hereda transcripciones enormes y sobredimensionadas y tiene que esforzarse mucho para resumir los nodos DAG. No tengo mantenimiento de sesiones y sesiones largas, así que nada limita la transcripción a lo largo del tiempo, lo que resulta en: 4.707 resultados de herramientas acumulándose sin fin en un archivo de 81MB, sin ningún mecanismo de ejecución que los limpie realmente. Cuando mi bot empieza a depurar, empieza a hacer grepping y a enviar texto enorme a la sesión principal, luego se queda atascado en ese bucle, muere y tiene que repetirlo, agravando el problema. No sé cómo abordar este problema, tiene varias capas.

@quinnzeda Pero puede que tengas razón... Aunque puede que tenga que tomarme una semana de descanso antes de intentarlo.