Réduire la facture des agents IA de 60 % : la méthode GitHub

GitHub a publié le 7 mai 2026 un retour d'expérience inhabituel pour un blog d'éditeur d'outil : Landon Cox et Mara Kiefer, chercheurs Microsoft Research, détaillent leur méthode pour réduire la consommation de tokens de leurs agents tournant en CI sur leurs propres dépôts. Les chiffres communiqués sont concrets : −62 % sur Auto-Triage Issues, −79 % sur Smoke Claude quand on combine plusieurs leviers.

Pour toute équipe qui vient de découvrir avec le passage de Copilot au paiement à l'usage que les coûts d'agents IA en CI ne sont plus invisibles, c'est le manuel pratique attendu. On déballe les cinq leviers que GitHub applique en interne et qu'on peut transposer dès la semaine prochaine sur n'importe quel pipeline agentique.

Le contexte : pourquoi les agents en CI dérivent

Les GitHub Agentic Workflows — les pipelines automatisés qui tournent à chaque pull request pour faire du triage, de la doc, du quality check, de la security review — ont la particularité d'exécuter le même travail à chaque fois, contrairement à une session interactive. Cette régularité les rend prévisibles, donc instrumentables, donc optimisables.

Mais cette même régularité fait grimper la facture en silence. Un workflow qui tourne 7 fois par jour à 50 000 tokens par run, c'est 10,5 millions de tokens par mois pour un seul workflow. Multipliez par 8 agents en CI, et vous êtes à 84 M tokens/mois — soit 84 $ chez Claude Sonnet, 420 $ chez Opus, et personne ne le voit dans le dashboard de coûts parce que c'est noyé dans le forfait.

Le passage à l'usage qui touche Copilot, mais aussi les API Claude et OpenAI, change le rapport au bruit : maintenant, chaque token gaspillé a un coût marginal lisible.

Le métrique Effective Tokens : comparer comparable

Avant d'optimiser, il faut mesurer correctement. GitHub définit une métrique unifiée appelée Effective Tokens (ET) qui pondère les tokens selon leur coût réel :

ET = m × (1.0 × I + 0.1 × C + 4.0 × O)

Où m est le multiplicateur du modèle (Haiku 0.25, Sonnet 1.0, Opus 5.0), I les tokens d'input frais, C les tokens lus depuis le cache, et O les tokens d'output. Pourquoi ces poids ? Parce que les outputs sont typiquement 4× plus chers que les inputs chez tous les fournisseurs majeurs, et que les cache reads sont facturés à 10 % du prix d'un input frais.

L'intérêt d'ET, c'est qu'il permet de comparer un workflow avant/après changement de modèle, un workflow A vs B, ou l'évolution d'un workflow dans le temps. Sans ce dénominateur commun, vous comparez des pommes et des poires.

Les cinq leviers concrets

Levier 1 — Logger avant d'optimiser

GitHub recommande un proxy API qui capture chaque appel modèle dans un fichier token-usage.jsonl standardisé. Une ligne par appel avec : tokens d'input, output, cache-read, cache-write, modèle, timestamp. Cette instrumentation est indépendante du framework agentique (Claude CLI, Copilot CLI, Codex CLI) et fournit la vue historique nécessaire à toute décision.

Cox et Kiefer sont catégoriques : "Add the API proxy, turn on logging, and let the data tell you where to look." Sans cette base, vous optimisez à l'aveugle. Avec, vous identifiez le top 3 des workflows gourmands et vous concentrez l'effort là où c'est rentable.

Côté outillage : gh extensions install github/gh-aw puis gh aw add githubnext/agentic-ops/copilot-token-audit copilot-token-optimizer ajoutent deux workflows automatisés — un auditeur quotidien qui agrège la consommation et un optimiseur qui ouvre des Issues GitHub avec des propositions concrètes d'optimisation.

Levier 2 — Élaguer les outils MCP inutilisés

Le MCP (Model Context Protocol) standardise la déclaration d'outils accessibles à un agent. Mais chaque outil déclaré envoie son schéma JSON dans le contexte de chaque appel. Le serveur MCP GitHub fournit 40 outils par défaut ; ça se traduit par 10 à 15 Ko de schéma envoyés à chaque tour, même si l'agent n'utilise que 2 outils sur les 40.

L'audit est mécanique : croiser le manifest des outils déclarés avec les tool calls effectivement réalisés sur les derniers runs. Désactiver tout ce qui n'est jamais appelé. GitHub rapporte que cet élagage réduit le contexte par appel de 8 à 12 Ko, soit plusieurs milliers de tokens par run sans aucun changement de comportement.

Cas extrême documenté : sur le workflow Glossary Maintainer, un seul outil (search_repositories) avait été appelé 342 fois dans un seul run, ce qui représentait 58 % de tous les tool calls. Identifier ce hot-spot a permis de remplacer la stratégie d'agent et de descendre la consommation drastiquement.

Levier 3 — Remplacer les MCP par le GitHub CLI quand on peut

Un appel d'outil MCP est un round-trip LLM complet : l'agent doit décider d'appeler l'outil, formuler les arguments, recevoir la réponse, l'interpréter. Trois étapes facturées en tokens. À l'inverse, un gh pr diff est une requête HTTP déterministe sans aucun LLM impliqué.

Deux patterns concrets :

Pre-agentic data download : avant que l'agent démarre, des steps GitHub Actions exécutent les gh commands nécessaires et écrivent les résultats dans des fichiers du workspace. L'agent les lit comme du contexte au lieu de les fetcher via MCP.

CLI proxy in-agent : un proxy HTTP léger redirige les appels CLI vers l'API GitHub sans exposer les tokens d'authentification à l'agent. L'agent voit juste un endpoint local.

Le mantra des auteurs : "The cheapest LLM call is the one you don't make." Pour tout flux où la donnée à récupérer est déterministe, sortez-la de la boucle agentique.

Levier 4 — Choisir le modèle par task

Pas tous les workflows nécessitent Claude Opus 4.7. Un agent qui formate un message de log peut tourner sur Haiku, qui coûte environ 4× moins cher par token que Sonnet. Le profil de qualité reste largement suffisant pour des tâches "transformer A en B" simples.

Le combo gagnant documenté : Smoke Claude dans le repo gh-aw-firewall a vu sa consommation chuter de 79 % en combinant pruning MCP agressif et switch vers Haiku. Le trade-off qualité a été surveillé via des process signals (output tokens par appel, taux de complétion des tool calls), pas via une mesure de "correctness" directe — ce qui pose une question méthodologique qu'on traite plus bas.

Levier 5 — Les portes de pertinence

Le levier le plus radical : skipper le LLM entièrement quand la condition d'utilité n'est pas remplie. Le workflow Security Guard ne lance plus son agent que sur les PR qui modifient des fichiers du périmètre sécurité ; pour les autres, il sort en quelques millisecondes sans dépenser un token. Résultat : −43 % d'ET sur l'agrégat.

Cette logique se généralise. Tout workflow agentique devrait avoir une porte conditionnelle en début d'exécution qui répond à la question "est-ce que ce run a une chance d'être utile ?". Quand la réponse est "non avec haute probabilité", on coupe.

Le piège : mesurer la vraie efficacité

Trois facteurs confondants empêchent une lecture naïve des gains :

Modèles différents = coûts par token différents. Sans la métrique ET, switch de modèle et optimisation token sont indistinguables.

Workload variable. Le workflow Contribution Check a montré une augmentation de 5 % d'ET après optimisation — non parce que l'optimisation a échoué, mais parce que la période post-fix coïncidait avec un shift vers des PR plus grosses (65 % de gros PR vs 41 % avant). L'optimisation marchait mais était masquée par le contexte.

Pas de ground-truth de qualité. Personne ne peut mesurer si un agent "a fait le bon travail" sur des tâches ouvertes. Les process signals (output tokens, tour count, taux de tool call complétés) approximent la qualité mais ne la mesurent pas. L'aveu honnête de Cox et Kiefer : "Measuring tokens-per-unit-of-correct-work requires additional instrumentation and thought."

Ce que ça change pour les équipes IA

Trois implications concrètes pour qui pilote des agents en production :

1. L'observabilité agentique est non-négociable. Avant tout effort d'optimisation, l'instrumentation. Sans token-usage.jsonl ou équivalent, vous ne savez pas où regarder. C'est exactement la même logique que les exigences de l'AI Act sur le logging d'événements — la base technique est commune, l'usage diffère.

2. Le portfolio prime sur la pièce. Run frequency × per-run savings est la métrique qui compte. Auto-Triage Issues à 6,8 runs/jour avec −62 % a généré l'économie la plus élevée du portfolio GitHub (~7,8M ET sur la période d'observation). Optimiser un workflow rare à fort volume par run rapporte moins qu'un workflow fréquent à volume moyen.

3. Les recommandations LLM sur l'optimisation sont à instrumenter, pas à appliquer aveuglément. L'optimiseur quotidien que GitHub déploie ouvre des Issues avec des propositions ; toutes ne se traduisent pas en gains mesurables. Sur une fenêtre courte, le bruit du workload masque les améliorations. Disposition pratique : appliquer les optimisations, mais regarder l'ET sur 4 à 6 semaines avant de conclure.

Pour une équipe qui vient de brancher 3 ou 4 agents sur sa CI, l'ordre des opérations est lisible : ajoutez le proxy de logs (J), faites un audit MCP (J+5), introduisez les portes de pertinence (J+10), expérimentez les switch de modèle sur les workflows non-critiques (J+15). Trois semaines pour viser un −40 % structurel sans toucher à la qualité, c'est réaliste.

En bref

• GitHub publie le 7 mai 2026 un retour d'expérience interne sur l'optimisation token de ses agents CI : −62 % sur Auto-Triage, jusqu'à −79 % en cumulé
• Métrique Effective Tokens : ET = m × (1.0×I + 0.1×C + 4.0×O) pour comparer comparable through models
• 5 leviers : 1) logger avant d'optimiser via API proxy, 2) élaguer outils MCP inutilisés, 3) remplacer MCP par GitHub CLI quand l'appel est déterministe, 4) switch modèle par task (Haiku ~4× moins cher que Sonnet), 5) portes de pertinence pour skipper le LLM
• Pièges : workload shift, absence de ground-truth qualité, modèles non comparables sans ET
• Ordre pratique : observabilité (J) → audit MCP (J+5) → relevance gates (J+10) → model switch (J+15). Cible réaliste −40 % structurel en 3 semaines.

Vous industrialisez vos agents IA ? SeedVision propose des audits IA en 3-5 jours et des forfaits de mise en production de 15 à 30 jours. Voir les packages ou réserver un appel de 30 min.

Photo de couverture : Photo by 1981 Digital on Unsplash.