Microsoft y Berkeley publican TokenEconomizer: los agentes de código salen entre un 18 % y un 31 % más baratos

La factura de los agentes de programación crece más rápido de lo que parece. Una sola ejecución de Claude Code o Codex en una tarea no trivial supone decenas de pasos, y en cada uno el modelo vuelve a leer el contexto acumulado. Por eso, cualquier promesa de reducir costes sin cambiar el modelo atrae la atención de los equipos para los que los tokens ya son una partida independiente del presupuesto.

Esa es justamente la promesa de Microsoft y UC Berkeley: han liberado TokenEconomizer, una herramienta para abaratar los agentes.

Qué se afirma

Según una publicación en X, el equipo probó la herramienta en 277 tareas de SWE-Bench. Se evaluaron cinco combinaciones de agente y modelo. El coste medio de ejecución bajó entre un 18,4 % y un 30,9 % según la combinación. La cifra más alta, 30,9 %, aparece en el titular, pero es el mejor caso, no una garantía para cualquier stack.

La frase clave es «sin tocar el modelo». La optimización funciona desde fuera: no requiere ajuste fino, ni sustituir el modelo por uno más barato, ni acceso a los pesos. Para quienes usan modelos cerrados mediante API, es la única palanca realista: no controlas el precio por token, pero sí, en parte, la cantidad de tokens.

El autor de la publicación escribe que todo el método cabe en un repositorio y tres pasos. Cuáles son esos pasos no se explica en la publicación, que solo enlaza al repositorio. Por eso es más honesto no especular sobre la mecánica, sino leer el código.

Por qué importa en la práctica

En los escenarios con agentes, el coste no se compone de una sola petición, sino de una cadena. El contexto, la salida de las herramientas, los reintentos: todo se paga una y otra vez. Ahorrar un 20–30 % en ese flujo no es algo cosmético. Para un equipo que gasta varios miles de dólares al mes en agentes, la diferencia se nota, y para una startup con un agente de código en el núcleo de su producto puede alterar la economía unitaria.

Hay un segundo aspecto. El trabajo de Microsoft y Berkeley demuestra que la infraestructura que rodea a los agentes aún tiene mucha ineficiencia. Mientras todos discuten qué modelo es mejor, parte del dinero se fuga en la capa de orquestación. Es una señal para los responsables de producto: conviene optimizar no solo la elección del modelo, sino también cómo maneja el agente el contexto.

Qué conviene comprobar

Primero, las métricas. La publicación habla del coste, pero no dice nada del porcentaje de tareas resueltas. Si el ahorro se logra a costa de perder calidad, no hay ganancia. Hay que ver si la tasa de éxito se mantiene en el nivel anterior.

Segundo, la traslación a la realidad. SWE-Bench son tareas cuidadosamente preparadas de repositorios populares de código abierto. Tu monorepositorio privado, con un historial de commits caótico, es distinto, y el 18–31 % puede convertirse allí en un 10 % o, al contrario, en un 35 %.

Tercero, la fuente. La publicación obtuvo pocas visualizaciones y las cifras llegan de segunda mano. Antes de incluir el ahorro en el presupuesto, abre el repositorio y, si existe, el artículo, y revisa las condiciones del experimento: versiones de los agentes, precios y método de cálculo del coste.

Qué hacer

El plan práctico es sencillo. Clona el repositorio, ejecútalo con 20–30 de tus tareas habituales con la herramienta activada y desactivada, y compara el coste y la proporción de soluciones correctas. Si el ahorro se confirma aunque sea en la mitad de lo declarado, la adopción se amortizará en cuestión de días. Si no, perderás un par de horas y obtendrás tus propios datos en lugar de porcentajes ajenos.