Token Burn Rate

1. Visión general del concepto y problema sistémico

En los chatbots convencionales, el consumo de tokens es insignificante: una pregunta y respuesta consumen unos pocos cientos de tokens. Sin embargo, en el vibecoding y los ciclos de agentes autónomos (Cursor Composer, Claude Code, OpenHands), la dinámica del consumo de tokens cambia radicalmente. El agente carga en el contexto las reglas del proyecto, fragmentos de la base de código a través de un índice, esquemas de herramientas y registros de terminal, enviando entre 50,000 y 150,000 tokens en cada iteración.

Si el agente realiza 25 pasos para corregir un error, el volumen total de tokens de entrada fácilmente alcanza varios millones. Si el ingeniero no comprende la métrica Token Burn Rate, el proyecto rápidamente enfrenta un shock financiero: cientos de dólares por día de trabajo en una estación de trabajo o el bloqueo de los límites de la clave API corporativa a mitad de la jornada laboral.

2. Taxonomía arquitectónica y modelo mental

La estructura de costos de tokens en los sistemas de agentes modernos se divide en cuatro categorías desiguales:

┌─────────────────────────────────────────────────────────────┐
│                 TOKEN BURN RATE COST BREAKDOWN              │
├─────────────────────────────────────────────────────────────┤
│ 1. Cached Input Tokens (Prompt Caching Hit) ➔ -90% costo    │
│    Reglas estáticas del repositorio, archivos base, prompt   │
├─────────────────────────────────────────────────────────────┤
│ 2. Fresh Input Tokens (Uncached Cache Miss) ➔ 100% costo    │
│    Archivos nuevos, registros de terminal, mensajes frescos    │
├─────────────────────────────────────────────────────────────┤
│ 3. Generation Tokens (Output / Code Blocks) ➔ 3-5x tarifa    │
│    Código generado, llamadas a herramientas en formato JSON    │
├─────────────────────────────────────────────────────────────┤
│ 4. Thinking / Reasoning Tokens (Extended CoT) ➔ Premium      │
│    Razonamientos internos ocultos de los modelos Claude 3.7 / o1│
└─────────────────────────────────────────────────────────────┘

1. Consumo de entrada básico (Context Ingestion):
   • Volumen de contexto que el modelo revisa en cada paso. Cuanto más largo es el diálogo, mayor es el peso de cada solicitud subsiguiente.
2. Contexto en caché (Cached Prefix):
   • Tokens almacenados en el KV Cache del proveedor de GPU. Tienen un costo reducido (por ejemplo, $0.30 por 1M en lugar de $3.00 en Claude Sonnet), si el prefijo de la solicitud no cambia durante varios minutos.
3. Tokens de salida generativa (Output Tokens):
   • Código que devuelve el modelo. Se cobra significativamente más que los tokens de entrada (de 3 a 5 veces), ya que requiere un cálculo autorregresivo secuencial en GPU.
4. Tokens de pensamiento extendido (Thinking Tokens):
   • Cadenas de razonamiento internas de modelos de nueva generación. Una tarea compleja puede generar 10,000 tokens de pensamientos antes de que el modelo escriba la primera línea de código.

3. Pipeline técnico y mecánica interna

Ciclo de vida de monitoreo y control del Token Burn Rate:

1. Pre-cálculo de tokens (Token Counting): Un tokenizador local (por ejemplo, tiktoken o la biblioteca de tokenización del proveedor) calcula la longitud del prompt generado antes de enviarlo.
2. Verificación de límites (Circuit Breaker & Guardrails): El sistema compara los gastos actuales con el presupuesto establecido: si la sesión actual supera el umbral de $5.00, se envía una alerta al ingeniero.
3. Optimización de la estructura del prompt para preservar el cache: La arquitectura de la solicitud se organiza de tal manera que los datos estáticos (reglas, manifiestos de herramientas) vayan al principio, y los dinámicos (salida fresca de la terminal) al final. Esto evita la invalidación del cache del proveedor.
4. Obtención de telemetría post-respuesta: Se leen de los encabezados de respuesta de la API las métricas exactas: prompt_tokens, completion_tokens, cache_read_input_tokens, cache_creation_input_tokens.
5. Cálculo de la tasa actual de quema: Se calcula la tasa de gastos ($/minuto o $/tarea) y se muestra en la barra de estado del IDE o terminal.

4. Escenarios prácticos de ingeniería en producción

01. Estructuración arquitectónica de prompts para preservar un 90% de descuento en el cache

El ingeniero configura el trabajo con Claude 3.7 Sonnet:

• Si se coloca un timestamp dinámico o registros cambiantes al principio del prompt del sistema, todo el contexto de 100k se considerará nuevo, quemando $0.30 en cada paso.
• Al mover las variables cambiantes al último bloque de la solicitud, el ingeniero asegura un 95% de aciertos en el cache (Cache Hit), reduciendo el costo de un ciclo de 20 pasos de $6.00 a $0.80.

02. Gateway corporativo de control de presupuestos para desarrolladores

El CTO de la empresa implementa un servidor proxy (LiteLLM / Portkey):

• Cada ingeniero recibe un límite diario personal de $15.
• Al alcanzar el 80% del límite, el desarrollador recibe una notificación en Slack.
• Al llegar al 100%, la herramienta cambia automáticamente las tareas no críticas a modelos de bajo costo (DeepSeek V3 o Claude Haiku).

03. Detección de ciclo infinito (Infinite Loop Detection)

Un agente autónomo quedó atrapado en un intento cíclico de instalar una biblioteca incompatible:

• El detector de Token Burn Rate nota que en los últimos 3 minutos se enviaron 8 solicitudes sin cambios en el código resultante, quemando 1.2M de tokens.
• El proceso se interrumpe de emergencia, ahorrando fondos a la empresa.

5. Errores comunes, trampas y seguridad

• Invalidación accidental del cache de prefijos: Agregar UUID aleatorios o la hora actual al principio de la conversación destruye todo el KV Cache, aumentando la factura financiera por 10 veces.
• Sobrecarga invisible del presupuesto de pensamiento (Thinking Budget Overflow): Si no se limita el parámetro max_thinking_tokens, el modelo puede razonar durante 30,000 tokens sobre un cambio trivial en el nombre de un botón, quemando fondos sin valor agregado.
• Sesiones en segundo plano dejadas en el terminal: Ejecutar múltiples agentes CLI en diferentes pestañas de terminal sin monitoreo puede llevar a un agotamiento inadvertido del saldo corporativo si uno de los procesos se queda atascado.
• Configuración incorrecta de notificaciones del proveedor: La falta de límites estrictos (Hard Limits) configurados en los paneles de Anthropic o OpenAI crea el riesgo de deducciones inesperadas de miles de dólares de la tarjeta bancaria vinculada.