GitHub: usar menos tokens no siempre reduce los costos
La plataforma está replanteando una de las métricas más utilizadas para medir la eficiencia de los agentes de programación. Sus experimentos con Copilot muestran que reducir la cantidad de tokens de una interacción puede terminar encareciendo una tarea completa si obliga al agente a recuperar información, repetir comandos o realizar más llamadas.
Durante meses, buena parte de la conversación sobre eficiencia en inteligencia artificial ha girado alrededor de una pregunta aparentemente sencilla: ¿cómo hacer que un modelo utilice menos tokens?
GitHub acaba de plantear una respuesta menos intuitiva: no necesariamente hay que utilizar menos tokens, sino evitar que el agente haga trabajo innecesario.
Erik Kristensen y Napalys Klicius, ingenieros de GitHub, explican cómo el equipo está reduciendo los costos de GitHub Copilot sin sacrificar la calidad de las tareas de programación. La tesis es importante para el futuro de los agentes de IA: el costo real no está determinado por una interacción aislada, sino por todo el recorrido desde la petición del usuario hasta el resultado final.
El problema puede verse en un ejemplo sencillo. Un desarrollador pide a un agente que modifique una aplicación. El agente ejecuta un comando y recibe cientos de líneas de salida. Reducir esa respuesta parece una optimización obvia. Menos texto significa menos tokens y, en teoría, menos dinero.
Pero si dentro de lo eliminado estaba la información que el agente necesitaba, tendrá que volver a ejecutar el comando o recuperar la salida original. El resultado es paradójico: la respuesta individual se hizo más barata, pero la tarea completa se volvió más cara.
GitHub probó precisamente este escenario con RTK (Rust Token Killer), una utilidad diseñada para reducir la salida de comandos antes de que llegue al agente. En los benchmarks utilizados por GitHub, algunas respuestas efectivamente se acortaron, pero cuando la información omitida era relevante, el modelo volvía a consultar el resultado original o repetía el comando.
Eso añadía turnos, contexto y tiempo. La lección es casi contraintuitiva para una industria obsesionada con la reducción del consumo: ahorrar tokens localmente puede aumentar el gasto global.
La eficiencia se mueve fuera del modelo
El planteamiento de GitHub refleja una evolución en la arquitectura de los agentes de IA. El modelo sigue aportando la capacidad de razonamiento, pero una capa de software, conocida como harness, decide cómo se utilizan esas capacidades.
En junio, GitHub explicó que su agentic harness es un componente compartido que alimenta Copilot CLI, Copilot app, Copilot code review y otras experiencias. En sus pruebas, el sistema alcanzó tasas de finalización de tareas comparables a otros harnesses de proveedores de modelos, pero con menor consumo de tokens en la mayoría de configuraciones evaluadas. También mantiene la posibilidad de trabajar con más de 20 modelos.
Ahora GitHub muestra cómo esa arquitectura se puede optimizar desde diferentes ángulos. Uno de los experimentos eliminó prefijos de visualización que no aportaban información útil. Otro aplicó compresión selectiva a las respuestas. Un tercero redujo el tamaño de las instrucciones de herramientas sin modificar el comportamiento esperado. El cuarto eliminó ciclos adicionales de recuperación de información.
Los cuatro experimentos produjeron reducciones independientes en el uso medido mediante AI Credits: 3,1%, 5,5%, 2,9% y 2,3%, respectivamente. GitHub aclara que los efectos no deben interpretarse como estrictamente acumulativos.
La diferencia está en qué se elimina.
GitHub descubrió que las salidas de instalación, compilación, pruebas y lint suelen contener ruido repetitivo, mientras que el código fuente y determinados resultados arbitrarios pueden contener información crítica. Por eso, su sistema comprime selectivamente las primeras categorías, pero conserva sin modificaciones resultados como cat, git diff, git show y scripts arbitrarios.
El equipo aprendió esta distinción después de cometer el error contrario. Una primera versión comprimía git diff, pero los benchmarks mostraron que los agentes tenían que volver a abrir la información original para recuperar lo que se había eliminado. La optimización terminó aumentando el costo total y reduciendo la tasa de éxito.
Es una pequeña lección de ingeniería con implicaciones grandes para la economía de los agentes.
Un agente barato no es el que habla menos
La idea central de GitHub puede resumirse así: el objetivo no debería ser minimizar tokens por llamada, sino maximizar el trabajo realizado por unidad de costo.
La diferencia importa porque los agentes de programación no funcionan como un chatbot convencional. Pueden ejecutar comandos, inspeccionar archivos, analizar resultados, modificar código, volver a probarlo y corregir errores. Una tarea aparentemente simple puede convertirse en una cadena de interacciones.
Cada optimización aplicada a un eslabón puede modificar el comportamiento de los siguientes.
GitHub encontró un ejemplo concreto cuando intentó aplicar instrucciones de herramientas de archivos más compactas. El cambio había producido resultados positivos en Copilot code review, pero en un experimento online con Copilot CLI aumentó el costo. La compañía decidió no implementarlo.
Ese resultado cuestiona otra suposición habitual del desarrollo de IA: que una mejora comprobada en un producto debería trasladarse automáticamente a otro.
Para GitHub, la respuesta es no. El contexto importa.
En sus evaluaciones independientes sobre tareas de revisión de código, eliminar prefijos con números de línea y comprimir selectivamente las salidas redujo aproximadamente 5% los tokens promedio de los prompts, sin cambios materiales en las métricas de calidad. Además, una migración anterior de Copilot code review hacia herramientas de archivos compartidas, combinada con ajustes en las instrucciones, había reducido alrededor de 20% el costo de las revisiones.
GitHub también había reportado en junio que la utilización de herramientas compartidas como grep, rg, glob y view, junto con el ajuste de instrucciones, permitió reducir aproximadamente 20% el costo de Copilot code review manteniendo el estándar de calidad.
La batalla por la eficiencia llega al harness
Este cambio de enfoque ocurre mientras el desarrollo asistido por agentes se vuelve más intensivo.
En junio, GitHub señaló que las nuevas generaciones de modelos tienden a consumir más tokens por tarea. Con la transición de Copilot hacia modelos y esquemas de uso en los que cada token importa, las eficiencias de la capa de orquestación adquieren mayor relevancia.
Eso convierte al harness en una pieza estratégica. Si el modelo es el motor, el harness funciona cada vez más como la transmisión que decide cuánto trabajo llega realmente al motor, qué información se conserva, qué tareas puede resolver directamente el sistema y cuándo es necesario volver al modelo.
GitHub lo plantea de manera explícita: una de sus estrategias consiste en eliminar turnos del modelo cuando el harness puede realizar una tarea de forma determinista. En otras palabras, no todo debe ser razonado por un modelo de lenguaje. Algunas operaciones pueden ejecutarse de forma más rápida y barata fuera de él.
Comentarios