Un plugin de código abierto desarrollado por investigadores de Microsoft Research y UC Berkeley busca reducir el gasto de los agentes de programación al aprender de sesiones previas, aunque sus pruebas también registran una leve caída de precisión en una configuración.
***
- TokenEconomizer redujo entre 18,4% y 30,9% el costo promedio en cinco configuraciones de agentes y modelos evaluadas con SWE-Bench.
- El sistema poda herramientas poco usadas, reutiliza aprendizajes por repositorio y detecta bucles de fallas sin alterar el modelo ni el agente.
- Pass@1 mejoró en cuatro configuraciones, pero cayó un punto en Claude Code con Opus 4.8; en ReposVul los ahorros fueron menores.
⚙️ Microsoft presenta TokenEconomizer: agentes de código costaron hasta 30,9% menos
La prueba cubrió 277 tareas de SWE-Bench y cinco configuraciones.
Pass@1 mejoró en cuatro; con Opus 4.8 cayó de 74% a 73%.
El plugin abierto aprende de sesiones previas por repositorio. pic.twitter.com/ZdPk1JbRaX
— Diario฿itcoin (@DiarioBitcoin) October 30, 2026
Un equipo de investigadores de Microsoft Research y UC Berkeley presentó TokenEconomizer, un plugin de código abierto que busca disminuir el costo de los agentes de programación aprovechando lo aprendido en tareas anteriores de cada repositorio. En pruebas con 277 tareas de SWE-Bench, la herramienta redujo el costo promedio entre 18,4% y 30,9% en cinco combinaciones de agente y modelo, sin modificar los pesos del modelo ni el código del agente.
La propuesta apunta a un problema práctico de estos sistemas: cada turno puede volver a facturar instrucciones, esquemas de herramientas y partes del historial de conversación. Según MarkTechPost, TokenEconomizer funciona con Claude Code, Codex, GitHub Copilot CLI y Pi; además, el paquete requiere Python 3.10 o posterior, pero no una GPU ni una clave de API propia. El repositorio de Microsoft describe el proyecto como un plugin que analiza cada sesión completada para aprovechar la experiencia acumulada.
Un controlador externo que aprende del repositorio
TokenEconomizer no reemplaza al agente ni intenta cambiar la manera en que el modelo genera código. Se instala como una capa externa que trata al agente como una caja negra y mantiene, para cada repositorio, un estado construido a partir de trazas de tareas completadas; antes de una nueva ejecución, ese historial sirve para ajustar políticas de instrucciones, herramientas y flujo de eventos.
El diseño combina tres mecanismos conmutables: microhabilidades, poda de herramientas e intervención ante bucles de falla. La idea común es reducir actividad redundante sin imponer una receta fija a todos los proyectos, ya que una herramienta útil en un repositorio puede resultar innecesaria o incluso elevar el costo en otro.
El componente de microhabilidades convierte resúmenes de sesiones previas en hechos breves, como el comando que permite ejecutar las pruebas de un proyecto. Un proponente basado en un modelo de lenguaje sugiere esos datos, mientras detectores de expresiones regulares los contrastan con trazas posteriores para verificar si siguen siendo pertinentes.
Una microhabilidad solo entra en las instrucciones después de recibir tres confirmaciones en tareas cuyos archivos editados no se superponen, y su tasa de necesidad debe mantenerse en 0,4 o más. El sistema también considera que una contradicción equivale a cinco confirmaciones, un criterio destinado a retirar con rapidez recomendaciones que resulten incorrectas o hayan quedado desactualizadas.
Menos herramientas y menos repeticiones
La poda de herramientas busca reducir el material que el agente recibe en cada turno. Shell, lectura, escritura y edición siempre permanecen disponibles, pero otras herramientas pueden ocultarse después de tres tareas consecutivas sin uso o cuando un juez de modelo de lenguaje las considera irrelevantes para el trabajo actual.
El catálogo completo no desaparece de manera permanente: vuelve a habilitarse cada cinco tareas para permitir una nueva auditoría. En una prueba con Django y Claude Code, la primera solicitud de la segunda tarea pasó de 43.351 a 16.295 tokens de prompt, una reducción que ilustra cuánto puede crecer el contexto cuando se cargan herramientas que el agente no necesita.
El tercer mecanismo intenta reconocer cuándo el agente repite errores o se queda atrapado en un ciclo improductivo. TokenEconomizer aprende un presupuesto de turnos equivalente a 1,25 veces el percentil 90 de la duración de ejecuciones exitosas; reglas sencillas detectan patrones sospechosos y un juez de modelo de lenguaje decide si existe un bloqueo con una confianza de al menos 0,7.
Si el controlador considera que el agente está atascado, primero lo redirige una vez y, si el ciclo continúa, detiene la ejecución. El objetivo es limitar el gasto de tareas que consumen recursos sin avanzar, aunque esta intervención implica que el sistema debe decidir cuándo insistir y cuándo interrumpir un intento que todavía podría encontrar una solución.
Resultados en SWE-Bench y otros conjuntos de pruebas
En las cinco configuraciones evaluadas sobre SWE-Bench, TokenEconomizer redujo el costo frente a la ejecución predeterminada: 23,6% con Claude Code y Sonnet 5; 30,9% con Claude Code y Opus 4.8; 24,7% con Codex y GPT-5.6 Terra; 26,1% con Codex y GPT-5.6 Sol; y 18,4% con Copilot CLI y Sonnet 5.
La medida de éxito Pass@1, que refleja la proporción de tareas resueltas con una sola generación evaluada, aumentó en cuatro de esas cinco combinaciones. Con Opus 4.8 bajó de 74,0 a 73,0, una diferencia de un punto; en las otras configuraciones, las cifras pasaron de 74,7 a 76,0 con Sonnet 5, de 73,8 a 74,7 con GPT-5.6 Terra, de 80,1 a 81,7 con GPT-5.6 Sol y de 75,0 a 77,6 con Copilot CLI y Sonnet 5.
Los investigadores también compararon el sistema con estrategias abiertas de reducción de costos, como RTK, Serena y RepoMap de Aider. En las 30 celdas de repositorio y configuración que reporta el análisis, TokenEconomizer fue más barato que la ejecución predeterminada en todas; RTK elevó el costo en 12 celdas y RepoMap lo hizo en 15, mientras que las tres alternativas redujeron gastos en Django, pero los aumentaron en SymPy.
Los ahorros no aparecieron necesariamente desde la primera tarea de un repositorio: la mayoría de los proyectos costó más al comienzo mientras el sistema acumulaba información, pero todos resultaron más baratos para la sexta tarea. En Claude Code, el desglose atribuyó a la poda de herramientas reducciones de entre 13,2% y 17,7%, a las microhabilidades entre 11,8% y 14,3%, y al protector contra bucles entre 5,4% y 7,1%.
Alcances, límites e instalación
Las pruebas también incluyeron Web-Bench y CredData, donde los costos bajaron entre 16,0% y 21,2%, y entre 16,5% y 19,6%, respectivamente. En ReposVul, en cambio, las reducciones fueron de 6,4% a 9,3%; la explicación planteada por el equipo es que las ejecuciones más cortas dejan menos actividad que eliminar.
El resultado pone de relieve que el ahorro depende del tipo de tarea y de la configuración utilizada, no solo de instalar un plugin. El balance entre costo y capacidad también importa: aunque Pass@1 subió en cuatro configuraciones de SWE-Bench, la medición cayó un punto en Opus 4.8, y una evaluación de costos no equivale por sí sola a demostrar que la herramienta mejora todos los aspectos de la programación asistida.
Para instalarlo se necesita uno de los cuatro agentes compatibles y Python 3.10 o una versión posterior. En Claude Code, el procedimiento descrito consiste en clonar el repositorio, agregarlo como marketplace y ejecutar claude plugin install tokeneconomizer@tokeneconomizer; los datos aprendidos quedan localmente en ~/.tokeneconomizer.
La poda de herramientas y la protección contra bucles vienen activadas por defecto, mientras que las microhabilidades comienzan desactivadas porque su proponente añade llamadas al modelo. El proyecto se distribuye bajo licencia Apache 2.0 y su repositorio incluye instrucciones para los agentes compatibles, de modo que los equipos pueden probar los mecanismos según las necesidades de sus propios flujos de trabajo.
Los datos perfilados por el equipo ayudan a explicar la apuesta: en 60 tareas de SWE-Bench distribuidas en seis repositorios, los investigadores observaron repeticiones, herramientas sin uso y ejecuciones fallidas que absorbían una fracción desproporcionada del gasto. TokenEconomizer intenta convertir ese diagnóstico en controles específicos por proyecto, aunque sus resultados deberán leerse junto con las diferencias entre conjuntos de pruebas y la caída puntual de Pass@1.
Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.
Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.
ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.
Suscríbete a nuestro boletín
Artículos Relacionados
Asia
Hong Kong llevará la inteligencia artificial a las aulas de primaria a partir de 2028
Educación
EE. UU. acusa a cinco personas por fraude con estudiantes fantasma y préstamos universitarios
IA
Claude eligió una terapia génica y operó el cerebro de un ratón, pero se detuvo por seguridad
Empresas
