OpenClaw quema 21,5 millones de tokens en un día? Tres estrategias de optimización para reducir los costos de forma drástica

Título: Por qué mis sesiones de OpenClaw consumieron 21.5 millones de tokens en un día (y qué lo solucionó realmente)

Autor: MOSHIII

Compilación: Peggy, BlockBeats

Nota del editor: En la rápida popularización de la aplicación Agent, muchos equipos han observado un fenómeno aparentemente contradictorio: el sistema funciona perfectamente, pero el costo en tokens continúa aumentando sin que se note. Este artículo, mediante el análisis de una carga de trabajo real de OpenClaw, revela que la causa del estallido de costos no suele ser la entrada del usuario ni la salida del modelo, sino la reproducción en caché del prefijo de contexto (cached prefix replay) que se ha ignorado. El modelo lee repetidamente un enorme contexto histórico en cada llamada, lo que genera un consumo masivo de tokens.

El artículo combina datos específicos de sesiones para mostrar cómo productos intermedios grandes, como salidas de herramientas, instantáneas del navegador y registros JSON, son continuamente escritos en el contexto histórico y leídos repetidamente en el ciclo del agente.

A través de este caso, el autor propone una estrategia clara de optimización: desde el diseño de la estructura del contexto, la gestión de las salidas de herramientas, hasta la configuración del mecanismo de compactación. Para los desarrolladores que están construyendo sistemas de agentes, esto no solo es un registro técnico de diagnóstico, sino también una estrategia concreta para ahorrar dinero.

A continuación, el texto original:

Analicé una carga de trabajo real de OpenClaw y descubrí un patrón que creo que muchos usuarios de Agent reconocerán:

El uso de tokens parece muy “activo”

Las respuestas también parecen normales

Pero el consumo de tokens de repente se dispara de forma explosiva

A continuación, se presenta la descomposición estructural, la causa raíz y la ruta de reparación factible basada en este análisis.

TL;DR

El principal factor que impulsa el costo no es que los mensajes del usuario sean demasiado largos. Es que una cantidad enorme de prefijos en caché (cached prefix) se reproduce repetidamente.

Según los datos de la sesión:

Tokens totales: 21,543,714

Lecturas de caché (cacheRead): 17,105,970 (79.40%)

Entrada (input): 4,345,264 (20.17%)

Salida (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 un contexto histórico enorme.

¿Espera, cómo puede ser así? Momento de duda

Pensaba que el alto uso de tokens provenía de: prompts de usuario muy largos, muchas salidas generadas o llamadas costosas a herramientas.

Pero el patrón dominante en realidad es:

input: de cientos a miles de tokens

cacheRead: entre 170,000 y 180,000 tokens por llamada

Es decir, en cada ciclo, el modelo lee repetidamente el mismo prefijo estable y enorme.

Rango de datos

Analicé datos en dos niveles:

1. Registros en tiempo de ejecución (runtime logs)

2. Transcripciones de sesiones (session transcripts)

Cabe aclarar que:

Los registros en tiempo de ejecución se usan principalmente para observar señales de comportamiento (como reinicios, errores, problemas de configuración)

La estadística precisa de tokens proviene del campo usage en los archivos JSONL de las sesiones

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

¿Dónde se consumen realmente los tokens?

1) Concentración en la sesión

Hay una sesión cuyo consumo es mucho mayor que las demás:

570587c3-dc42-47e4-9dd4-985c2a50af86: 19,204,645 tokens

Luego, una caída abrupta:

ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1,505,038

ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649,584

2) Concentración en comportamiento

La mayor parte de los tokens proviene de:

toolUse: 16,372,294

stop: 5,171,420

Esto indica que el problema principal radica en la cadena de llamadas a herramientas en ciclo, no en conversaciones normales.

3) Concentración en tiempo

El pico de tokens no es aleatorio, sino que se concentra en algunos períodos de horas:

08-03-2026 16:00: 4,105,105

08-03-2026 09:00: 4,036,070

08-03-2026 07:00: 2,793,648

¿Qué hay en el enorme prefijo en caché?

No se trata del contenido del diálogo, sino principalmente de productos intermedios grandes:

Bloques de datos toolResult enormes

Trazas largas de razonamiento / pensamiento

Instantáneas JSON de gran tamaño

Listas de archivos

Datos capturados del navegador

Registros de diálogo de agentes secundarios

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 estos contenidos se mantienen en el contexto histórico, cada llamada posterior puede volver a leer estos datos mediante el prefijo en caché.

Ejemplo específico (de un archivo de sesión)

En las siguientes ubicaciones, aparecen repetidamente bloques de contexto de gran tamaño:

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70

Registro JSON de puerta de enlace grande (aprox. 37,000 caracteres)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134

Instantánea del navegador + encapsulación segura (aprox. 29,000 caracteres)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219

Salida de lista de archivos enorme (aprox. 41,000 caracteres)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311

Instantánea de estado de sesión + estructura de prompt grande (aprox. 30,000 caracteres)

“Desperdicio por contenido repetido” vs “Carga de reproducción en caché”

También medí la proporción de contenido repetido dentro de una sola llamada:

Proporción de repetición: aproximadamente 1.72%

Existe, pero no es el problema principal.

El problema real es: el volumen absoluto del prefijo en caché es demasiado grande

La estructura consiste en: un contexto histórico enorme, que se vuelve a leer en cada ciclo, y solo se añaden unos pocos datos nuevos encima.

Por lo tanto, el enfoque de optimización no es eliminar duplicados, sino diseñar mejor la estructura del contexto.

¿Por qué el ciclo de Agent es especialmente propenso a este problema?

Tres mecanismos se superponen:

1. Gran cantidad de salidas de herramientas que se escriben en el contexto histórico

2. El ciclo de herramientas genera muchas llamadas cortas en intervalos cortos

3. El prefijo cambia muy poco → cada vez se vuelve a leer en caché

Si la compactación del contexto no se activa de forma estable, el problema se amplifica rápidamente.

Estrategias de reparación más importantes (por orden de impacto)

P0—No incluir salidas de herramientas enormes en el contexto a largo plazo

Para salidas de herramientas extremadamente grandes:

• Mantener un resumen + ruta de referencia / ID

• El payload original se guarda en un archivo artifact

• No mantener el texto completo en el historial de chat

Priorizar la limitación de estas categorías:

• JSON grande

• Listas largas de directorios

• Instantáneas completas del navegador

• Transcripciones completas de agentes secundarios

P1—Asegurar que el mecanismo de compactación funcione realmente

En estos datos, varias veces se detectaron problemas de compatibilidad en la configuración: claves de compactación inválidas

Esto puede desactivar silenciosamente la optimización.

La forma correcta: usar solo configuraciones compatibles con versiones

Luego, verificar con:

openclaw doctor --fix

Y revisar los logs de inicio para confirmar que la compactación fue aceptada.

P1—Reducir la persistencia de textos de razonamiento

Evitar que textos largos de razonamiento se reproduzcan repetidamente

En producción: guardar resúmenes breves, no el razonamiento completo

P3—Mejorar el diseño de caché de prompts

El objetivo no es maximizar cacheRead. El objetivo es usar cache en prefijos compactos, estables y de alto valor.

Recomendaciones:

• Incluir reglas estables en el prompt del sistema

• No incluir datos inestables en el prefijo estable

• Evitar inyectar grandes cantidades de datos de depuración en cada ciclo

Plan de acción (si fuera a resolver esto mañana)

1. Identificar la sesión con mayor proporción de cacheRead

2. Ejecutar /compact en sesiones descontroladas

3. Truncar y artifactizar las salidas de herramientas

4. Repetir el análisis de tokens tras cada modificación

Cuatro KPIs clave a seguir:

cacheRead / totalTokens

Promedio de toolUse por llamada

Número de llamadas con más de 100,000 tokens

Proporción de la sesión más grande

Señales de éxito

Si las optimizaciones funcionan, deberías notar:

Reducción significativa en llamadas de más de 100,000 tokens

Disminución en la proporción de cacheRead

Reducción en el peso de toolUse

Menor dominio de sesiones individuales

Si estos indicadores no cambian, significa que tu estrategia de contexto aún es demasiado permisiva.

Comando para reproducir el experimento

python3 scripts/session_token_breakdown.py ‘sessions’
–include-deleted
–top 20
–outlier-threshold 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 bien, pero los costos siguen aumentando, primero verifica una cosa: ¿estás pagando por nuevas inferencias o por la reproducción masiva del contexto antiguo?

En mi caso, la mayor parte del costo proviene en realidad de la reproducción del contexto.

Una vez que te das cuenta de esto, la solución es clara: controlar estrictamente los datos que entran en el contexto a largo plazo.