Dans son blog technique du 2 septembre, GitHub a publié une liste de réductions de coûts pour son agent de codage Copilot, signée Erik Kristensen et Napalys Klicius. Quatre changements, qui économisent respectivement 5,5 %, 3,1 %, 2,9 % et 2,3 % du coût d'inférence, agissent tous sur le contexte envoyé au modèle, aucun ne reposant sur un changement de modèle.
Quatre changements, chacun quelques points de pourcentage
En tête vient la compression sélective des sorties, qui économise 5,5 %. Les règles sont finement découpées : le code source reste intact, la sortie des commandes reste intacte, les résultats de recherche sont seulement réordonnés sans suppression de contenu ; seul le bruit répétitif — des milliers de lignes dans les logs d'installation, de build et de tests — est compressé. La partie compressée conserve un chemin de récupération, permettant au modèle de retrouver la sortie originale en cas de besoin.
Le deuxième changement supprime le préfixe de numéro de ligne lors de la lecture des fichiers, économisant 3,1 %. Dans ses premières versions, Copilot ajoutait un numéro au début de chaque ligne lue, un format dont le flux d'édition actuel n'a plus besoin. Après suppression, le coût d'inférence du modèle a baissé d'environ 5 % dans les benchmarks, ce qui correspond à 3,1 % sur la facture globale — les deux chiffres reposent sur des bases de calcul différentes.
Le troisième changement porte sur le prompt de l'outil task. L'équipe a utilisé une approche de méta-prompting pour réduire de moitié le passage consacré à l'exécution parallèle, sans changer le comportement, ce qui économise 2,9 %. Ce fragment de prompt est renvoyé à chaque interaction avec le modèle ; une fois compressé, chaque tour économise environ 1 300 tokens.
Le quatrième changement réduit les allers-retours de notifications, économisant 2,3 %. Auparavant, une fois une tâche en arrière-plan terminée, il fallait un tour de récupération supplémentaire pour faire parvenir le résultat au modèle ; avec l'envoi direct par lots, c'est un appel entier au modèle qui est économisé.
Économiser des tokens n'est pas la même chose que réduire le contexte
La phrase la plus susceptible d'être mal comprise dans cette liste est leur définition de l'objectif :
"The goal shouldn't be to use fewer tokens, but to tap into the right amount of context to move a task forward."
L'objectif ne devrait pas être d'utiliser moins de tokens, mais de puiser dans la bonne quantité de contexte pour faire avancer une tâche.
Le point commun des quatre changements est de ne supprimer que ce que le modèle lit sans jamais l'utiliser : logs de build répétitifs, numéros de ligne que personne ne consulte, longues instructions renvoyées à chaque tour, tours de récupération superflus. Les éléments porteurs d'information réelle — code source, sortie des commandes, résultats de recherche — ne sont pas touchés. La frontière entre « redondance » et « manque de contexte » est la condition qui rend toute cette démarche applicable — couper trop se paie par une baisse du taux de réussite des tâches, une facture bien plus lourde que les tokens économisés.
D'abord un benchmark hors ligne, puis une comparaison en ligne
Le passage sur le processus est plus instructif que les chiffres eux-mêmes. Chaque changement a d'abord été validé sur un benchmark hors ligne d'agents de codage pour vérifier que la qualité des tâches ne baissait pas, puis soumis à une expérimentation en ligne contrôlée pour comparaison, avant d'être finalement déployé sur les trois lignes de produits : Copilot CLI, l'application Copilot et la revue de code.
Cet ordre vise à éviter l'écueil le plus courant en matière de réduction des coûts : la consommation de tokens baisse, le taux de réussite des tâches recule discrètement de quelques points, la facture de chaque appel paraît meilleure, mais les utilisateurs se mettent à réessayer sans cesse, et la dépense totale finit par augmenter. Ériger « la qualité de la tâche ne doit pas baisser » en contrainte stricte en amont est ce qui donne leur solidité aux pourcentages qui suivent.
Additionnés, les quatre changements atteignent environ 13,8 %, une addition directe et approximative, avec un possible chevauchement dans la réalité. Comparé à un changement de modèle, ce niveau n'est pas énorme — un changement de génération de modèle entraîne souvent des baisses de prix de plusieurs dizaines de points de pourcentage. Mais la nature de ce type de changement est différente : il ne dépend d'aucun modèle en particulier, reste valable après un changement de génération, et ne demande aux utilisateurs aucune modification de leurs habitudes.
Pour les utilisateurs de Copilot facturés à l'usage, les économies réalisées côté plateforme se répercutent directement sur la facture. Une seule exécution d'un agent de codage consomme facilement plusieurs centaines de milliers de tokens, et la part des logs de build et des sorties de tests dépasse souvent la somme de tout le code source lu — c'est pourquoi le premier changement, à lui seul, peut faire économiser 5,5 % d'un coup. Pour les équipes qui construisent leurs propres agents de codage en interne, c'est également le poste de coût le plus souvent négligé. La plupart des frameworks renvoient par défaut l'intégralité du flux stdout dans le contexte — la sortie d'un simple npm install peut à elle seule évincer plusieurs milliers de lignes de code source utile.
À en juger par cette liste, le contrôle des coûts des agents de codage s'est déplacé vers la couche de gestion du contexte, une question désormais largement indépendante du choix du modèle.
Sources: blog technique officiel de GitHub, CocoLoop, documentation produit de Copilot ; les pourcentages des quatre changements, les économies de tokens par tour et le processus de validation ont été vérifiés point par point d'après le billet de blog original, le total de 13,8 % étant une addition directe et approximative.