Imagina esta escena: abres un asistente de programación con IA y escribes «vale» para que lo confirme. Solo esas cuatro letras. Y antes de que la IA «lea» siquiera esa palabra, ya ha consumido en segundo plano una cuota de cómputo de unos 33.000 tokens. Otra herramienta de funcionalidad casi idéntica, en el mismo escenario, gastó apenas unos 7.000.
No es una metáfora ni una estimación. Es la conclusión medida por el equipo de Systima tras colocar una capa de proxy de registro sobre la API de Anthropic y anotar, petición por petición, los datos en bruto de cada solicitud. Publicaron en su blog la metodología completa del experimento junto con las cifras originales, y el artículo acumuló luego más de 400 votos y más de 200 comentarios en Hacker News.
Quiero explicar, en términos que cualquiera pueda entender, las tres cosas que hay detrás de esa cifra: ¿qué hace realmente una herramienta de programación con IA «antes de ver lo que escribes»? ¿Por qué los subagentes son auténticos agujeros negros de tokens? Y ¿qué papel juega en todo esto el modelo de negocio de pago por uso?
¿Qué es un token? ¿Por qué se quema tan rápido, como si fuera gasolina?
Antes de entrar en cifras concretas, conviene aclarar un concepto clave. Un token puede entenderse como la unidad mínima de medida con la que la IA procesa el texto: no es «una palabra», sino aproximadamente 0,75 palabras en inglés, o entre 1 y 2 caracteres en chino. Cuando usas un servicio de IA de pago por uso, cada token procesado genera un cargo en tu factura.
Las herramientas de programación con IA no funcionan como una conversación normal con IA. Cuando charlas con Claude en la versión web, lo que recibe es básicamente tu pregunta. Pero una herramienta de programación con IA necesita, además de tu pregunta, inyectar una enorme cantidad de «trabajo preparatorio»: decirle a la IA quién es, qué herramientas puede invocar, qué reglas tiene tu proyecto, cuál es el directorio de trabajo actual, qué información de entorno tiene el sistema operativo, etc.
A todo ese contenido adicional se le llama «andamiaje» (harness overhead). El problema es que el tamaño del andamiaje varía enormemente.
33.000 frente a 7.000: la factura de responder «OK»
El diseño del experimento de Systima es directo: hicieron que dos herramientas de programación con IA —Claude Code, el producto oficial de Anthropic, y OpenCode, de código abierto— ejecutaran por separado la misma tarea, la más sencilla posible: responder «OK».
Antes de leer esas dos letras, Claude Code envió a la API unos 33.000 tokens. Su composición era esta: unos 6.500 tokens del prompt del sistema (que le dice a la IA «quién eres y cómo debes actuar»), unos 24.000 tokens de las definiciones de 27 herramientas (leer archivos, escribir archivos, ejecutar comandos, gestionar subagentes, tareas programadas…), y unos 2.000 tokens de bloques de recordatorio inyectados (estado de la tarea, lista de habilidades disponibles, información del entorno actual).
OpenCode usó solo unos 7.000 tokens: unos 2.000 del prompt del sistema y unos 4.800 de las definiciones de 10 herramientas. No tiene bloques de recordatorio adicionales; su estructura es muy austera.
Aquí hay un detalle fácil de pasar por alto: esos 33.000 tokens no se «gastan una sola vez». En el modo de trabajo de las herramientas de programación con IA, cada ronda de conversación —cada ida y vuelta con el modelo— vuelve a enviar todo ese andamiaje. Es decir, si tu tarea requiere 10 rondas de comunicación con la IA, solo el andamiaje consume 330.000 tokens, sin contar tu código ni tu conversación reales.
El caché debería ahorrar dinero, pero Claude Code lo estropea
Los proveedores de servicios de IA suelen ofrecer un mecanismo llamado «caché de prompts»: si la mayor parte del contenido no cambia entre peticiones consecutivas, se puede leer del caché a un precio muy bajo en lugar de recalcularlo. Es una herramienta clave para controlar costes.
Pero Systima descubrió una diferencia crucial: el prefijo de las peticiones de OpenCode es idéntico byte a byte cada vez, lo que significa que solo necesita escribir el caché una vez y, a partir de ahí, cada lectura se factura a una décima parte del precio. Claude Code, en cambio, reescribe repetidamente decenas de miles de tokens de caché a lo largo de las peticiones consecutivas de una misma tarea: escribe en caché 54 veces más que OpenCode en la misma tarea.
Escribir en el caché es mucho más caro que leer de él. Dicho de otro modo: buena parte del motivo por el que los usuarios ven crecer la cifra de su factura es que la herramienta no aprovecha el caché de forma eficiente.
La factura real en producción: de 33K a 85K
Esos 33.000 son todavía el estado «desnudo»: sin configuración de proyecto, sin plugins, sin herramientas adicionales. ¿Cómo es un entorno de producción real?
Systima hizo un «experimento de acumulación». Primero probaron en un proyecto vacío y luego fueron añadiendo poco a poco la configuración de un escenario de desarrollo real:
Primer paso: introducir un archivo de instrucciones de proyecto de 72 KB (AGENTS.md o CLAUDE.md, que sirve para indicarle a la IA tus convenciones de código). Solo este paso añadió unos 20.000 tokens a cada petición.
Segundo paso: conectar 5 servidores MCP ligeros (que permiten a la IA leer y escribir correos, gestionar tareas, consultar bases de datos, etc.). Se sumaron otros 5.000 a 7.000 tokens.
En conjunto, en un entorno de desarrollo real, Claude Code ya había consumido entre 75.000 y 85.000 tokens antes de leer la pregunta del usuario. OpenCode también se infla con una acumulación similar, pero como su punto de partida es bajo, el valor absoluto sigue siendo manejable.
Subagentes: el auténtico agujero negro de tokens
Si el consumo del andamiaje es «un consumo de combustible elevado», el subagente es «el depósito de gasolina agujereado».
Los subagentes son una función importante de Claude Code: cuando una tarea es compleja, el agente principal puede desplegar varios «clones» que trabajan en paralelo, y cada subagente lee código, analiza problemas y devuelve resultados de forma independiente. Suena eficiente, pero el coste es asombroso.
Systima comparó la misma tarea: la ejecución directa consumió 121.000 tokens; al usar dos subagentes en paralelo, el consumo se disparó a 513.000 tokens, 4,2 veces más.
¿Por qué tanta diferencia? Porque cada subagente es una unidad de trabajo independiente. Tiene su propio prompt del sistema (aunque más austero que el del agente principal), su propio conjunto de herramientas y necesita volver a leer los archivos del proyecto para entender el contexto. Y cuando un subagente termina su tarea, todo su registro de conversación es «tragado» por el agente principal como referencia. Es como enviar a dos personas a buscar información y que, al volver, cada una traiga no solo la respuesta, sino una caja entera con todos los documentos originales que revisaron.
La experiencia de un usuario en HN es aún más extrema. Escribió: «I gave Claude Code a fairly large task and it immediately spun up 7 subagents, and none of them finished the task before my budget was burned. Tried again 5 hours later, same result.» Y esa misma tarea, ejecutada de forma secuencial con el agente principal, no dio ningún problema.
El dilema del modelo de negocio de Anthropic
Llegados aquí, surge una duda natural: ¿es un defecto de diseño o consecuencia del modelo de negocio?
La API de Anthropic se factura por token. Como Claude Code es una herramienta oficial, cuanto mayor sea su consumo de tokens, mayores serán los ingresos de Anthropic. Pero eso no significa que sea necesariamente «un diseño intencionado»: más bien es un incentivo estructural. Cuando tus ingresos dependen de cuántos tokens consuman los usuarios, no tienes un incentivo tan fuerte como el de la comunidad de código abierto para aligerar el andamiaje.
OpenCode logra ese «suelo» de 7.000 tokens en gran parte porque es un proyecto de código abierto: entre sus objetivos de diseño no está maximizar los ingresos de la API. Las 27 herramientas de Claude Code, sus múltiples capas de recordatorios y el mecanismo completo de arranque de subagentes tienen, cada uno, una justificación legítima de «más funcionalidad». Pero cuando toda esa «mayor funcionalidad» se acumula, la factura del usuario se convierte en un subproducto.
Pero Claude Code también gana algunas veces
Siendo justos, la prueba de Systima también reveló un escenario favorable a Claude Code.
En una tarea que requería varios pasos (escribir código, ejecutar pruebas, corregir según los errores y volver a probar), el consumo total de Claude Code resultó incluso menor que el de OpenCode. La razón es que Claude Code agrupa varias llamadas a herramientas dentro de una sola petición, mientras que OpenCode gasta una ronda de petición por cada llamada. Aunque el andamiaje de cada petición de Claude Code es más pesado, OpenCode, al no poder agrupar, pagó 9 veces la sobrecarga del andamiaje y acabó con una factura total mayor.
Este hallazgo revela un hecho sutil: la eficiencia en tokens de una herramienta no depende solo de lo ligero que sea su andamiaje, sino también de cómo organiza el flujo de trabajo. Andamiaje pesado pero con capacidad de agrupar, o andamiaje ligero pero que hay que repetir una y otra vez: cuál es mejor depende de la tarea concreta.
¿Qué significa esto para el usuario común?
Si no programas, quizá pienses que es «un problema de programadores». En realidad, a medida que las herramientas de IA pasan de «charlar» a «trabajar», este modelo de facturación por uso afectará a cada usuario.
Cuando cambias una línea de código en Cursor, o le pides a la IA en Claude Code que te arregle un bug, detrás de cada operación ocurre una historia parecida: se reenvían en masa grandes cantidades de instrucciones del sistema, los subagentes nacen y mueren en segundo plano, el caché se reescribe una y otra vez, y la factura se va acumulando en silencio entre todas esas acciones invisibles.
El experimento de Systima ha sacado a la luz cifras que antes permanecían ocultas en una caja negra. Como usuario, conocer la existencia de estas cifras es, en sí mismo, una forma de empoderamiento informativo.
O, dicho más claro: la próxima vez que veas la factura de la API, sabrás que, de todos esos números, probablemente solo una pequeña parte corresponde a lo que de verdad usaste.
Enlaces de referencia:
- Systima: Claude Code vs OpenCode Token Overhead
- Discusión en HN (item?id=48883275)