Por qué mis sesiones de OpenClaw quemaron 21,5 millones de tokens en un día (y qué realmente lo solucionó)
Autor original: MOSHIII
Compilación original: Peggy, BlockBeats
Nota del editor: En la actualidad, con la rápida adopción de aplicaciones de Agent, muchos equipos han observado un fenómeno aparentemente paradójico: el sistema funciona correctamente, pero el costo de los tokens aumenta constantemente sin que se note. A través del análisis de una carga de trabajo real de OpenClaw, se descubrió que la causa del aumento exponencial de costos generalmente no proviene de la entrada del usuario ni de la salida del modelo, sino del olvidado reproductor de contexto en caché (cached prefix replay). El modelo vuelve a leer repetidamente un contexto histórico extenso en cada llamada, generando un consumo masivo de tokens.
El artículo, combinando datos de sesión específicos, muestra cómo los grandes productos intermedios, como la salida de la herramienta, capturas de pantalla del navegador y registros JSON, se escriben continuamente en el contexto histórico y se leen repetidamente en el ciclo del agente.
A través de este caso, el autor presenta una estrategia clara de optimización: desde el diseño de la estructura del contexto, la gestión de la salida de herramientas hasta la configuración del mecanismo de compaction. Para desarrolladores que están construyendo sistemas de Agentes, esto no solo es un registro de diagnóstico técnico, sino también una guía práctica para ahorrar dinero.
A continuación se encuentra el texto original:
Analicé una carga de trabajo real de OpenClaw y encontré un patrón que creo que muchos usuarios de Agent reconocerán:
El uso del token parece muy «activo»
La respuesta también parece normal
Pero el consumo de tokens experimentó un crecimiento explosivo repentino
A continuación, se presenta la descomposición estructural, la causa raíz y la ruta de reparación práctica para este análisis.
TL;DR
El factor de costo más grande no es que los mensajes de los usuarios sean demasiado largos, sino la gran cantidad de prefijos en caché (cached prefix) que se reproducen repetidamente.
Según los datos de la sesión:
Tokens totales: 21,543,714
cacheRead: 17.105.970 (79,40%)
4.345.264 (20,17%)
salida: 92.480 (0,43%)
En otras palabras: el costo de la mayoría de las llamadas no se debe a procesar nuevas intenciones de usuario, sino a leer repetidamente un contexto histórico muy extenso.
El momento de «Espera, ¿cómo es posible esto?»
Originalmente pensaba que el alto uso de tokens provenía de: prompts de usuario muy largos, una gran cantidad de generación de salida o llamadas a herramientas costosas.
Pero el patrón realmente dominante es:
Cientos a miles de tokens
cacheRead: cada llamada de 170.000 a 180.000 tokens
Es decir, el modelo lee repetidamente el mismo prefijo estable y enorme en cada ronda.
Rango de datos
Analicé los datos en dos niveles:
1. Registros de ejecución (runtime logs)
2. Registros de sesión (session transcripts)
Se debe señalar que:
Los registros de ejecución se utilizan principalmente para observar señales de comportamiento (como reinicios, errores o problemas de configuración).
Las estadísticas precisas de tokens provienen del campo usage del archivo JSONL de la sesión.
Script utilizado:
scripts/session_token_breakdown.py
scripts/session_duplicate_waste_analysis.py
Archivo de análisis generado:
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
¿Dónde se consumen realmente los tokens?
1) Sesión concentrada
Una sesión consume mucho más que las demás:
570587c3-dc42-47e4-9dd4-985c2a50af86: 19,204,645 tokens
Luego viene una caída claramente abrupta:
ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1.505.038
ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649.584
2) Conducta centrada
Los tokens provienen principalmente de:
toolUse：16,372,294
detener: 5.171.420
El problema radica principalmente en el bucle de la cadena de llamadas a herramientas, no en el chat normal.
3) Concentración de tiempo
Los picos de tokens no son aleatorios, sino que se concentran en varios períodos horarios:
2026-03-08 16:00: 4.105.105
2026-03-08 09:00: 4.036.070
2026-03-08 07:00: 2.793.648
¿Qué hay en el enorme prefijo de caché?
No es el contenido de la conversación, sino principalmente el gran subproducto:
Bloque de datos toolResult enorme
Largas trazas de razonamiento / pensamiento
Gran instantánea JSON
Lista de archivos
El navegador recopila datos
Registro de conversación del subagente
En la sesión máxima, la cantidad de caracteres es aproximadamente:
366,469 caracteres
assistant:thinking：331,494 caracteres
assistant:toolCall：53,039 caracteres
Una vez que estos contenidos se mantengan en el contexto histórico, cada llamada posterior podría volver a leerlos mediante el prefijo cache.
Ejemplos específicos (del archivo de sesión)
En la siguiente ubicación se han repetido bloques de contexto de gran volumen:
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70
Registro JSON de puerta de enlace grande (aproximadamente 37 000 caracteres)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134
Captura del navegador + envoltura segura (aproximadamente 29.000 caracteres)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219
Lista de archivos enorme (aproximadamente 41 000 caracteres)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311
session/status instantánea de estado + estructura de prompt grande (aproximadamente 30.000 caracteres)
«Desperdicio de contenido repetido» vs «Carga de retransmisión de caché»
También medí la proporción de contenido repetido dentro de una sola llamada:
Proporción de repetición aproximada: 1.72%
Indeed exists, but it is not the main issue.
El problema real es que el volumen absoluto del prefijo de caché es demasiado grande.
La estructura es: un contexto histórico enorme, volver a leer en cada llamada, y solo agregar una pequeña cantidad de entrada nueva encima
Por lo tanto, el enfoque de la optimización no es la eliminación de duplicados, sino el diseño de la estructura del contexto.
¿Por qué el ciclo de Agent es particularmente propenso a este problema?
Tres mecanismos se superponen:
1. Se han escrito muchas salidas de herramientas en el contexto histórico
2. El ciclo de herramientas generará muchas llamadas con intervalos cortos.
3. El prefijo cambia muy poco → la caché se vuelve a leer cada vez
Si la compactación del contexto no se activa de manera estable, el problema se amplificará rápidamente.
Las estrategias de reparación más importantes (ordenadas por impacto)
P0—No insertes salidas de herramientas enormes en el contexto prolongado
Para salida de herramienta supergrande:
- Mantener el resumen + ruta/ID de referencia
- Escribir el payload original en el archivo artifact
- No mantenga el texto original completo en el historial del chat
Limitar优先这些 categorías:
- JSON grande
- Lista larga de directorios
- Captura completa del navegador
- Transcripción completa del subagente
P1—Asegúrate de que el mecanismo de compaction funcione realmente
En estos datos, los problemas de compatibilidad de configuración aparecen múltiples veces: clave de compactación no válida
Esto cerrará silenciosamente el mecanismo de optimización.
Práctica correcta: utilice solo configuraciones compatibles con la versión
Luego verifica:
openclaw doctor --fix
Y verifique los registros de inicio para confirmar que la compactación fue aceptada.
P1—Reducir la persistencia de texto de razonamiento
Evite que los textos de razonamiento largos se repitan continuamente
En entorno de producción: guarde un resumen breve, no el razonamiento completo
P3—Mejorar el diseño del almacenamiento en caché de prompts
El objetivo no es maximizar cacheRead. El objetivo es usar cache en prefijos compactos, estables y de alto valor.
Sugerencia:
- Coloque las reglas estables en el prompt del sistema
- No pongas datos inestables en el prefijo estable
- Evite inyectar grandes cantidades de datos de depuración en cada ronda.
Plan de止损 práctico (si yo lo tuviera que manejar mañana)
1. Identificar la sesión con el mayor porcentaje de cacheRead
2. Ejecute /compact en la sesión runaway
3. Agregar truncamiento + artificación a la salida de la herramienta
4. Vuelva a ejecutar el recuento de tokens después de cada modificación
Seguimiento clave de cuatro KPI:
cacheRead / totalTokens
herramientaUso avgTotal/call
Más de 100k llamadas de tokens
Máximo porcentaje de sesión
Señal de éxito
Si la optimización tiene efecto, deberías ver:
Las llamadas de tokens de más de 100k han disminuido notablemente
Disminución del porcentaje de cacheRead
Disminución del peso de la llamada toolUse
La dominancia de una sola sesión se reduce
Si estos indicadores no han cambiado, significa que tu estrategia de contexto sigue siendo demasiado laxa.
Comandos para reproducir el experimento
python3 scripts/session_token_breakdown.py 'sessions' \
--include-deleted \
--top 20 \
--umbral-de-outlier 120000 \
--json-out tmp/session_token_stats_v2.json \
> tmp/session_token_stats_v2.txt
python3 scripts/session_duplicate_waste_analysis.py 'sessions' \
--include-deleted \
--top 20 \
--png-out tmp/session_duplicate_waste.png \
--json-out tmp/session_duplicate_waste.json \
> tmp/session_duplicate_waste.txt
Conclusión
Si tu sistema Agent parece estar funcionando correctamente pero los costos siguen aumentando, primero verifica este problema: ¿estás pagando por inferencias nuevas o estás reproduciendo en gran escala contextos antiguos?
En mi caso, la mayor parte del costo proviene realmente de la repetición del contexto.
Una vez que te des cuenta de esto, la solución será clara: controla estrictamente los datos que ingresan al contexto prolongado.