GitHub considera que medir la eficiencia de los agentes de programación basándose en el número de tokens de una sola llamada puede conducir a un resultado engañoso. Una salida más breve puede obligar al modelo a volver a ejecutar un comando o solicitar la información eliminada, lo que aumenta el número de rondas, el tiempo y el coste de toda la tarea. Por ello, la empresa reevaluó las mejoras de GitHub Copilot según el resultado final de la tarea, no según el tamaño de la respuesta de una herramienta individual.
En una entrada publicada por Eric Christensen y Nabalis Klesius el 2 de septiembre de 2026, GitHub explicó cuatro cambios que, según afirmó, se desarrollaron mediante pruebas sin conexión utilizando criterios para evaluar tareas de programación agéntica y que posteriormente se validaron mediante experimentos controlados con usuarios antes de su lanzamiento. Varios productos de Copilot, entre ellos la aplicación GitHub Copilot y la revisión de código, utilizan la misma infraestructura, mientras que los ejemplos incluidos en la entrada proceden de GitHub Copilot CLI.
¿Por qué no basta con una respuesta más breve?
GitHub probó el impacto de la herramienta RTK, o Rust Token Killer, que acorta las salidas de shell antes de mostrarlas al agente. En la configuración de prueba utilizada, eliminar algunos textos importantes provocó que se volvieran a abrir las salidas originales o se volvieran a ejecutar los comandos. Como resultado, el tamaño de la respuesta de la herramienta disminuyó localmente, pero la tarea necesitó, en promedio, más tokens y más tiempo.
La empresa confirma que este resultado corresponde a la integración y las cargas de trabajo que probó, y no representa un juicio sobre todas las configuraciones de RTK ni sobre todos los métodos de compresión de salidas. La lección práctica es que el criterio de evaluación debe extenderse desde la solicitud del usuario hasta el resultado final, teniendo en cuenta las rondas de recuperación y el trabajo repetido.
Compresión selectiva de las salidas
La solución de GitHub consistió en comprimir el ruido repetitivo y conservar la información que el agente necesita. Los análisis operativos mostraron que las salidas de instalación, compilación, pruebas y operaciones de lint suelen contener mucha repetición, mientras que las salidas similares al código y los resultados de comandos arbitrarios pueden contener información esencial.
La versión lanzada adoptó una política de tres puntos:
- Mantener sin cambios las salidas similares al código y los resultados arbitrarios, incluidos comandos como cat, git diff, git show y scripts arbitrarios.
- Reorganizar los resultados de búsqueda, como los resultados de grep y las listas de archivos, sin eliminar ningún resultado.
- Comprimir las salidas de instalación, compilación, pruebas y progreso únicamente cuando el ahorro sea considerable.
Copilot también mantuvo una vía directa para recuperar la salida original completa. GitHub siguió el uso de esta vía como mecanismo de seguridad e indicador de que la compresión había eliminado información útil. En las tareas sin conexión en las que se activó la compresión, la empresa no detectó un descenso estadísticamente significativo en el éxito de las tareas, mientras que el experimento en línea redujo ligeramente el coste medio sin un retroceso sustancial en los indicadores de calidad supervisados.
Eliminación de formato innecesario
GitHub logró uno de los ahorros más claros mediante la herramienta view, que muestra el contenido de los archivos al modelo. La herramienta añadía un número de línea a cada línea, aunque las herramientas de edición actuales se basan en la coincidencia del código circundante y no utilizan esos números en el flujo de trabajo habitual. Por ello, la empresa eliminó estos prefijos de las lecturas de archivos, manteniendo los números de línea cuando resultan útiles en diferencias y fragmentos breves.
El cambio redujo en aproximadamente un 5% el coste de inferencia del modelo en criterios sin conexión para tareas de programación agéntica, mientras que las tasas de éxito se mantuvieron dentro de la variación esperada y no aumentaron los errores de edición. En un experimento en línea con usuarios de Copilot CLI, el coste medio diario de inferencia por usuario disminuyó aproximadamente un 3%, sin un descenso sustancial en los indicadores de calidad o satisfacción medidos por GitHub.
Acortar las instrucciones sin cambiar el comportamiento
Las instrucciones de la herramienta task se acumularon en las descripciones de herramientas, los esquemas, las definiciones de agentes y las instrucciones del sistema. GitHub utilizó un ciclo para optimizar automáticamente las instrucciones, reduciendo el texto aproximadamente a la mitad, y después probó los comportamientos que quería conservar.
Sin embargo, el primer experimento en línea reveló un problema que no había aparecido en las evaluaciones sin conexión: las directrices sobre el paralelismo prudente se habían convertido en una política de programación estricta, lo que hizo que los agentes personalizados independientes trabajaran secuencialmente. GitHub detuvo el experimento, añadió una prueba de regresión para este comportamiento y sustituyó la lista de permisos y prohibiciones por una sola frase: «Los agentes independientes pueden trabajar en paralelo; ten en cuenta los efectos secundarios».
La formulación final redujo aproximadamente 1300 tokens de las instrucciones de la herramienta de tareas en cada ronda, lo que equivale a una disminución cercana al 1,8% en el total de tokens de instrucciones por sesión y del 2,9% en el coste normalizado por hora de actividad, sin detectar un descenso de la calidad en las evaluaciones medidas.
Eliminación de rondas de recuperación innecesarias
Los agentes ejecutan a veces trabajos independientes en segundo plano, como ejecutar un comando de shell largo en paralelo con una investigación realizada por un subagente. Anteriormente, las notificaciones de finalización de estos trabajos llegaban sin el resultado correspondiente, por lo que el agente tenía que realizar una llamada adicional para recuperar salidas que Copilot ya había obtenido. Ahora, el sistema recopila las notificaciones de finalización pertinentes y envía los resultados completados dentro del formato existente de resultados de herramientas.
En el ejemplo que combina un comando de shell y un subagente, completar el trabajo requería anteriormente cuatro llamadas al modelo: dos llamadas para solicitar los resultados y dos para procesarlos. Después del cambio, ambos resultados llegan juntos en una sola llamada para su procesamiento. Esto redujo aproximadamente un 2,3% el uso medio asociado a los tokens, según la medición de las unidades de AI Credits.
¿Qué cambia en la práctica?
La experiencia de GitHub ofrece una regla importante para los desarrolladores de agentes de programación: la optimización más segura no consiste en eliminar la mayor cantidad posible de texto, sino en eliminar el trabajo que el modelo no necesita realizar. Esto incluye el formato que no se utiliza, las rondas de espera y recuperación que el sistema puede resolver, y la repetición que puede comprimirse proporcionando una vía de recuperación.
Por el contrario, no todos los resultados pueden generalizarse fuera del entorno de prueba. El estrechamiento de las instrucciones de las herramientas de archivos, aunque tuvo éxito en la revisión de código, aumentó el coste en un experimento de Copilot CLI, por lo que GitHub no lo lanzó. Asimismo, la compresión de git diff se eliminó después de que los criterios mostraran que los agentes volvían a abrir la salida original para recuperar la información eliminada.
La conclusión que demuestra el artículo es la necesidad de medir el cambio a nivel de la tarea, el flujo de trabajo y el producto que lo utilizará, mediante criterios sin conexión, experimentos en línea y pruebas de comportamiento claras. El efecto de estas mejoras en un usuario concreto sigue dependiendo del tipo de tareas, las herramientas y sus salidas, y no puede deducirse únicamente de una disminución local del número de tokens.