GitHub estime que mesurer l’efficacité des agents de programmation en fonction du nombre de tokens dans un seul appel peut conduire à un résultat trompeur. Une sortie plus courte peut contraindre le modèle à réexécuter une commande ou à demander les informations supprimées, ce qui augmente le nombre de tours, le temps et le coût à l’échelle de la tâche complète. En conséquence, l’entreprise a réévalué les améliorations de GitHub Copilot en fonction du résultat final de la tâche, et non du volume de la réponse d’un outil isolé.
Dans un article publié par Eric Christensen et Nabalès Klesius le 2 septembre 2026, GitHub a expliqué quatre changements qui, selon elle, ont été développés au moyen de tests hors ligne utilisant des critères d’évaluation des tâches de programmation agentique, puis validés par des expériences contrôlées avec les utilisateurs avant leur lancement. Plusieurs produits Copilot, dont l’application GitHub Copilot et la revue de code, utilisent la même infrastructure, tandis que les exemples présentés dans l’article proviennent de GitHub Copilot CLI.
Pourquoi une réponse plus courte ne suffit-elle pas ?
GitHub a testé l’impact de l’outil RTK, ou Rust Token Killer, qui abrège les sorties du shell avant de les présenter à l’agent. Dans les configurations de test utilisées, la suppression de certains textes importants a entraîné la réouverture des sorties originales ou la réexécution des commandes. En conséquence, le volume de la réponse de l’outil a diminué localement, mais la tâche a nécessité en moyenne davantage de tokens et plus de temps.
L’entreprise souligne que ce résultat concerne l’intégration et les charges de travail qu’elle a testées, et ne constitue pas un jugement sur toutes les configurations de RTK ni sur toutes les méthodes de compression des sorties. La leçon pratique est que le critère d’évaluation doit s’étendre de la demande de l’utilisateur jusqu’au résultat final, en comptabilisant les tours de récupération et le travail supplémentaire.
Compression sélective des sorties
La solution de GitHub a consisté à compresser le bruit répétitif tout en conservant les informations dont l’agent a besoin. Des analyses opérationnelles ont montré que les sorties d’installation, de compilation, de test et des opérations de lint contiennent souvent beaucoup de répétitions, tandis que les sorties ressemblant à du code et les résultats de commandes arbitraires peuvent contenir des informations indispensables.
La version lancée a adopté une politique en trois points :
- Conserver inchangées les sorties ressemblant à du code et les résultats arbitraires, notamment les commandes telles que cat, git diff, git show et les scripts arbitraires.
- Réorganiser les résultats de recherche, tels que ceux de grep et les listes de fichiers, sans supprimer aucun résultat.
- Compresser les sorties d’installation, de compilation, de test et de progression uniquement lorsque le gain est important.
Copilot a également conservé un accès direct permettant de récupérer la sortie originale complète. GitHub a continué à surveiller l’utilisation de cet accès comme mécanisme de sécurité et comme indicateur signalant que la compression avait supprimé des informations utiles. Dans les tâches hors ligne où la compression était activée, l’entreprise n’a pas observé de baisse statistiquement significative du taux de réussite des tâches, tandis que l’expérience en ligne a légèrement réduit le coût moyen sans diminution substantielle des indicateurs de qualité suivis.
Suppression du formatage superflu
GitHub a réalisé l’une de ses économies les plus nettes grâce à l’outil view, qui présente le contenu des fichiers au modèle. L’outil ajoutait un numéro de ligne à chaque ligne, bien que les outils d’édition actuels reposent sur la correspondance avec le code environnant et n’utilisent pas ces numéros dans le flux de travail habituel. L’entreprise a donc supprimé ces préfixes des lectures de fichiers, tout en conservant les numéros de ligne lorsqu’ils sont utiles dans les différences et les courts extraits.
Ce changement a réduit d’environ 5 % le coût d’inférence du modèle dans les critères hors ligne des tâches de programmation agentique, tandis que les taux de réussite sont restés dans la variation attendue et que les erreurs d’édition n’ont pas augmenté. Lors d’une expérience en ligne menée auprès d’utilisateurs de Copilot CLI, le coût quotidien moyen d’inférence par utilisateur a diminué d’environ 3 %, sans baisse substantielle des indicateurs de qualité ou de satisfaction mesurés par GitHub.
Raccourcir les instructions sans modifier le comportement
Les instructions de l’outil task s’étaient accumulées dans les descriptions des outils, les schémas, les définitions des agents et les instructions système. GitHub a utilisé une boucle d’optimisation automatique des instructions, réduisant le texte d’environ moitié, puis a testé les comportements qu’elle souhaitait préserver.
La première expérience en ligne a toutefois révélé un problème qui n’était pas apparu dans les évaluations hors ligne : les consignes de parallélisme prudent s’étaient transformées en politique de planification stricte, obligeant les agents indépendants personnalisés à travailler séquentiellement. GitHub a interrompu l’expérience, ajouté un test de régression pour ce comportement, puis remplacé la liste d’autorisation et d’interdiction par une seule phrase : « Les agents indépendants peuvent travailler en parallèle ; tenez compte des effets secondaires ».
La formulation finale a supprimé environ 1 300 tokens des instructions de l’outil de tâches à chaque tour, ce qui équivaut à une baisse d’environ 1,8 % du nombre total de tokens d’instructions par session et de 2,9 % du coût normalisé par heure d’activité, sans baisse de qualité observée dans les évaluations mesurées.
Supprimer les tours de récupération inutiles
Les agents exécutent parfois des tâches indépendantes en arrière-plan, comme lancer une longue commande shell en parallèle d’une investigation menée par un sous-agent. Auparavant, les notifications d’achèvement de ces tâches arrivaient sans le résultat lui-même, obligeant l’agent à effectuer un appel supplémentaire pour récupérer des sorties que Copilot avait déjà obtenues. Désormais, le système regroupe les notifications d’achèvement admissibles et envoie les résultats terminés dans le format de résultats d’outil existant.
Dans l’exemple combinant une commande shell et un sous-agent, l’achèvement de la tâche nécessitait auparavant quatre appels au modèle : deux appels pour demander les résultats et deux appels pour les traiter. Après le changement, les deux résultats arrivent ensemble dans un seul appel de traitement. Cela a réduit d’environ 2,3 % l’utilisation moyenne liée aux tokens, telle que mesurée par les unités AI Credits.
Qu’est-ce qui change concrètement ?
L’expérience de GitHub fournit une règle importante aux développeurs d’agents de programmation : l’optimisation la plus sûre ne consiste pas à supprimer le plus de texte possible, mais à éliminer le travail dont le modèle n’a pas besoin. Cela inclut le formatage inutilisé, les tours d’attente et de récupération que le système peut résoudre, ainsi que les répétitions qui peuvent être compressées tout en fournissant un mécanisme de récupération.
En revanche, tous les résultats ne peuvent pas être généralisés au-delà de l’environnement de test. Le resserrement des instructions des outils de fichiers, malgré son succès dans la revue de code, a augmenté le coût dans une expérience avec Copilot CLI ; GitHub ne l’a donc pas lancé. De même, la compression de git diff a été supprimée après que les critères ont montré que les agents rouvraient la sortie originale pour récupérer les informations supprimées.
La conclusion établie par l’article est qu’il faut mesurer le changement au niveau de la tâche, du flux de travail et du produit qui l’utilisera, au moyen de critères hors ligne, d’expériences en ligne et de tests comportementaux clairs. L’impact de ces améliorations sur un utilisateur donné dépend toutefois du type de tâches, des outils et de leurs sorties, et ne peut pas être déduit de la seule diminution locale du nombre de tokens.