Introducción: una nueva herramienta para reducir el gasto de los agentes de IA
Un equipo de investigadores de Microsoft Research y UC Berkeley lanzó TokenEconomizer, un controlador de costos de código abierto diseñado para reducir el gasto de los agentes de inteligencia artificial que trabajan con repositorios de software.
La herramienta utiliza información de sesiones anteriores para identificar operaciones repetitivas, reducir las herramientas disponibles cuando resultan innecesarias e intervenir cuando un agente entra en ciclos de errores.
Su principal característica es que funciona como un controlador externo: no modifica los pesos del modelo de IA ni el código del agente.
TokenEconomizer es compatible con Claude Code, Codex, GitHub Copilot CLI y Pi. Se distribuye como un paquete de Python basado en su biblioteca estándar, acompañado de plugins para los agentes compatibles.
En una evaluación de 277 tareas de SWE-Bench, el sistema consiguió reducir el costo medio entre un 18,4% y un 30,9% en cinco combinaciones de agentes y modelos.
Los resultados forman parte del trabajo de investigación identificado como arXiv 2610.22732.
Por qué los agentes de programación desperdician tokens
El consumo de tokens de los agentes de programación depende de algo más que las instrucciones que reciben.
Cada interacción vuelve a incorporar el prompt del sistema, los esquemas de las herramientas disponibles y el historial acumulado de la conversación. Esta estructura puede provocar que el agente procese repetidamente información que ya utilizó en operaciones anteriores.
Para estudiar este fenómeno, los investigadores analizaron 60 tareas de SWE-Bench distribuidas entre seis repositorios, utilizando Claude Code con Opus 4.8.
El análisis identificó tres fuentes recurrentes de gasto innecesario.
1. Descubrimiento repetido de información
Cuando una tarea estaba precedida por otras cinco, el 30% de las llamadas a herramientas repetía alguna acción realizada anteriormente.
Esto significa que parte del presupuesto de tokens se destinaba a recuperar información o ejecutar operaciones que ya habían aparecido en el historial de trabajo.
2. Herramientas cargadas que apenas se utilizan
En las configuraciones analizadas se incorporaban 23 esquemas de herramientas en cada turno del agente.
De ellos, 16 nunca se utilizaban y solamente tres concentraban el 98% de todas las llamadas.
Pese a esa distribución, la información correspondiente a las herramientas permanecía dentro del contexto procesado.
3. Bucles de fallos que multiplican el gasto
Los investigadores identificaron 10 ejecuciones fallidas que representaban el 17% de las tareas, pero concentraban el 32% del costo total.
El comportamiento observado mostraba que un grupo relativamente pequeño de ejecuciones problemáticas podía consumir una proporción considerable del presupuesto.
El equipo también examinó tres estrategias de código abierto utilizadas para reducir el consumo: RTK, Serena y RepoMap de Aider.
Las tres redujeron costos en Django, pero los incrementaron en SymPy, lo que evidenció diferencias de rendimiento según el repositorio.
Cómo funciona TokenEconomizer: tres mecanismos para controlar el consumo
TokenEconomizer opera como un sistema externo que observa las ejecuciones de los agentes y mantiene información específica para cada repositorio.
A partir de los registros de tareas completadas, construye un estado que utiliza para establecer políticas antes de las siguientes ejecuciones.
Estas políticas actúan mediante el prompt, la configuración de herramientas y el flujo de eventos del agente.
El sistema incorpora tres mecanismos que pueden habilitarse de manera independiente.
Micro-skills: aprovechar conocimientos de tareas anteriores
El primer mecanismo convierte información obtenida durante ejecuciones previas en pequeños hechos reutilizables.
Un modelo de lenguaje encargado de proponer estos conocimientos analiza resúmenes de las trazas y genera afirmaciones de una línea, por ejemplo, relacionadas con el comando de pruebas utilizado en un repositorio.
Cada hecho incorpora detectores basados en expresiones regulares que permiten comprobar su aparición en futuras ejecuciones sin necesidad de realizar otra llamada al modelo.
Para que un conocimiento pase a formar parte del prompt deben cumplirse varias condiciones:
- Acumular tres confirmaciones en tareas cuyos archivos modificados no se superpongan.
- Mantener una tasa de necesidad de al menos 0,4.
- Superar un sistema de revisión en el que una contradicción equivale a cinco confirmaciones.
Este último criterio permite retirar rápidamente información que resulte incorrecta.
El objetivo es conservar conocimientos útiles del repositorio para evitar que el agente vuelva a descubrirlos en cada tarea.
Recorte de herramientas: reducir el contexto innecesario
El segundo mecanismo, denominado tool pruning, administra las herramientas disponibles para el agente.
Las funciones esenciales de Shell, lectura, escritura y edición permanecen habilitadas.
En cambio, otras herramientas pueden quedar ocultas después de tres tareas consecutivas sin utilización o cuando un modelo evaluador las considera irrelevantes.
El catálogo completo vuelve a estar disponible cada cinco tareas para realizar una nueva evaluación.
En una ejecución sobre Django con Claude Code, este mecanismo redujo los tokens del prompt de la primera petición de la segunda tarea de 43.351 a 16.295.
La reducción se consiguió al disminuir la cantidad de información sobre herramientas que el agente debía procesar.
Intervención en bucles de fallo: detectar ejecuciones atascadas
El tercer mecanismo busca identificar situaciones en las que un agente continúa consumiendo recursos sin conseguir avanzar.
TokenEconomizer establece un presupuesto de turnos basado en 1,25 veces el percentil 90 de la duración de las ejecuciones exitosas.
A continuación, utiliza comprobaciones basadas en reglas para detectar errores frecuentes o fallos repetidos.
Cuando aparecen estas señales, un modelo evaluador determina si el agente está atascado. La intervención requiere una confianza de al menos 0,7.
Si se detecta un bloqueo, el agente recibe una redirección. Si el problema vuelve a producirse, el controlador detiene la ejecución.
De esta manera, el sistema busca limitar el gasto generado por intentos repetidos que no permiten completar la tarea.
Resultados en SWE-Bench: ahorros de hasta el 30,9%
Los investigadores evaluaron TokenEconomizer sobre 277 tareas de SWE-Bench, utilizando cinco combinaciones de agentes y modelos.
Los cálculos incluyeron el costo de todas las llamadas realizadas por el propio controlador y emplearon tres semillas por configuración.
| Agente y modelo | Reducción del costo | Pass@1 original | Pass@1 con TokenEconomizer |
|---|---|---|---|
| Claude Code + Sonnet 5 | 23,6% | 74,7 | 76,0 |
| Claude Code + Opus 4.8 | 30,9% | 74,0 | 73,0 |
| Codex + GPT-5.6 Terra | 24,7% | 73,8 | 74,7 |
| Codex + GPT-5.6 Sol | 26,1% | 80,1 | 81,7 |
| Copilot CLI + Sonnet 5 | 18,4% | 75,0 | 77,6 |
El mayor ahorro individual correspondió a Claude Code con Opus 4.8, que registró una disminución del costo del 30,9%.
Cuando TokenEconomizer se combinó con RTK en esa configuración, el ahorro alcanzó el 33,2%.
Además de reducir el gasto, Pass@1 mejoró en cuatro de las cinco configuraciones.
La excepción fue Claude Code con Opus 4.8, donde el indicador pasó de 74,0 a 73,0, una reducción de 1,0 punto.
Los investigadores también analizaron la alternativa de disminuir el esfuerzo de razonamiento del modelo. Aunque esa estrategia redujo costos, produjo caídas de Pass@1 de entre 1,8 y 10,3 puntos.
Los ahorros aumentan conforme el sistema aprende
Otro resultado relevante fue la evolución del costo a medida que TokenEconomizer acumulaba información sobre los repositorios.
En la mayoría de los repositorios, las primeras tareas tuvieron un costo superior. Sin embargo, todos registraron un menor gasto al llegar a la sexta tarea.
En las 30 combinaciones de repositorio y configuración evaluadas, TokenEconomizer consiguió reducir costos.
El estudio también examinó por separado la contribución de sus tres mecanismos en Claude Code.
| Mecanismo | Reducción del costo |
|---|---|
| Recorte de herramientas | 13,2% a 17,7% |
| Micro-skills | 11,8% a 14,3% |
| Protección contra bucles de fallo | 5,4% a 7,1% |
El recorte de herramientas fue el mecanismo con mayor ahorro individual en estas pruebas, seguido por las micro-skills y la intervención en ejecuciones problemáticas.
Resultados fuera de SWE-Bench y límites observados
Los investigadores ampliaron las evaluaciones a otros conjuntos de tareas para examinar cómo se comportaba TokenEconomizer en diferentes escenarios.
Los resultados mostraron reducciones de costos en Web-Bench, CredData y ReposVul, aunque con diferencias importantes entre ellos.
| Evaluación | Reducción del costo |
|---|---|
| SWE-Bench | 18,4% a 30,9% |
| Web-Bench | 16,0% a 21,2% |
| CredData | 16,5% a 19,6% |
| ReposVul | 6,4% a 9,3% |
Web-Bench registró ahorros de entre el 16,0% y el 21,2%, mientras que CredData presentó reducciones de entre el 16,5% y el 19,6%.
El resultado más limitado apareció en las auditorías de ReposVul, donde las disminuciones oscilaron entre el 6,4% y el 9,3%.
La explicación indicada en el análisis está relacionada con la duración de las ejecuciones: las tareas más cortas dejan menos oportunidades para eliminar operaciones repetitivas o reducir información procesada.
Esto muestra que el beneficio económico de TokenEconomizer varía según las características y la extensión de las tareas ejecutadas.
Comparación con RTK, Serena y RepoMap de Aider
TokenEconomizer pertenece al grupo de herramientas que buscan controlar el consumo de tokens de los agentes de programación, pero utiliza un enfoque distinto al de otras alternativas.
Mientras RTK se centra en comprimir la salida de comandos Shell y RepoMap introduce información estructurada del repositorio en el prompt, TokenEconomizer aprende políticas específicas a partir de ejecuciones anteriores.
Serena, por su parte, proporciona herramientas para interactuar con código a nivel de símbolos mediante un servidor MCP.
La comparación presentada en la investigación recoge las siguientes características y resultados.
| Herramienta | Enfoque principal | Licencia | Compatibilidad | Cambio medio del costo en SWE-Bench |
|---|---|---|---|---|
| TokenEconomizer | Aprende políticas por repositorio a partir de tareas anteriores | Apache 2.0 | Claude Code, Codex, Copilot CLI y Pi | -18,4% a -30,9% |
| RTK | Comprime las salidas de comandos Shell | Apache 2.0 para CLI; BUSL-1.1 para motor | 18 herramientas de programación con IA | -8,9% a +4,5% |
| Serena | Servidor MCP con herramientas de código a nivel de símbolos | GPL-3.0-or-later; MIT para SolidLSP | Cualquier cliente MCP | Incremento del costo agrupado en el perfilado |
| RepoMap de Aider | Incorpora al prompt un mapa clasificado de símbolos del repositorio | Apache 2.0 | Aider | -6,1% a +6,5% |
Diferencias en la consistencia de los ahorros
Una parte importante del análisis consistió en comprobar cuántas configuraciones terminaban siendo más caras después de incorporar cada herramienta.
| Herramienta | Configuraciones con aumento del costo |
|---|---|
| TokenEconomizer | 0 de 30 |
| RTK | 12 de 30 |
| RepoMap de Aider | 15 de 30 |
TokenEconomizer consiguió reducir costos en las 30 combinaciones evaluadas.
En comparación, RTK incrementó el gasto en 12 configuraciones y RepoMap lo hizo en 15.
Serena se examinó durante el perfilado inicial, donde aumentó el costo agrupado, mientras que las ejecuciones principales se concentraron en las otras herramientas.
La diferencia fundamental del enfoque de TokenEconomizer reside en su capacidad para adaptar las decisiones al historial de cada repositorio, en lugar de aplicar una misma estrategia fija a todos los escenarios.
TokenEconomizer en contexto
TokenEconomizer es un proyecto de código abierto desarrollado por un equipo de investigadores de Microsoft Research y UC Berkeley.
Su código se distribuye bajo la licencia Apache 2.0 y está diseñado para funcionar como un controlador externo de agentes de programación.
El sistema es compatible con Claude Code, Codex, GitHub Copilot CLI y Pi, y requiere Python 3.10 o una versión superior.
Su funcionamiento no exige una GPU ni una clave API propia, ya que utiliza la infraestructura del agente con el que trabaja.
La propuesta del proyecto consiste en aprovechar la información acumulada durante las tareas anteriores para controlar el consumo de tokens sin modificar los modelos de inteligencia artificial ni el código de los agentes.
Los resultados de la investigación muestran que esta estrategia puede reducir el gasto en distintos escenarios de programación, especialmente cuando el sistema dispone de varias tareas anteriores de las que aprender.
