Observaciones sobre el consumo de tokens de los agentes de IA

Un artículo nuevo de investigadores de Stanford, Michigan, DeepMind, All Hands, Microsoft AI y el MIT es el estudio empírico abierto más detallado que he visto sobre cómo gastan tokens los agentes de IA a escala¹. Los autores ejecutan ocho modelos de frontera sobre 500 tareas de SWE-bench Verified, con cuatro ejecuciones cada una, y capturan la telemetría completa de cada trayectoria desglosada por tipo de token, fase y acción. Publican el conjunto de datos junto con el artículo, que a mi entender es el corpus público más granular de trayectorias agénticas que existe hoy.

El artículo es riguroso, cuidadoso con lo que afirma y pone cifras duras a preguntas que hasta ahora solo se respondían con anécdotas. Te recomiendo leerlo entero.

Lo que sigue es un repaso de cuatro de sus observaciones, mezclado con lo que vemos en Flowstate, donde los mismos patrones aparecen en los entornos de nuestros clientes. Estamos en la ruta de la petición, entre el usuario y el proveedor de IA. Eso significa que observamos las mismas trayectorias que analiza el artículo, pero en producción y con un abanico de herramientas de IA mucho más amplio que el que cubre SWE-bench.

Los dos conjuntos de observaciones se parecen muchísimo. Los investigadores lo midieron en un benchmark. Nosotros lo vemos en los dispositivos de los clientes. Que coincidan es lo que hace tan útil este artículo para cualquiera que intente gestionar de verdad este gasto.

Los tokens de entrada dominan el gasto agéntico

El primer hallazgo del artículo es que la programación agéntica consume unas 1000 veces más tokens que las tareas equivalentes de chat de código o de razonamiento de código, con una proporción de entrada a salida de aproximadamente 153:1 (frente a 1,33 en el chat y 0,16 en el razonamiento)².

La razón es estructural. Los flujos agénticos acumulan contexto de una ronda a otra, y ese mismo contenido vuelve a entrar en el modelo en cada turno. La caché de tokens ayuda un poco, pero el volumen de contexto acumulado domina el coste.

Es el mismo patrón que vemos en el uso de IA no agéntico. El uso tipo chat de Claude, ChatGPT y herramientas parecidas tiene la misma forma, porque los usuarios siguen las conversaciones durante días en lugar de empezar sesiones nuevas con el contexto explícito. Un cliente nos lo describió así:

“We think they’re creating PowerPoints, and then they’re like, ‘change this word on slide three’, and then they’re just continuing to generate these really large documents.”

(Traducción: “Pensamos que están creando presentaciones de PowerPoint, y luego dicen ‘cambia esta palabra de la diapositiva tres’, y siguen generando esos documentos enormes.”)

Ese es el hallazgo del artículo en versión humana. Una sesión de chat que tendría que haber sido un prompt nuevo se convierte en un hilo que vuelve a pagar todo su historial en cada turno. El usuario cree que hace una edición pequeña. Al modelo le piden que reprocese el documento entero. El proveedor cobra en consecuencia.

La implicación es que una parte enorme del coste de IA que se puede controlar está antes del modelo. Mejores prompts. Sesiones nuevas. Contexto explícito dado una sola vez, en lugar de construido poco a poco durante una tarde. El comportamiento del agente es, en gran medida, consecuencia de cómo se le preparó.

La elección de modelo produce diferencias de coste de un orden de magnitud

En las 230 tareas de SWE-bench que resolvieron con éxito todos los modelos probados, Kimi-K2 y Claude Sonnet 4.5 usaron de media 1,5 millones de tokens más que GPT-5³. Los mismos problemas, las mismas respuestas correctas, apetitos de tokens completamente distintos.

El artículo se cuida de descartar la explicación obvia: la diferencia de coste persiste tanto en el subconjunto de éxitos compartidos como en el de fallos compartidos. Los modelos más caros no se enfrentaban a problemas más difíciles. Simplemente gastaban más tokens en los mismos problemas.

Esto coincide con un comportamiento que vemos de forma constante. Los usuarios usan por defecto el modelo más destacado de la interfaz, y “más destacado” suele significar el más caro. Opus cuando Sonnet habría bastado. Los proveedores no tienen ningún incentivo comercial para empujar a los usuarios hacia modelos más baratos. De otra conversación con un cliente:

“We definitely know that people are using just all Opus. The people that are using up their tokens, they’ll continue to do that unless there’s a way to control it. We did not know there was a way to control that in Claude. I know there isn’t.”

(Traducción: “Sabemos seguro que la gente usa todo el rato Opus. Los que se están acabando sus tokens van a seguir haciéndolo a menos que haya forma de controlarlo. No sabíamos que había una forma de controlarlo en Claude. Yo sé que no la hay.”)

Hay una forma de controlarlo, pero no vive en el producto del proveedor. El lugar natural es la capa que puede ver la categoría de la tarea y enrutar a nivel de petición: lo repetitivo al modelo más ligero, la planificación larga al más pesado. El hallazgo de Stanford de que la eficiencia en tokens es una propiedad del modelo y no de la tarea es justo lo que hace viable el enrutado. Si los modelos pesados solo quemaran más tokens en problemas más difíciles, enrutar no serviría de nada. No es así, y por eso sirve.

El uso de tokens es muy variable y difícil de predecir

La tercera observación del artículo es que cuatro ejecuciones del mismo modelo sobre la misma tarea pueden producir hasta 30x de variación en el coste total de tokens⁴. La ejecución más cara de un problema dado cuesta de media aproximadamente el doble que la más barata. A más coste, menos previsibilidad.

Más al grano todavía: los autores comprueban si los agentes pueden predecir su propio uso de tokens antes de ejecutar una tarea. Encontraron correlaciones de 0,39 en el mejor de los casos. Los ocho modelos subestiman de forma sistemática⁵. Ni el propio agente sabe cuánto va a costar una tarea.

Lo que vemos del lado del cliente es a la dirección intentando gestionar el gasto con el único dato que tiene a mano. Normalmente, un recuento de chats del panel de administración del proveedor:

“What are these five people doing? They’re always saying they don’t have enough tokens.”

(Traducción: “¿Qué están haciendo estas cinco personas? Siempre dicen que no tienen tokens suficientes.”)

Un recuento de chats no responde a eso. Un recuento de tokens responde cuánto se gastó, pero no por qué. El “por qué” es estructuralmente invisible desde la factura. Solo se ve en la capa de petición, donde el trabajo real es observable. Ninguna previsión previa cerrará la brecha, porque el propio trabajo es estocástico.

Más coste no da más precisión

El artículo divide las ejecuciones en cuartiles de coste y encuentra que la precisión alcanza su máximo en el segundo cuartil más barato y se queda plana a partir de ahí. Las ejecuciones más caras no dan mejores resultados que las de precio moderado⁶.

Los autores lo atribuyen a un patrón de comportamiento concreto: en el cuartil de mayor coste, las modificaciones repetidas de archivos son aproximadamente 4 veces más frecuentes que en el cuartil más barato, y las lecturas repetidas de archivos, 2 veces más⁷. Las ejecuciones caras no hacen más trabajo. Hacen el mismo trabajo, otra vez, sobre los mismos archivos.

El artículo lo describe con educación como “exploración improductiva en lugar de razonamiento más profundo”. Vemos la misma forma en el uso de IA que no es de programación. Regenerar una y otra vez el mismo artefacto con cambios marginales. Sesiones larguísimas que el usuario abandonó hace horas. Prompts idénticos reenviados tras corregir una errata. Nada de esto son fallos del agente. Son patrones del usuario que el agente hereda.

La brecha de medición

Ninguno de estos patrones se puede abordar a escala sin medir en la capa de petición. Los paneles de los proveedores agregan por herramienta y por cliente. Los gateways de IA (un proxy que se sitúa entre tú y tu proveedor de IA) cubren el enrutado de producción en el servidor. Las herramientas de eficacia de ingeniería cubren asistentes de código concretos y ahí se quedan.

Construimos Flowstate porque la capa de medición necesaria para actuar sobre estos patrones no existía en ningún punto del stack.

Flowstate observa cada llamada de IA que hace un usuario, sea ChatGPT en el navegador, Claude Code en la terminal, Midjourney para imágenes o Suno para audio, y vincula cada llamada con un usuario, un proyecto, un modelo y una clase de coste⁸. Los clientes conservan sus propios contratos y sus propias claves de API con cada proveedor que usan. Nosotros no vendemos acceso a IA ni restringimos las herramientas a las que la gente puede recurrir.

Esa posición arquitectónica tiene consecuencias más allá de medir el coste. La misma instrumentación que deja al descubierto el derroche de tokens deja al descubierto patrones que importan para la seguridad. Prompts con datos personales de clientes camino de una herramienta de IA de consumo. Código fuente pegado en ChatGPT. Empleados que llevan proyectos personales con la suscripción de la empresa. Los vemos en el campo únicamente porque la capa de petición es el único sitio donde se ven.

El artículo de Stanford plantea un argumento económico limpio desde un benchmark. Nuestras observaciones plantean exactamente el mismo desde entornos corporativos reales. Los patrones que mueven el coste de la IA son grandes, medibles y constantes. Solo hace falta la instalación para verlos.

---

Footnotes

1. Bai, L., Huang, Z., Wang, X., Sun, J., Mihalcea, R., Brynjolfsson, E., Pentland, A., and Pei, J. (2026). How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks. arXiv:2604.22750v2. Los autores reconocen trabajos simultáneos sobre la distribución de tokens en sistemas multiagente (Salim et al. 2026, Wang et al. 2025) y sobre la dinámica de precios en modelos de razonamiento (Chen et al. 2026), pero la combinación de escala, granularidad y publicación abierta de los datos hace de este artículo el más útil que he visto para entender cómo es de verdad el gasto agéntico. Los autores publican también un sitio web del proyecto con el conjunto de datos de trayectorias, un repositorio de código de análisis para replicar las figuras y un juego interactivo, Can You Guess the Token Cost?, que clava el hallazgo principal del artículo en unos treinta segundos. ↩

2. Bai et al., figura 1. La programación agéntica promedia 4,17M de tokens por tarea y 1,86 $ de coste, frente a 3,39k tokens en las tareas de chat de código y 1,19k tokens en el razonamiento de código de un solo turno. La cifra de 1000x es la proporción frente al razonamiento. Frente al chat es de aproximadamente 1200x. ↩

3. Bai et al., figura 6 y sección 4. La sección 4 aborda en concreto la objeción de que “las tareas más difíciles cuestan más de forma natural” y muestra que la diferencia persiste en el subconjunto de éxitos compartidos (n=230 tareas resueltas por todos los modelos probados). Los autores describen la diferencia como “model-specific behaviour rather than intrinsic task difficulty”. ↩

4. Bai et al., figuras 2a y 2b. Hasta 30x de variación entre instancias. En la misma tarea a lo largo de cuatro ejecuciones, la más cara cuesta de media aproximadamente 2x la más barata. ↩

5. Bai et al., figuras 10 y 11. La mejor correlación entre los ocho modelos es 0,39 (Claude Sonnet 4.5, tokens de salida). La predicción de tokens de entrada es siempre peor que la de tokens de salida. Todos los modelos subestiman de forma sistemática. La figura 11 muestra las predicciones agrupadas muy por debajo de la diagonal en todos los casos. ↩

6. Bai et al., figura 3b. La precisión aumenta de forma significativa del cuartil más barato al segundo más barato, y después se estanca. El tercer y el cuarto cuartil no se distinguen estadísticamente del segundo. ↩

7. Bai et al., figura 4 y apéndice A. Coeficientes de regresión de efectos mixtos de aproximadamente 4x para las modificaciones repetidas y 2x para las lecturas repetidas en el cuartil de mayor coste, ambos significativos con p < 0,001 frente al grupo de coste mínimo, controlando por la identidad del modelo. El análisis de tokens de salida del apéndice muestra el mismo patrón. ↩

8. Flowstate. Lo cofundé yo, así que se aplica la obvia declaración de conflicto de intereses. ↩