324 millions de tokens relus pour 3 millions écrits : ce que coûte une session d'agents

Je suis développeur web. Je lis des livres techniques et j'en tire des fiches de lecture, des résumés publiés dans la bibliothèque de ce site. Je les fais avec Claude, mais pas un seul. J'utilise une petite équipe d'agents : des Claude qui ont chacun un rôle, comme lire, rédiger ou relire. Chaque agent consomme des tokens, les morceaux de mots que Claude lit et écrit. C'est ce qui vide mon abonnement.

Mes deux premières fiches, courtes, écrites avant ces mesures, ont consommé 4,1 millions de tokens d'agents. Cela fait environ 360 tokens pour chaque mot que le lecteur finit par lire. Je voulais savoir ce que je pouvais couper sans abîmer la qualité. J'ai donc mesuré quatre fiches de plus, étape par étape. Résultat : deux choses ont fait baisser la facture. La première est un script, un petit programme ordinaire sans intelligence artificielle, placé avant un agent. La seconde est de relancer le même agent après une correction : il reprend où il s'était arrêté, au lieu de tout recommencer. Abréger les notes que prennent les agents qui lisent le livre a réduit le total de 12 %, mais n'a rien gagné par mot publié. Un troisième script, celui qui vérifie les citations, n'entre pas dans ce décompte : je n'ai pas mesuré son gain.

$ git clone https://github.com/ohugonnot/citecheck
$ cd citecheck && ./demo.sh

Comment une fiche est écrite, puis notée

Une fiche de lecture résume un livre technique en quelques minutes de lecture. Des agents Claude l'écrivent, mais jamais seuls : l'agent qui rédige n'est pas celui qui juge. Un auteur relit ce qu'il a voulu écrire, pas ce qu'il a écrit (Aucun agent ne corrige sa propre copie).

Le relecteur compare la fiche au texte du livre et donne une note sur 100. Une partie, la fidélité, vaut 25 points : exemples réels, citations exactes, rien d'inventé. Sous 20 sur 25, la fiche repart en correction, quelle que soit la note totale : un 19/25 est refusé même avec 90 sur 100. Pour sortir, il faut aussi 85 sur 100 au total, fidélité comprise. Je laisse trois tours au relecteur, un Claude de taille moyenne appelé Sonnet. Une relecture finale passe ensuite par le plus grand, Opus.

Ce que la consommation montre vraiment

Claude Code, l'outil avec lequel je lance mes agents, a une commande, /usage, qui affiche ce qu'une session a consommé. Je l'ai lancée après sept heures de travail. Elle indiquait 107 dollars et 14 %. Les 107 dollars sont un montant calculé par l'outil, pas une facture : je paie un forfait mensuel. Les 14 % sont la part de mon quota de la semaine déjà utilisée. Cet abonnement a une limite hebdomadaire, comme un forfait de minutes.

Le relevé contenait aussi un chiffre bizarre : 323,7 millions de tokens relus, pour seulement 2,9 millions de tokens de texte produit. Un token est un petit morceau de mot, l'unité dans laquelle Claude lit et écrit. « Relus » veut dire lus de nouveau par un agent, en plein travail. Mes agents ont donc relu plus de cent fois ce qu'ils ont écrit.

Pourquoi autant de relectures ? Un agent travaille en demandant à des outils d'agir : ouvrir un fichier, lancer un programme. Chaque demande à un outil s'appelle un appel. L'agent ne garde aucun souvenir de lui-même d'un appel à l'autre.

Pour qu'il suive le fil, on lui renvoie donc à chaque appel toute la conversation depuis le début. Cette conversation s'appelle son contexte. Imagine un collègue qui doit relire tout son cahier depuis la première page avant d'écrire chaque nouvelle ligne. Plus le cahier grossit, plus chaque ligne coûte de lecture.

Le cache garde le début de la conversation prêt à être réutilisé (documentation Anthropic). Une relecture en cache coûte moins cher qu'une lecture neuve, mais pas rien. Elle figure toujours dans le relevé, et il y en a 323,7 millions.

Le relevé ne détaille pas les 107 dollars. Je ne peux donc pas dire quelle part vient des relectures. Elles sont cent fois plus nombreuses que le texte écrit : j'en déduis que le poids vient surtout d'elles. C'est une déduction, pas une mesure.

Deux précautions. D'abord, ce relevé couvre toute ma session, pas une fiche seule. Ensuite, mes agents me rendent leurs propres compteurs de tokens, ceux du reste de l'article. Ils comptent eux aussi ce contexte relu. Ils ne correspondent pas à ce que mon abonnement a décompté.

J'ai relancé /usage après la dernière des quatre fiches. Entre les deux relevés, j'ai aussi lu les schémas d'un autre livre, construit le dépôt de cet article et écrit son premier jet. Le coût affiché est passé de 107,05 à 120,96 dollars, soit 13,91 de plus pour 1 h 07 de travail. La semaine est passée de 14 % à 15 % : environ un point, l'affichage ne donne pas plus fin.

La chaîne, étape par étape

Claude existe en trois tailles. Haiku, la plus petite, est la moins chère par token. Sonnet, de taille moyenne, fait presque tout. Opus, la plus grande, est la plus chère. Pour chaque agent, je donne la taille qu'il a utilisée.

Une fiche passe par une dizaine d'agents, dans cet ordre :

• un agent de plan (Sonnet pendant ces mesures, Opus depuis) choisit les chapitres à lire et les idées clés à garder ;
• trois lecteurs (Sonnet) lisent ces chapitres du livre et prennent des notes ;
• un rédacteur (Sonnet) écrit la fiche à partir des notes ;
• un lecteur novice (Haiku) signale tout ce qu'un développeur qui n'a pas lu le livre ne comprend pas ;
• un correcteur (Sonnet) applique son rapport et modifie le texte ;
• un relecteur (Sonnet) relit la fiche sans la modifier : il vérifie chaque affirmation dans le livre, et quelques faits sur internet ;
• si le relecteur trouve des défauts, le correcteur et lui repassent pour un second tour ;
• un traducteur (Haiku), puis un agent (Sonnet) qui fabrique la page web ;
• enfin, quand il reste des défauts de style, une relecture finale par Opus, que je n'ai pas lancée sur les deux dernières fiches.

Entre eux, il y a des scripts. Un script n'est pas un agent : il ne consomme aucun token. L'un d'eux contrôle les citations, ces passages du livre recopiés entre guillemets dans la fiche, avant chaque relecture.

Voici les quatre fiches mesurées côte à côte. Dans le tableau, « M » veut dire million. Les deux premières lignes sont deux fiches en ligne, pas les deux fiches courtes du début : Event-Driven Architecture in Golang et Observability Engineering. La quatrième, Building Secure and Reliable Systems (Heather Adkins et al., Google et O'Reilly, 2020, gratuit en ligne), a coûté 1,42 million de tokens d'agents. « Lecture » compte les tokens pour lire le livre et prendre des notes. « Premier jet » compte ceux de la première version du texte. « Fidélité » est la note sur 25 expliquée plus haut. La troisième, Serious Cryptography, est un livre d'Aumasson sur la cryptographie.

Les deux fiches courtes du début coûtaient environ 360 tokens par mot publié. À lire avec prudence : quatre livres différents, une seule mesure par fiche. Ce sont des ordres de grandeur, pas une moyenne.

Ce qui a payé : le script passe avant l'agent

Premier gain : le choix de ce qu'il faut lire. Avant de lire un livre, il faut décider quelles idées garder et quelles parties lire. C'est le travail de l'agent de plan, vu dans la liste plus haut. Mon ancienne méthode le faisait en deux passes. La première, un coup d'œil appelé pré-tri, coûtait 93 700 tokens. La seconde, une analyse plus complète appelée tri, en coûtait 109 900. Cela faisait 203 600 tokens. J'avais prévu 25 000 pour le pré-tri. Pourquoi autant ? À chaque appel, l'agent relisait l'index de la bibliothèque du site. L'index est la liste de toutes les fiches déjà publiées : l'agent s'en servait pour savoir lesquelles existent déjà. Comme il relit tout à chaque appel, cet index coûtait cher.

Un script fait maintenant cet index en une seconde, et un autre dresse la carte du livre, une ligne par chapitre. Un seul agent, le plan, choisit à partir de ces deux listes. Il coûte 81 600 tokens sur la troisième fiche, 68 300 sur la quatrième, mesurés sur Sonnet. Je l'ai depuis passé sur Opus, plus cher par token. C'est lui qui décide ce que la fiche contiendra : une idée qu'il oublie, aucune relecture ne la rattrape. Je n'ai pas encore mesuré ce que cela coûte.

Deuxième gain : quand le relecteur trouve des défauts, je ne lance pas un nouvel agent. Je relance le même, avec la liste exacte des défauts. Il reprend la même conversation : ce qu'il a déjà lu y est. Il ne regarde que ce qui a changé depuis son premier passage. Un nouvel agent devrait tout relire depuis zéro, le livre compris. Sur la quatrième fiche, le correcteur a coûté 30 700 tokens au second tour, contre 169 100 au premier. Le relecteur : 21 700 contre 174 200.

Troisième ajout, dont je n'ai pas mesuré le gain : un script lit les citations avant le relecteur. Il ne juge que ce qui est entre guillemets. Dans une fiche, une citation est suivie d'un renvoi, par exemple « (chapitre 3) ». Le script cherche la citation dans le texte complet du livre, à l'endroit annoncé. Il attrape trois sortes de fautes que mes relecteurs relevaient jusque-là eux-mêmes. Une citation est légèrement réécrite. Une autre est rattachée au mauvais chapitre. Un renvoi vise un chapitre qui n'existe pas. Il ne coûte aucun token. Voici ce qu'il répond, sans sa ligne d'en-tête, sur une fiche volontairement fausse, écrite pour un livre inventé pour le dépôt. Ce livre est en anglais, d'où les citations anglaises. Dans sa sortie, « leçon » et « unité » veulent dire chapitre.

ECHEC  l.7 (lesson 9) : leçon 9 n'existe pas dans la source
ECHEC  l.3 (lesson 1) : introuvable « 99 to 100 percent »
MAUVAISE-UNITE l.5 (lesson 3) : « dirty lines are a debt, not a gift » est en leçon [2]
a-verifier l.3 (lesson 1) : nombre 300 absent de l'unité citée | …. A miss to main memory costs about 300 cycles against 4 for a hit
RESULTAT : ECHEC (3 échec(s), 1 nombre(s) à relire)

• ECHEC, l.3 (ligne 3 de la fiche) : la citation « 99 to 100 percent » n'est pas dans le livre. Je l'avais modifiée.
• MAUVAISE-UNITE : la citation existe, mais dans la leçon 2, pas la 3.
• ECHEC, ligne 7 : la fiche cite la leçon 9, et le livre n'en a que trois.
• a-verifier : le chiffre 300 n'est pas dans le livre. C'est un avertissement à relire, pas un refus.

Fichier complet : examples/summary-bad.md, lignes 3 à 7

Il ne refuse jamais un chiffre absent du livre, car la fiche a pu le calculer.

Le script ne juge pourtant que ce qui est entre guillemets. Or le relecteur de la quatrième fiche a trouvé cinq erreurs de fait, et aucune n'était une citation du livre. La phrase d'accroche de la fiche disait le livre « muet sur l'IA », alors qu'il a une section sur l'IA au chapitre 2. Une idée parlait du « nombre d'équipes touchées », alors que le livre parle de dépendances, pas d'équipes. Sur ces erreurs, le script restait muet, et la fiche était fausse.

Ce que j'ai mal économisé

Sur la troisième fiche, les trois lecteurs avaient rendu 23 800 mots de notes. Sur la quatrième, j'ai plafonné les notes à 450 mots par idée : 4 322 mots en tout. Dans le tableau, la lecture coûte 37 % de moins. Le premier jet, la première version du texte, coûte 41 % de moins pour 18 % de mots en moins. Un gain, en apparence.

Mais le relecteur lui a donné 19 sur 25. En dessous de 20, je la fais corriger avant de la publier. Le rédacteur avait reformulé des détails au jugé, faute de notes assez fournies. Après correction : 23/25. Au total, la quatrième fiche coûte 12 % de moins que la troisième. Par mot publié, aucun gain : 209 tokens pour la quatrième, 199 pour la troisième. J'ai déplacé du travail des lecteurs vers le relecteur, je ne l'ai pas supprimé.

Autre choix de modèle : Haiku, le plus petit des trois, a un token bien moins cher. Son total de tokens ne dit donc presque rien de son coût. Mon lecteur novice sur Haiku a trouvé 3 des 4 passages obscurs repérés ensuite par le relecteur. Le traducteur sur Haiku a passé mes contrôles, avec 18 % de tokens en plus par mot que Sonnet. Entre mes deux relevés, tout Haiku a pesé 0,37 dollar, contre 13,54 dollars pour Sonnet. Pour ces deux tâches, il vaut le coup.

Mon avis : ce que je referais

Mon avis : plafonner les notes des lecteurs baisse le total de 12 %, sans rien gagner par mot publié. Faute de notes, le rédacteur n'a plus de quoi vérifier. Je garde le plafond, avec une règle en plus, à tester. Chaque chiffre et chaque affirmation attribuée au livre garde sa citation dans les notes, même si le reste est court.

Les économies solides sont celles que j'ai mesurées. Il y a l'index fait par script, qui a ramené le choix de la lecture de 203 600 à 81 600 puis 68 300 tokens. Il y a aussi le second tour du même agent. La vérification des citations ne coûte rien, mais je n'ai pas mesuré ce qu'elle fait gagner. Je réserve désormais le relecteur aux affirmations sans guillemets, les seules que le script ne voit pas. Je n'ai pas lancé la relecture finale par Opus sur les deux dernières fiches. Après le second tour, le relecteur ne signalait plus aucun défaut de style à confier à Opus. Je ne sais pas encore si ces deux fiches y perdent en qualité.

Conclusion

J'ai écrit un script pour attraper les citations que mes agents réécrivent ou rattachent au mauvais chapitre. Il fait son travail, et il ne coûte rien. Sur la quatrième fiche, les erreurs que mon relecteur a trouvées, elles, n'étaient pas dans les guillemets. Mon script m'a surtout appris où s'arrête ce qu'un simple programme vérifie seul. Au-delà, il faut qu'un agent, ou moi, relise le livre.

Sources

Mesures du 3 novembre 2026 :

• Documentation consultée le 3 novembre 2026 : coûts dans Claude Code (la commande /usage) et le cache (« prompt caching »).
• Le code et les tests : dépôt citecheck, version figée du code (commit e875dd3).
• Les deux fiches du tableau déjà en ligne : Event-Driven Architecture in Golang et Observability Engineering.
• Les chiffres de tokens viennent des rapports des agents de ma session. Les dollars et les pourcentages viennent de la commande /usage, relevée deux fois le même jour.