La Ilusión del Token

Hay un patrón que no deja de aparecer en las sesiones de agentes en producción: le das a un asistente de IA una tarea pequeña, hace un buen trabajo, y luego miras el conteo de tokens y te mareas un poco.

Un desarrollador recientemente instrumentó una sesión donde un agente cerró un issue de GitHub. Leyó el issue, editó un archivo, corrió tests, hizo commit del cambio, abrió un pull request. Trabajo limpio, completo, útil.

¿El output? Cerca de 10,300 tokens de razonamiento y generación real.

¿El contexto total procesado? Aproximadamente 1.55 millones de tokens.

Deja que eso permee. Eso es una ratio trabajo-sobrecosto de aproximadamente 1:150. El agente no estaba pensando con 1.5 millones de tokens. Los arrastraba como muebles en una mudanza que no podía desempacar.

Si estás usando agentes de código en tu flujo de trabajo — ya sea para desarrollo de startups, automatización DevOps, o simplemente para acelerar code reviews — esta ratio está royendo tu presupuesto en silencio, inflando tu latencia, y aumentando el riesgo de context rot (donde el modelo empieza a perder el hilo porque la ventana de conversación está muy saturada para parsear de forma limpia).

Así que vamos a desmontar dónde van realmente esos tokens.

Anatomía de una Sesión Inflada

Después de revisar datos de sesiones a lo largo de varios runs de agentes, el patrón queda claro. La mayor parte del consumo de tokens no viene del razonamiento del modelo. Viene del context scaffolding — la infraestructura que el agente necesita simplemente para operar.

La explosión del catálogo de herramientas. Este es el grande, y tiende a sorprenderte. Cuantos más servidores MCP (Model Context Protocol) conectes, más definiciones de herramientas se inyectan en la ventana de contexto. En una sesión, nueve servidores MCP estaban conectados, exponiendo aproximadamente 260 herramientas. Cuando dos de ellos se attachearon a mitad de sesión, un servidor solo listó alrededor de 180 nombres de herramientas. Esto pasa una vez por conexión, pero nunca sale del historial de conversación. Solo se queda ahí, acumulándose, añadiendo peso a cada turno posterior.

El impuesto del catálogo de skills. A diferencia de los dumps de herramientas, que son un costo de una sola vez, el catálogo de skills es un gasto por turno. Docenas de skills, cada una con descripciones de múltiples oraciones, cargadas en cada interacción. Esto no dispara el conteo de tokens drásticamente — solo eleva el piso. Sesión tras sesión, infla silenciosamente tu baseline.

El overhead del system prompt e infraestructura. Antes de que tu agente haga nada, ya estás por encima de 100k tokens en muchos setups. El system prompt, políticas de seguridad, esquemas de herramientas, e instrucciones de formateo se cargan cada turno. Son necesarios, pero no son el trabajo.

La tarea real. Aquí viene la parte incómoda: el texto del issue, los edits de archivos, el output de tests, el mensaje de commit — todo combinado podría ser unos pocos miles de tokens. La tarea es diminuta al lado del taller.

Por Qué Esto Importa Más de Lo Que Crees

Podrías estar tentado a restarle importancia. "¿Tokens baratos, no?"

Lo son — hasta que estás corriendo veinte sesiones de agentes al día, cada una inflada por factores que no sabías que podías controlar. Las matemáticas se composan rápido. Y no es solo cuestión de costo.

Alto volumen de contexto significa mayor latencia. El modelo tiene que procesar más en cada turno, ralentizando los tiempos de respuesta justo cuando necesitas velocidad.

Más críticamente, el context rot se convierte en un problema real. Cuando el contexto de trabajo de tu agente está empaquetado con definiciones de herramientas, descripciones de skills, e historial de conversación que no necesita para la tarea inmediata, empieza a perder señal-ruido. Puede olvidar contexto relevante de antes en la sesión, malinterpretar lo que le pides, o tomar decisiones basadas en información obsoleta enterrada profundamente en la ventana de conversación.

Para startups que se mueven rápido, eso no es un inconveniente menor — es un problema de confiabilidad.

Cómo Medir Realmente Lo Que Estás Gastando

El instinto es adivinar. "Quizás esta sesión es grande porque la tarea es compleja." Usualmente no lo es. Usualmente es la infraestructura.

Tres enfoques que realmente funcionan:

1. Lee el bloque de usage en tu respuesta final de API. Cada respuesta de tu modelo lleva estadísticas de uso: output tokens (lo que el modelo generó), input tokens (lo que enviaste), y cache_read_input_tokens (lo que se sacó del historial de conversación). Esa cifra de cache_read es tu smoking gun. Si lee 1.5 millones de tokens y tu output fue 10k, tienes una imagen clara de la ratio de overhead.

2. Revisa el estado del contexto de tu sesión a mitad del run. La mayoría de frameworks de agentes modernos tienen un comando como /context que muestra exactamente qué está ocupando tu ventana en este momento, categorizado. Así es como detectas los costos por turno — el catálogo de skills y los esquemas — que un bloque de usage del turno final no puede separar limpiamente de la tarea real.

3. Audita tus conexiones de herramientas antes de agregar más. Antes de conectar otro servidor MCP o añadir otra capability a tu agente, pregúntate: ¿cuánto me va a costar esto por turno? Una definición de herramienta individual podría estar bien. Cien definiciones de herramientas a través de docenas de servidores es un asesino silencioso del presupuesto.

Formas Prácticas de Reducir la Ratio

Ahora la parte útil. Si has identificado que tus sesiones de agentes son token-heavy, aquí es donde empezar a podar.

Optimiza tus conexiones de herramientas. Audita cada servidor MCP y pregúntate si está justificando su peso. Si un servidor expone 50 herramientas y tu agente usó 3, hay una desconexión. Considera si necesitas todas esas herramientas conectadas todo el tiempo, o si podrías scopearlas por fase de tarea.

Usa contextos enfocados en lugar de globales. En lugar de cargar tu catálogo completo de herramientas y biblioteca de skills en cada sesión, considera configuraciones específicas por tarea. Un agente ayudando con code review no necesita el mismo contexto que uno escribiendo código de infraestructura.

Monitorea por sesión, no solo por mes. Revisar costos agregados oculta los outliers. Mira los conteos de tokens de sesiones individuales y empiezas a ver patrones — qué tareas disparan el consumo, qué conexiones inflan, qué skills nunca se usan pero siempre se cargan.

Considera modelos y frameworks construidos para eficiencia. Algunos frameworks de agentes son más token-efficient por diseño. Vibe Hosting, por ejemplo, ofrece un entorno de desarrollo asistido por IA construido con esto en mente — dándote el poder de workflows agentic sin el overhead oculto que se come tus márgenes.

La Línea de Fondo

La próxima vez que corras un agente de código y sientas que la ratio inteligencia-costo está desbalanceada, probablemente tengas razón. Los tokens no están yendo donde crees. La mayoría están cargando el taller — las herramientas, skills, esquemas, y andamiaje de conversación — no haciendo el trabajo real.

Mide primero. El bloque de usage y los comandos de contexto no mienten. Una vez puedas ver a dónde van los tokens, puedes tomar decisiones informadas sobre qué podar. En la mayoría de los casos, encontrarás espacio significativo para optimización sin sacrificar capacidad.

Tu agente no necesita cargar todo el taller. Solo necesita las herramientas correctas para el trabajo. Asegúrate de darle exactamente eso.