Consumo de tokens de Claude Code: adónde va y cómo recortar un 62 %

Una sola pasada para contrastar la documentación con el código lanzó 85 agentes y habría costado unos $26 a precio de API. Los 85 corrieron en el modelo más caro, aunque nadie lo eligió: el script no indicaba modelo y los agentes heredaron el de la sesión. Revisé los registros de esa pasada y de otras tres para entender adónde va el consumo de tokens de Claude Code en un workflow. Las respuestas del modelo casi no cuestan nada. El dinero se va en que cada agente relee su contexto una y otra vez.

Este es el segundo artículo sobre workflows. Qué es este modo, cómo se lanza y qué límites tiene lo conté en el primer artículo sobre Claude Code workflows. Aquí solo hay cifras y lo que cambié en mis scripts después de medir.

Lo esencial:

1. Las respuestas del modelo son alrededor del 2 % del coste de la pasada. Entre el 65 y el 84 % se va en escribir contexto en la caché.
2. La fase más cara es la recomprobación de hallazgos: del 50 al 78 % de la pasada.
3. El modelo que nadie eligió resultó ser la partida principal. Tras asignar un modelo a cada rol, la revisión de un commit bajó de $3,20 a $1,23.
4. Repetir la pasada sin commits nuevos cuesta menos de un centavo: un agente pequeño compara el estado y termina.
5. Sin un conjunto de tareas de referencia, el ahorro no se puede medir con honestidad. Todavía no lo tengo, y es el principal punto abierto.

Cómo conté#

Cada agente de un workflow tiene su registro: ~/.claude/projects/<proyecto>/<sesión>/subagents/workflows/wf_*/agent-*.jsonl. Cada respuesta del modelo trae el campo message.usage: tokens de entrada, lectura de caché, escritura de caché y salida. Los sumé por fase y los multipliqué por los precios de la API del 6 de noviembre de 2026:

Precios por millón de tokens. Con una suscripción no se cobra la pasada, pero esos mismos tokens gastan los límites del plan, así que las proporciones son las mismas.

Una salvedad. En los registros hay sospechosamente pocos tokens de salida, entre 30 y 100 por solicitud: parece que el razonamiento del modelo no queda registrado. Por eso la parte de la salida es una estimación mínima. La conclusión no cambia: aunque multiplicara la salida por diez, seguiría por debajo del 20 % del coste.

Adónde va el consumo de tokens de Claude Code#

Cuatro pasadas sobre la misma rama, todos los agentes en Opus 5.5:

La mecánica es simple. Un agente arranca con unos 50 mil tokens de contexto: prompt del sistema, herramientas, CLAUDE.md, memoria y la tarea. Solo CLAUDE.md y la memoria suman entre 11 y 13 mil tokens antes de la primera línea de la tarea. Después el agente hace de 5 a 8 solicitudes, y cada una arrastra todo el contexto acumulado con los resultados de las herramientas. El total sale aproximadamente así: agentes × solicitudes por agente × tamaño del contexto × precio del modelo. Cada uno de esos cuatro factores se puede reducir.

La caché no siempre salva. En Opus 5.5 leer de la caché cuesta $0,20 y escribir $5, 25 veces más. En las revisiones, los verificadores leían el prefijo común de la caché de su vecino: la mediana de escritura en la primera solicitud fue cero. En el contraste de documentación, cada uno de los 76 verificadores escribió su prefijo de nuevo, unos 32 mil tokens cada vez. Son unos $12 de los $26 solo para guardar 76 veces lo mismo en la caché.

Por qué ahí la caché no se compartió, no lo averigüé. Según la documentación de workflows, los agentes leen la caché de otros solo si coinciden el modelo, el nivel de esfuerzo, el tipo de agente, las herramientas, el esquema de respuesta y la carpeta de trabajo. La caché de un agente de workflow dura cinco minutos, incluso con suscripción.

Recomprobar: caro y a menudo en vano#

El esquema «un agente encuentra, otro intenta refutar» es lo mejor que tiene el workflow. Pero también es lo que más consume: por cada hallazgo se lanza un verificador aparte con su propio contexto.

En el contraste de documentación, los verificadores refutaron 36 de 76 discrepancias, el 47 %. Casi la mitad del dinero de la fase se fue en descartar discrepancias que no existían. El coste de un hallazgo confirmado salió igual en todas las pasadas: entre $0,9 y $1,2.

De ahí sale una conclusión que al principio parece rara: sale más barato endurecer la búsqueda que tener más verificadores. Si el buscador está obligado a traer la cita literal de la página y la línea de código que leyó, las discrepancias falsas disminuyen incluso antes de la comprobación.

Trabajos externos dicen lo mismo. En el preprint Refute-or-Promote, diez revisores confirmaron por unanimidad una vulnerabilidad de OpenSSL que no existía, y la mató una sola prueba empírica. No hay una comparación controlada, es un único caso. Pero la lección es clara: diez agentes de acuerdo todavía no son un hecho. En CodeX-Verify cada verificador adicional aportaba menos que el anterior: +14,9, luego +13,5 y +11,2 puntos porcentuales de precisión.

Qué cambié en los scripts#

Cinco cambios. Cada uno ataca uno de los factores.

Modelo explícito en cada agente. Según la documentación, un agente sin modelo indicado corre en el modelo de la sesión. Ahora cada script empieza con una tabla, y se puede sobrescribir al lanzarlo:

const M = {
  scope: 'haiku',
  find: A.thorough ? 'opus' : 'sonnet',
  verify: A.thorough ? 'opus' : 'sonnet',
  state: 'haiku',
  ...(A.models || {}),
}

Haiku 5.5 escribe caché a $0,125 frente a los $5 de Opus, 40 veces menos. A Haiku le tocan el reconocimiento (qué archivos cambiaron) y el guardado del estado. La búsqueda y la verificación van en Sonnet. Opus queda para la pasada de lanzamiento y para una excepción: en la auditoría de código de terceros lo mantuve en la lectura de scripts de instalación, porque un hook malicioso que se cuele cuesta más que cualquier cantidad de tokens. A la mecánica y a la comprobación de hallazgos menores les puse effort: 'low'.

Los duplicados se fusionan antes de verificar. Tres revisores suelen encontrar el mismo error desde ángulos distintos. Si el archivo es el mismo y las líneas difieren en tres o menos, el hallazgo se verifica una sola vez. Los hallazgos menores que exceden el límite no se verifican y van a una lista aparte, con registro en el log, para que el recorte no sea silencioso.

El verificador debe traer un hecho. Una llamada, una condición más arriba en la pila, la salida de un comando, una cita literal. Sin hecho, el hallazgo se rechaza:

`Keep a finding only with evidence — what you found and where ` +
`(file:line or command output). No evidence → reject.`

Los tres votos se quedaron solo para los hallazgos graves de la pasada de lanzamiento.

Revisar solo lo nuevo. La revisión guarda el último commit revisado en un archivo dentro de .git (git rev-parse --git-path change-review-state.json), así que no entra en ningún commit. La siguiente ejecución mira lastReviewedSha..HEAD y traslada los hallazgos abiertos de los archivos que no se tocaron. La pasada completa se hace antes de un pull request, tras un rebase y al cambiar los prompts: para eso el script lleva un número de versión de los prompts. Así funcionan las revisiones incrementales de CodeRabbit y la selección de tests afectados en CI.

No eliminé la pasada completa, y hay una razón. El error más serio del día lo encontró justamente ella: unía el cliente, el servicio y los ajustes en tres archivos distintos. Un recorrido incremental archivo por archivo no lo habría visto.

Salida temprana. Si desde la última pasada no cambió nada, tras el reconocimiento el script devuelve el resultado de inmediato y no lanza ningún revisor.

Resultado en el mismo repositorio:

La comparación de calidad no es estricta. El script antiguo miró el commit antes de las correcciones de la revisión y el nuevo después, y los hallazgos difieren: tres confirmados frente a dos. El precio es comparable porque el volumen es el mismo: de 4 a 6 archivos, 10 agentes.

Otro cambio no toca el dinero sino el ciclo «comprobación → corrección». En mi script de traducciones, el agente corrector hacía los últimos cambios y nadie los releía. Ahora, después de la corrección hay una recomprobación corta en Sonnet con effort: 'low'. El ciclo debe terminar en una comprobación; si no, los últimos cambios llegan al commit sin que nadie los lea.

Lo que aún no he comprobado#

• No hay conjunto de referencia. Hacen falta entre 30 y 50 pull requests pasados con errores conocidos y unos cuantos errores introducidos a propósito. Sin eso no puedo decir cuántos hallazgos sutiles se le escapan a Sonnet en comparación con Opus.
• Por qué no se compartió la caché en el contraste de documentación sigue sin estar claro. Son hasta $12 por pasada.
• Entre 11 000 y 13 000 tokens de reglas comunes se siguen cargando en cada agente: un CLAUDE.md de 21 KB más la memoria. La documentación de costes recomienda mantener CLAUDE.md por debajo de 200 líneas y sacar las reglas especiales a skills, que se cargan bajo demanda. Todavía no lo he hecho.
• Todas las estimaciones de ahorro, salvo la medición de la revisión, son cálculo y no medición.

Aparte, sobre el contraste de documentación. Su mayor problema es comprobar cada página entera en cada pasada. El siguiente paso es contrastar solo las páginas vinculadas a los archivos modificados. Cómo vincular una página al código para que ella misma sepa que quedó obsoleta lo describí en el artículo sobre anclas de documentación en el código.

Si ya tienes workflows guardados, empieza por un comando: grep -n "agent(" ~/.claude/workflows/*.js. Cada llamada de su salida cuyas opciones no incluyan model probablemente corre en el modelo de tu sesión.