Después de que el autor descompuso una carga de trabajo de OpenClaw, descubrió que el 79% del consumo de tokens proviene de la repetición de prefijos en caché (cached prefix replay), en lugar de la entrada del usuario o la salida del modelo, y propuso tres estrategias de optimización contextual que efectivamente reducen los costos operativos de los Agentes de IA. Este artículo se basa en un artículo escrito por MOSHIII (Why My OpenClaw Sessions Burned 21.5M Tokens in a Day (And What Actually Fixed It)), editado y traducido por Dongqu. (Resumen: MEXC se posiciona entre los 3 principales CEX globales, profundizando su presencia en el mercado de spot y productos básicos) (Contexto adicional: En un mercado bajista, los ingresos se generan a partir de monedas estables: comparación de tasas de interés de plataformas OSL 18%, MEXC 15%, Binance 8%...) Analicé una carga de trabajo real de OpenClaw y encontré un patrón que creo que muchos usuarios de Agentes reconocerán: el consumo de tokens parece muy "activo" Las respuestas parecen también muy normales pero el consumo de tokens de repente se dispara. A continuación, se presentan el desglose estructural de este análisis, las causas fundamentales y las rutas de reparación prácticas. Mayor impulsor de costos: repetición de prefijos en caché. El principal factor impulsor de costos no es que los mensajes de los usuarios sean demasiado largos, sino que enormes prefijos en caché están siendo reproducidos repetidamente. Desde los datos de sesión: Total de tokens: 21,543,714 cacheRead: 17,105,970 (79.40%) input: 4,345,264 (20.17%) output: 92,480 (0.43%) En otras palabras: la mayor parte del costo de las llamadas no proviene de procesar nuevas intenciones del usuario, sino de leer repetidamente enormes contextos históricos. Originalmente pensé que el alto consumo de tokens provenía de: prompts de usuario muy largos, generación de salidas masivas o llamadas a herramientas costosas. Pero el verdadero patrón dominante es: input: cientos a miles de tokens cacheRead: cada llamada entre 170,000 y 180,000 tokens, es decir, el modelo está leyendo repetidamente el mismo enorme prefijo estable en cada ronda. Desglose de datos de sesión. Analicé datos en dos niveles: 1. Registros de tiempo de ejecución (runtime logs) 2. Registros de sesiones (session transcripts) Cabe aclarar que: los registros de ejecución se utilizan principalmente para observar señales de comportamiento (como reinicios, errores, problemas de configuración) Las estadísticas precisas de tokens provienen de la columna de uso en el JSONL de la sesión. Los scripts utilizados: scripts/session_token_breakdown.py scripts/session_duplicate_waste_analysis.py Archivos de análisis generados: tmp/session_token_stats_v2.txt tmp/session_token_stats_v2.json tmp/session_duplicate_waste.txt tmp/session_duplicate_waste.json tmp/session_duplicate_waste.png Hay una sesión cuyo consumo es mucho más alto que las demás: 570587c3-dc42-47e4-9dd4-985c2a50af86: 19,204,645 tokens y luego hay una caída abrupta evidente: ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1,505,038 ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649,584 tokens principalmente provenientes de: toolUse: 16,372,294 stop: 5,171,420 indicando que el problema radica principalmente en el ciclo de llamadas a herramientas, y no en conversaciones normales. ¿De dónde provienen los picos de tokens? Los picos de tokens no son aleatorios, sino que están concentrados en unos pocos períodos de horas: 2026-03-08 16:00: 4,105,105 2026-03-08 09:00: 4,036,070 2026-03-08 07:00: 2,793,648 No se trata del contenido de la conversación, sino principalmente de grandes productos intermedios: enormes bloques de datos toolResult trazas de razonamiento/pensamiento muy largas grandes instantáneas JSON lista de archivos datos de rastreo del navegador registros de conversación de subagentes En la sesión más grande, la cantidad de caracteres es aproximadamente: toolResult:text: 366,469 caracteres assistant:thinking: 331,494 caracteres assistant:toolCall: 53,039 caracteres Una vez que este contenido se mantiene en el contexto histórico, cada llamada posterior puede volver a leerlo a través del prefijo en caché. En los siguientes lugares, aparecen repetidamente bloques de contexto de gran volumen: sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70 Registro JSON del gran portal (aproximadamente 37,000 caracteres) sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134 instantánea del navegador + paquete de seguridad (aproximadamente 29,000 caracteres) sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219 salida de lista de archivos masiva (aproximadamente 41,000 caracteres) sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311 instantánea de estado de sesión/status + estructura de grandes prompts (aproximadamente 30,000 caracteres) También medí la proporción de contenido repetido dentro de una sola llamada: la proporción de repetición es aproximadamente: 1.72% existe, pero no es el problema principal. El verdadero problema es: el volumen absoluto de prefijos en caché es demasiado grande. La estructura es: un enorme contexto histórico, lectura repetida en cada llamada, donde solo se superponen unas pocas nuevas entradas. Por lo tanto, el enfoque de optimización no es la reducción, sino el diseño de la estructura del contexto. Tres mecanismos de expansión del contexto. Tres mecanismos se superponen entre sí: 1. Una gran cantidad de salidas de herramientas se escriben en el contexto histórico 2. Los ciclos de herramientas generan una gran cantidad de llamadas de corta duración 3. Cambios mínimos en el prefijo → el caché se vuelve a leer en cada llamada. Si la compactación del contexto no se activa de manera estable, el problema se amplificará rápidamente. Estrategias de optimización en la práctica. Para salidas de herramientas masivas: · Mantener resúmenes ...