Une session Claude Code ne ressemble pas à une requête de chat, et un facteur « par requête » ne dit rien d'utile sur elle. Sur une session type, 50 000 tokens d'entrée, 200 000 d'écriture de cache, 3 millions de lecture de cache et 30 000 générés sur Sonnet 5, l'équation de la méthodologie donne 134 Wh d'énergie serveur, 49,8 gCO₂e et 797 mL d'eau. Environ 350 mètres en voiture thermique, fabrication comprise. Ce qui compte n'est pas ce chiffre, c'est sa composition : dans un usage agentique, plus de 90 % des tokens traités sont du contexte relu, et pourtant ce ne sont pas eux qui pèsent le plus.
Une session n'est pas une requête
Claude Code empile quatre types de tokens, que le produit compte séparément : l'entrée fraîche, l'écriture de cache, la lecture de cache et la sortie générée. Les proportions n'ont rien à voir avec celles d'une conversation. Sur la trace publique TraceLab (2 676 sessions Claude Code, 37 développeurs, arXiv 2606.30560v2), ramenée à un million de tokens générés, on compte environ 4,8 millions de tokens d'entrée fraîche, 19,3 millions d'écriture de cache et 269,7 millions de lecture de cache. Soit 270 tokens relus du cache pour chaque token généré, et 91,5 % du volume total lu depuis le cache. La même source situe la médiane d'un pas de session à 126 180 tokens.
C'est la conséquence directe du fonctionnement d'un agent : à chaque tour, l'historique et les fichiers ouverts repartent en contexte. Un facteur calibré sur une requête de chat, où l'entrée tient en quelques centaines de tokens, ne transpose pas.
Où part l'énergie dans une session
Reprenons la session type ci-dessus, décomposée :
| Poste | Volume | Énergie | Part |
|---|---|---|---|
| Entrée fraîche et écriture de cache | 250 000 tokens | 29,8 Wh | 22 % |
| Lecture de cache | 3 000 000 tokens | 28,6 Wh | 21 % |
| Tokens générés | 30 000 tokens | 75,8 Wh | 57 % |
Les 30 000 tokens générés pèsent plus lourd que les 3,25 millions de tokens de contexte réunis. La raison tient au ratio des facteurs : sur Claude, un token de sortie coûte environ 21 fois l'énergie d'un token d'entrée, ratio récupéré du fit sur la source primaire et non posé par convention. Générer est cher, relire est bon marché, et un contexte long pèse moins qu'on ne le croit tant qu'il passe par le cache.
Conséquence pour agir : ce qui fait baisser l'empreinte d'une session, c'est ce qui réduit les tokens générés inutilement, pas la chasse au contexte. Les leviers côté facture sont voisins mais pas identiques, ils sont détaillés dans réduire la facture Claude Code.
Le cache coupe l'énergie, il ne l'annule pas
Un token relu du cache est un token dont le prefill a déjà été payé. Notre équation lui applique 8 % de l'énergie d'un token d'entrée frais, valeur bornée entre 0,05 et 0,20 dans la méthodologie. Ce facteur n'est pas le ratio de facturation d'Anthropic, qui est un prix et non une mesure d'énergie.
Une réserve, écrite plutôt que tue : ce terme capture le résidu de prefill, pas la relecture du cache pendant le décodage. Or chaque token généré relit l'intégralité du cache depuis la mémoire, ce que la littérature documente sans ambiguïté (GreenCache, SIGMETRICS). Ce coût est aujourd'hui absorbé dans un facteur de sortie supposé constant, calibré sur des contextes vraisemblablement courts. En régime de contexte long, donc précisément en usage agentique, notre chiffre sous-estime ce poste. Le correctif n'est pas une nouvelle constante mais une nouvelle forme d'équation, avec un terme fonction de la longueur de contexte.
Le modèle décide plus que le volume
Les facteurs d'énergie de la gamme Claude s'étalent sur un facteur huit, de Haiku à Fable. La session type ci-dessus, à volumes strictement identiques, donne 25 gCO₂e sur Haiku, 50 sur Sonnet, 100 sur Opus et 199 sur Fable. Un routage par défaut vers le modèle le plus lourd multiplie donc l'empreinte d'une équipe sans que personne n'écrive une ligne de plus. La répartition réelle de vos tokens par modèle est le premier chiffre à sortir, avant toute discussion sur les volumes. Les facteurs par famille et leurs niveaux de confiance sont détaillés dans l'empreinte carbone de Claude.
Mesurer sans compter deux fois
Trois chemins existent, et ils ne voient pas la même chose. Le plugin open source claude-carbon lit les transcripts locaux et calcule sur le poste, sans rien envoyer. Le CLI TokenClimate mesure les mêmes sessions et les pousse vers le dashboard, la commande tokenclimate org status affichant les valeurs locales avant envoi. Le Bilan part d'une clé Admin API en lecture seule et remonte jusqu'à douze mois via l'Usage & Cost API et la Claude Code Analytics API, sièges Team et Enterprise compris.
Le piège est le double comptage, et il est plus fréquent qu'on ne l'imagine. Les sessions reprises ou compactées rejouent les messages précédents dans le même fichier, et le streaming réécrit le même message plusieurs fois avec un compteur de sortie croissant : une somme brute des transcripts sur-compte d'environ trois fois. La déduplication se fait par identifiant de message et de requête, en gardant la dernière occurrence. Quand plusieurs sources couvrent le même usage, les recouvrements sont soustraits par réconciliation, au jour, au membre et à la famille de modèle.
Ce que la mesure ne voit pas est écrit noir sur blanc : le chat claude.ai et Claude Cowork sous plan Team n'exposent aucune API, ils sont déclarés hors périmètre plutôt qu'estimés.
FAQ
Combien de CO₂e pour une session Claude Code ?
Environ 50 gCO₂e pour une session Sonnet 5 de 30 000 tokens générés avec 3,25 millions de tokens de contexte, avec les facteurs de notre méthodologie. La même session sur Opus double le chiffre, sur Haiku le divise par deux. Un chiffre par session n'a de sens qu'accompagné du modèle et des volumes des quatre classes de tokens.
Le cache réduit-il l'empreinte carbone ?
Il la réduit, il ne l'annule pas. Un token relu compte pour 8 % de l'énergie d'un token d'entrée frais dans notre équation. Et cette valeur ne couvre que le prefill évité : la relecture du cache pendant la génération reste payée, absorbée aujourd'hui dans le facteur de sortie, ce qui nous fait sous-estimer les très longs contextes.
Pourquoi mon chiffre diffère-t-il de celui d'un collègue à usage comparable ?
Presque toujours à cause du mix de modèles, ensuite à cause du ratio entre tokens générés et contexte relu. Deux personnes qui écrivent le même nombre de lignes mais l'une sur Opus et l'autre sur Haiku sont séparées par un facteur quatre, à volumes identiques.
Faut-il compter les sessions reprises ou compactées ?
Une seule fois. Un transcript rejoue les messages précédents quand la session reprend ou se compacte, et une somme brute sur-compte d'environ trois fois. Tout outil sérieux déduplique par identifiant de message avant de sommer ; si le vôtre ne le documente pas, vérifiez-le avant de publier un chiffre.
Sources
- Méthodologie TokenClimate : équation, facteurs de cache et déduplication
- TraceLab, trace publique de sessions Claude Code, arXiv 2606.30560v2
- GreenCache, énergie du KV cache en phase de décodage, arXiv 2505.23970
- Irminsul, mesure directe du rapport hit/miss de prefill, arXiv 2605.05696
- Impact CO₂ (ADEME), 142 gCO₂e par kilomètre pour une voiture thermique, fabrication comprise
- claude-carbon, plugin open source de mesure locale des sessions Claude Code