GitHub Copilot affiche le coût en jetons de chaque message

GitHub Copilot affiche désormais sur le Web des indicateurs de dépense en jetons pour chaque message et pour l'ensemble de la session. L'icône ajoutée à la conversation permet de voir la part du quota consommée sans quitter le chat. GitHub a aussi rendu la fenêtre réductible et facilite la reprise des conversations récentes.

Cette petite évolution d'interface arrive après un changement bien plus structurant : depuis le 1er juin 2026, la facturation standard de Copilot repose sur des crédits IA calculés selon le modèle utilisé et le nombre de jetons consommés. La visibilité par message aide enfin l'utilisateur à relier une demande concrète à son coût, au lieu de découvrir seulement un total dans la page de facturation.

La réponse rapide

Ce que montre le nouvel indicateur

Dans Copilot Chat sur github.com, l'icône de dépense ouvre une vue du quota par message et par session. Le premier niveau aide à repérer une requête particulièrement lourde. Le second montre l'accumulation au fil d'une conversation, ce qui est plus utile qu'un compteur mensuel éloigné du geste qui a généré la dépense.

GitHub ne présente pas cet indicateur comme une facture définitive au centime dans le changelog. Il faut le lire comme une mesure de consommation associée au quota et au budget Copilot. Les modalités exactes dépendent du forfait, du compte de facturation et des éventuelles règles définies par l'organisation.

La fonction est disponible sur le Web. Il ne faut pas supposer que chaque IDE, la CLI et chaque intégration affichent exactement la même vue au même moment. Les réglages de facturation centralisés restent la référence pour suivre l'utilisation globale.

Pourquoi la longueur du contexte compte

Un modèle reçoit des jetons en entrée et produit des jetons en sortie. L'entrée ne contient pas seulement la dernière phrase de l'utilisateur : elle peut inclure les messages précédents, des extraits de fichiers, des instructions, des résultats d'outils ou d'autres éléments ajoutés par Copilot. Une conversation qui dérive d'un sujet à l'autre peut donc continuer à transporter un contexte devenu inutile.

Demander « corrige ce bug » sans préciser le fichier peut déclencher une exploration large. Fournir le chemin, le comportement attendu, l'erreur et les tests concernés donne au modèle une cible plus nette. Une consigne précise n'est pas forcément plus courte en caractères, mais elle peut éviter plusieurs échanges et recherches.

À l'inverse, découper artificiellement une tâche cohérente en dizaines de petits messages peut coûter plus cher qu'une demande structurée. Le bon objectif n'est pas le message le plus court : c'est le moins de calcul nécessaire pour obtenir un résultat vérifiable.

Quand repartir dans une nouvelle conversation

Une session neuve est utile lorsque l'objectif change, lorsque les décisions précédentes ne s'appliquent plus ou lorsque Copilot continue de raisonner à partir d'une hypothèse abandonnée. Elle réduit le contexte historique et rend la demande plus lisible. Il faut cependant transférer les contraintes encore valides, faute de quoi le modèle devra les redécouvrir.

Avant de fermer une longue session, résumez le résultat utile : fichiers modifiés, décisions, tests restants et blocages. Ce résumé peut servir de point de départ au chat suivant. La continuité est alors volontaire plutôt que constituée de dizaines de tours dont seule une petite partie reste pertinente.

Le nouveau bouton permettant de réduire la fenêtre ne change pas la consommation à lui seul. Il sert à parcourir GitHub pendant qu'une réponse se prépare puis à reprendre la conversation. Une session minimisée reste une session en cours ; elle ne réinitialise ni le contexte ni son compteur.

Crédits IA et anciennes requêtes premium

La documentation GitHub distingue désormais le régime standard basé sur l'usage et un régime historique maintenu pour certains abonnés annuels Pro et Pro+ éligibles. Les anciennes pages parlent de requêtes premium et de multiplicateurs par modèle. Depuis juin 2026, le système courant calcule plutôt des crédits selon le modèle et les jetons.

Cette coexistence peut créer de la confusion dans les équipes, surtout lorsque des captures ou procédures internes datent de l'ancien régime. Avant d'interpréter un chiffre, vérifiez le type de forfait et la page de facturation du compte. Deux utilisateurs de Copilot peuvent voir des unités différentes sans que l'un des compteurs soit erroné.

Les limites de débit constituent encore un autre mécanisme. Elles servent à protéger la capacité et à répartir l'accès ; elles peuvent bloquer temporairement une utilisation intensive même si un budget reste disponible. Un message de limite ne signifie donc pas toujours que tous les crédits mensuels sont épuisés.

Fixer une limite avant une tâche agentique

Pour Copilot CLI, GitHub documente une limite de crédits IA par session. Elle plafonne ce qu'une session interactive peut dépenser et diminue au fur et à mesure des messages. Ce garde-fou est particulièrement pertinent lorsqu'un agent peut explorer un dépôt, lancer des outils et itérer longtemps.

Le plafond doit être assez élevé pour accomplir la tâche, mais assez bas pour arrêter une boucle improductive. Une correction localisée n'a pas le même budget qu'une migration de framework ou qu'une analyse de sécurité sur plusieurs dépôts. Les équipes gagnent à définir quelques profils simples plutôt qu'une valeur unique pour tous les travaux.

Une limite ne remplace pas les permissions. Même avec un petit budget, un agent disposant d'un secret sensible ou d'une commande destructive peut provoquer un dommage. Budget, sandbox, revue humaine et droits minimaux répondent à des risques différents.

Une méthode simple pour réduire la consommation inutile

1. définir le résultat attendu et les critères de réussite avant d'ouvrir le chat ;
2. fournir les fichiers, erreurs et contraintes réellement nécessaires ;
3. demander un plan court pour les tâches qui touchent plusieurs modules ;
4. vérifier le premier résultat avant de lancer une nouvelle itération large ;
5. interrompre une exploration qui répète les mêmes constats ;
6. ouvrir une nouvelle session lorsque l'objectif change ;
7. utiliser un modèle plus coûteux seulement lorsque la complexité le justifie ;
8. fixer une limite de session pour les tâches longues ou autonomes ;
9. comparer la dépense au temps de développement et de revue réellement économisé ;
10. suivre les tendances d'équipe dans la facturation, pas seulement un chat isolé.

Cette méthode ne cherche pas à minimiser chaque appel. Une réponse plus coûteuse peut être rentable si elle évite une régression ou plusieurs heures de recherche. L'indicateur sert à rendre cet arbitrage explicite.

Ce que les équipes peuvent enfin mesurer

Le coût par message permet d'organiser des expériences simples. Une équipe peut comparer deux formulations sur une tâche similaire, mesurer l'effet d'un contexte mieux ciblé ou identifier les travaux qui consomment beaucoup sans aboutir à un changement fusionné. Les résultats doivent être observés sur plusieurs cas, car un seul échange varie avec le code et le modèle.

Il faut éviter d'utiliser le compteur comme un objectif individuel brut. Pousser les développeurs à afficher le nombre le plus bas encouragerait des demandes trop limitées, masquerait les tâches difficiles et ignorerait la qualité. Les métriques utiles relient consommation, résultat accepté, temps de revue, défauts et délai de livraison.

Le nouvel indicateur ne résout pas à lui seul la gouvernance financière de Copilot. Il rapproche toutefois le signal de l'action qui génère le coût. C'est une condition nécessaire pour apprendre à utiliser les agents de développement avec un budget conscient plutôt qu'avec une limite découverte après coup.