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 corta 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 costo a nivel 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 publicación de blog escrita por Eric Christensen y Nabales Klesius el 2 de septiembre de 2026, GitHub explicó cuatro cambios que, según afirmó, se desarrollaron mediante pruebas sin conexión usando 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 de la publicación proceden de GitHub Copilot CLI.
¿Por qué no basta con una respuesta más corta?
GitHub probó el efecto de la herramienta RTK, o Rust Token Killer, que comprime las salidas de shell antes de mostrarlas al agente. En las configuraciones de prueba utilizadas, eliminar ciertos textos importantes provocó que se volvieran a abrir las salidas originales o se ejecutaran de nuevo 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 a 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 abarcar desde la solicitud del usuario hasta el resultado final, contabilizando 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 conservando 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 necesaria.
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 conservó una vía directa para recuperar la salida original completa. GitHub siguió utilizando esta vía como mecanismo de seguridad y como 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 observó una disminución estadísticamente significativa en el éxito de las tareas, mientras que el experimento en línea redujo ligeramente el costo medio sin un deterioro sustancial de los indicadores de calidad supervisados.
Eliminación de formato innecesario
GitHub obtuvo 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 son útiles en diferencias y fragmentos breves.
El cambio redujo el costo de inferencia del modelo aproximadamente un 5% en los criterios de tareas de programación agéntica sin conexión, manteniendo las tasas de éxito dentro de la variación esperada y sin aumentar los errores de edición. En un experimento en línea con usuarios de Copilot CLI, el costo medio diario de inferencia por usuario disminuyó aproximadamente un 3%, sin un deterioro sustancial de 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 a través de 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 cuidadoso se transformaron en una política de programación estricta, lo que hizo que los agentes independientes especializados trabajaran en secuencia. 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 costo normalizado por hora de actividad, sin que se observara un deterioro de la calidad en las evaluaciones medidas.
Eliminación de rondas de recuperación innecesarias
Los agentes a veces ejecutan trabajos independientes en segundo plano, como ejecutar un comando de shell largo en paralelo con una investigación realizada por un subagente. Antes, las notificaciones de finalización de estos trabajos llegaban sin el resultado correspondiente, por lo que el agente debía realizar una llamada adicional para recuperar salidas que Copilot ya había obtenido. Ahora, el sistema reúne las notificaciones de finalización elegibles y envía los resultados completados dentro del formato de resultados de herramienta existente.
En el ejemplo que combina un comando de shell y un subagente, completar el trabajo requería antes 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 relacionado con 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 no utilizado, 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 otro lado, no todos los resultados pueden generalizarse fuera del entorno de prueba. Reducir las instrucciones de las herramientas de archivos, pese a su éxito en la revisión de código, aumentó el costo 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 material es la necesidad de medir el cambio a nivel de la tarea, el flujo de trabajo y el producto en el que se utilizará, mediante criterios sin conexión, experimentos en línea y pruebas de comportamiento claras. El efecto de estas mejoras en un usuario concreto, en cambio, 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.