Mesurer son propre usage de l'IA : trois compteurs, trois réponses différentes

TL;DR

Je pense que les abonnements forfaitaires aux agents sont tarifés en dessous de ce que coûte un usage intensif. Le signal que je surveille est le quota, pas le dollar : quand les quotas se resserrent à prix inchangé, j’y vois une hausse des prix pratiqués par les laboratoires. Je m’attends à ce que cette pression continue jusqu’à la fin de 2027.

Sujet	Chiffre	Statut
Volume des deux outils, 20 jours, une machine	38,97 milliards de tokens	ccusage, recoupé avec mon propre recomptage à moins de 1 %
Part de ce volume correspondant aux lectures de cache	94,8 % sur Claude Code, 96,1 % sur Codex	Même source
Tokens représentant du travail nouveau (entrée + écriture de cache + sortie)	1,75 milliard, soit un rapport de 22:1 avec le chiffre principal	Même source
Prix équivalent API de ces 20 jours	24 351 $	Tarifs publics appliqués par ccusage, pas une facture. Je paie quatre abonnements forfaitaires
Plafond de quota Codex sur 7 jours	100 % atteint 6 jours sur 20, 90 % ou plus sur 11	Lu dans le champ used_percent que Codex écrit dans ses propres fichiers de session
Scan brut des mêmes transcriptions, sans déduplication	Surcompte de 87 %	Mesuré par rapport à ccusage sur la même fenêtre
Filtrage des sorties de commandes shell par rtk	Réduction de 63,9 %, sur 7,4 % des nouveaux tokens de Claude	Historique SQLite de rtk, même fenêtre

Tous les articles de cette série jusqu’ici citaient les chiffres de quelqu’un d’autre. Celui-ci cite les miens, parce que je voulais savoir ce qui se passe quand on essaie de mesurer soigneusement son propre usage, et la réponse s’est révélée plus intéressante que le total.

J’utilise Claude Code et Codex côte à côte sur un Mac, avec quatre abonnements forfaitaires. Trois outils prétendent m’indiquer ce que cela consomme.

Ils divergent d’un facteur trois. Déterminer auquel me fier a pris plus de temps que de construire le pipeline d’export qui alimente maintenant cet article, et la leçon tient aux raisons de ces écarts.

Trois compteurs, trois définitions

• rtkSorties CLI filtrées.
  Compression dans ce périmètre, pas usage total du modèle.
• ccboardCache de statistiques et analyse des transcriptions.
  La fraîcheur et la définition des sessions comptent.
• ccusageUsage dédupliqué des transcriptions.
  Les tarifs publiés des tokens donnent un équivalent API, pas une facture.

Le premier compteur est rtk, un proxy que j’utilise pour compresser les sorties de commandes avant qu’elles atteignent le modèle. Transparence : j’ai contribué à RTK.

Mise à jour du 6 novembre 2026. Je ne contribue plus activement au code de RTK, mais je suis toujours le projet de près. Pour les politiques d’usage et la visibilité à l’échelle d’une équipe, vous pouvez découvrir RTK Pro. Cette offre est distincte du CLI mesuré ici. Ces mesures n’évaluent pas Pro et ne démontrent pas d’économies liées à cette offre.

Il rapporte une réduction d’environ 64 % et dit vrai, sur son propre territoire : 66 342 commandes filtrées en vingt jours, 66,7 millions de tokens de sorties shell ramenés à 24,1 millions.

Ce territoire est étroit. Ces 66,7 millions de tokens représentent 7,4 % des nouveaux tokens consommés par Claude Code sur la même fenêtre, et les 42,7 millions économisés représentent environ un dixième de pour cent du volume total.

rtk est redoutable sur les sorties CLI, et c’est précisément sa limite : les sorties shell sont une petite part de ce que le modèle consomme, donc les filtrer n’est pas un levier sur votre facture.

Sur son périmètre global, plus large que ces 20 jours, rtk gain lu le 1er octobre 2026 donne 240 576 commandes, 574,1 millions de tokens de sorties CLI en entrée, 171,0 millions en sortie et 403,2 millions économisés (70,2 %). Les économies les plus importantes viennent de rtk grep avec 150,7 millions économisés (79,3 %), rtk read avec 148,6 millions (75,5 %), rtk vitest run avec 47,0 millions (99,4 %) et rtk find avec 21,2 millions (99,0 %).

Ce sont les propres comptes de tokens de sorties CLI de rtk, pas ma facture totale.

Relu le 2 octobre 2026 avec rtk gain --all, le total est de 242 025 commandes, 592,0 millions en entrée et 421,2 millions économisés (71,2 %), mais le taux varie beaucoup : 71,7 % en juillet, 47,9 % en août et 80,8 % en septembre. Un seul jour, le 18 septembre, représente 165,3 millions des tokens économisés (39 %).

Sans ce jour, le total est de 60,0 %.

Le deuxième compteur est ccboard, un tableau de bord qui lit le cache de statistiques de Claude Code. C’est mon projet, ces critiques portent donc sur mon propre outil.

Ses chiffres principaux étaient figés depuis le 19 août, parce que ce cache est écrit par Claude Code et que Claude Code avait cessé de le mettre à jour.

Son onglet d’analyse, qui scanne directement les fichiers de transcription, comptait chaque transcription de sous-agent comme une session distincte, ce qui doublait à peu près le nombre de sessions.

Aucun de ces comportements n’est une erreur de calcul. Tous deux correspondent à un écart entre ce que compte l’outil et ce qu’un lecteur suppose qu’il compte.

Le troisième compteur est ccusage, qui lit les mêmes fichiers de transcription pour les deux outils et applique les prix publiés par token. C’est celui que j’ai gardé, pour une raison : il déduplique.

Claude Code écrit le même message de l’assistant plusieurs fois dans sa transcription, une fois par révision diffusée en streaming. Additionner naïvement ces lignes gonfle le total de 87 % sur la même fenêtre.

La correction consiste à dédupliquer sur la paire formée par l’identifiant du message et celui de la requête, exactement ce que fait ccusage et ce que ne fait pas une commande jq bricolée sur une ligne.

Je ne l’ai pas cru sur parole. J’ai écrit un outil de recomptage indépendant qui lit directement les transcriptions brutes des deux outils, et son résultat se situe à moins de 0,11 % de ccusage pour Claude et de 0,49 % pour Codex sur la fenêtre de calibration, avec une correspondance exacte sur 16 jours sur 21.

Trois choses devaient être correctes pour que les chiffres concordent, et chacune a d’abord été une erreur silencieuse :

• Codex garde un second répertoire, archived_sessions, plus gros que le répertoire actif. Ne lire que ce dernier fait perdre les deux tiers du volume.
• Codex réémet un événement d’usage quand sa fenêtre de limite de débit se renouvelle, sans nouvelle consommation associée. Les compter ajoute 2 %.
• Regroupez les dates dans le même fuseau horaire des deux côtés. Découper les jours en UTC plutôt qu’en heure locale faisait varier les totaux de certains jours jusqu’à 48 %.

Rien de cela n’est exotique.

C’est l’état normal d’un format de logs que personne n’a promis stable, et la raison pour laquelle je ne publierais pas un chiffre issu d’un seul script non vérifié, le mien compris.

Opus 5.5 exige sa propre fenêtre de mesure

L’export ci-dessous est une fenêtre de calibration datée. Une mesure sur Opus 5.5 exige une fenêtre distincte qui consigne l’identifiant du modèle effectivement utilisé, l’effort, le fournisseur, les catégories de cache et les résultats des tâches, avec la version de l’outil de comptage.

Utilisez le calcul actuel des coûts pour la dépense équivalente API, et capturez le quota d’abonnement indépendamment.

Opus 5.5 utilise le tokenizer Claude 4.7+, qui produit environ 30 % de tokens en plus pour le même texte que les modèles Claude antérieurs, selon la page tarifaire d’Anthropic (lue le 30 septembre 2026). Les nombres bruts de tokens de part et d’autre du changement ne seront donc pas directement comparables.

La configuration des modèles Claude Code, vérifiée le 10 novembre 2026, indique Opus 5.5 comme valeur par défaut sur Pro, Max, Ultra, Team, Enterprise et l’API Anthropic. Une sélection explicite, une règle d’organisation ou un autre fournisseur peuvent changer le modèle utilisé. Consignez l’identifiant effectif plutôt que de le déduire du nom de l’offre.

La comparaison doit répondre à la question suivante : une même classe de tâches acceptées consomme-t-elle moins de budget et de temps opérateur ?

Un nombre de tokens plus élevé après avoir pris en charge davantage de travail n’est pas une régression en soi. Un nombre de tokens plus faible après l’abandon de tâches difficiles n’est pas une économie.

Conservez les tentatives échouées et la composition des tâches à côté du total.

Le chiffre qui n’est pas une facture

L’équivalent API de vingt jours de mon usage s’élève à 24 351 $ : 7 855 $ côté Claude, 16 496 $ côté Codex.

Ce chiffre est ce que les mêmes tokens auraient coûté aux tarifs par appel publiés. Ce n’est pas ce que j’ai payé. Je paie quatre abonnements forfaitaires.

Pour donner l’échelle, les tarifs publics sont de 100 $ (5x) ou 200 $ (20x) par mois pour Claude Max et de 100, 200 ou 500 $ par mois pour ChatGPT Pro.

Je garde les deux chiffres visibles parce que le rapport est le sujet.

Supposons généreusement 200 $ par mois et par licence, au prorata de vingt jours sur quatre licences (environ 530 $) : mon usage reste valorisé à environ quarante-cinq fois le coût des abonnements qui le couvrent.

Cet écart n’est pas une anomalie personnelle. Il fait partie de la proposition commerciale des abonnements forfaitaires aux agents, et c’est aussi pourquoi la facture ne dit rien du caractère raisonnable de votre usage.

Avec une facturation à l’usage, le gaspillage apparaît en argent ; avec un abonnement, il reste invisible jusqu’à épuisement du quota.

Le chiffre qui contraint

Le mur est la fenêtre de quota, pas les dollars.

Dans l’export Codex utilisé pour cette calibration, les enregistrements de limite de débit incluaient une valeur used_percent pour une fenêtre de 10 080 minutes, soit sept jours. Cela décrit les enregistrements capturés, pas une garantie pour toutes les versions du client ou toutes les fenêtres de compte.

Sur la fenêtre de calibration, mon plafond a atteint 100 % six jours sur vingt, et 90 % ou plus sur onze. C’est la contrainte que je ressens en travaillant, et elle est invisible dans tous les montants en dollars de cette page.

Connectés via un abonnement Claude, claude -p et l’Agent SDK consomment le quota de cet abonnement. Depuis le 7 octobre 2026, les offres Max, Ultra et Team incluent aussi des crédits API mensuels. Pour les utiliser avec ces outils, il faut une clé API de l’organisation Console Claude liée au compte. Conditions du centre d’aide Claude

Pendant la mesure, j’ai lu ce pourcentage dans les fichiers de session Codex et relevé manuellement /usage côté Claude, faute de champ équivalent dans les transcriptions examinées.

Sur les abonnements Claude.ai Pro, Max et Ultra, un script de barre d’état peut aussi relever rate_limits pour les fenêtres de 5 heures et de 7 jours après la première réponse API. Le script doit accepter qu’une fenêtre soit absente. Les mesures présentées ici proviennent des captures manuelles.

Si vous retenez une habitude opérationnelle de cet article, gardez celle-ci : avec un abonnement, capturez la courbe de quota, parce que rien d’autre ne la reconstruit après coup.

De quoi le volume est fait

Le chiffre principal de 38,97 milliards de tokens est une mauvaise unité. Retirez les lectures de cache et il reste 1,75 milliard de tokens, ceux qui représentent du contenu réellement produit ou ingéré.

Tout le reste est le même contexte relu, tour après tour. Deux détails derrière ce rapport comptent davantage que le rapport lui-même :

• Taille du contexte. Mon tour médian de Claude Code porte 261 000 tokens de contexte dans une session principale, et 74 % des tours de session principale dépassent 150 000. Les sous-agents sont plus bas, à une médiane de 149 000, et représentent 40 % du volume total. Une session longue est un gros contexte relu de façon répétée, pas un petit.
• TTL des écritures de cache. Claude Code a écrit 58,7 % de ses entrées de cache avec la durée de vie d’une heure, facturée au double du tarif d’entrée, contre 1,25 fois pour celle de cinq minutes. Ce seul détail comptable peut faire varier le prix équivalent d’une journée de travail.

L’export Codex n’avait pas de colonne d’écriture de cache. La documentation tarifaire d’OpenAI vérifiée le 15 octobre précise aussi que la facturation Codex en crédits ne comporte pas de coût distinct d’écriture de cache, tandis que l’usage par clé API suit les tarifs API. Une télémétrie absente et une règle de facturation sont des observations distinctes ; aucune ne prouve qu’aucun calcul de mise en cache n’a eu lieu.

Le prix par token est incomplet couvre le même mécanisme d’erreur un niveau au-dessus, dans la grille tarifaire des modèles.

Ce que je n’affirme pas

Une machine, vingt jours, les habitudes d’une personne. Les licences utilisées ailleurs ne figurent pas dans ces chiffres.

Les montants en dollars sont des équivalents aux tarifs publics, recalculés à partir d’une grille tarifaire archivée avec chaque export. Je garde cette grille, mais cet article ne la publie pas : ces chiffres ne peuvent donc pas être reproduits à partir de cette seule page.

La période de nettoyage des transcriptions CLI locales était de trente jours par défaut, et je l’ai augmentée avant de collecter cette fenêtre. La documentation de conservation vérifiée le 15 octobre distingue ce nettoyage local de la conservation fournisseur et exempte par défaut de cette limite locale les sessions démarrées ou poursuivies le plus récemment dans Claude Desktop ou Cowork.

Les pourcentages de quota Codex appartiennent au compte qui était actif à ce moment-là, que je consigne séparément.

Pour une nouvelle mesure Codex, relevez le plafond du compte dans le tableau de bord d’usage ou via /status dans la CLI. La documentation d’OpenAI sépare ce plafond, les crédits achetés et la facturation avec clé API. Un ancien relevé de quota reste attaché au compte et à la période où il a été fait.

Une vidéo de t3dotgg datée du 31 août 2026 citait aussi un message attribué à Anthropic annonçant un changement de limites au 14 septembre. Cet article n’établit pas quels comptes l’ont reçu et ne mesure pas son application. Une fenêtre qui traverse un changement de politique rapporté exige des preuves propres au compte avant de traiter ses périodes comme équivalentes.

Ces chiffres sont une mesure datée d’une fenêtre de vingt jours. La série ne rapporte pas de fenêtre ultérieure, et les chiffres ci-dessus ne sont pas mis à jour pour les changements d’offres et de tarifs de cette section.

La méthode est la partie transférable. Dédupliquez avant de compter, vérifiez votre compteur avec une seconde implémentation, gardez la grille tarifaire utilisée et mesurez la contrainte qui vous bloque plutôt que celle que votre page de facturation affiche.

Le FinOps pour l’IA est la suite de cette discipline dès que plusieurs personnes dépensent.

---

YSNK

(Vous devriez maintenant savoir)

• Trois outils mesurant le même usage divergeaient d’un facteur trois, et chaque écart venait d’une différence de définition plutôt que d’une erreur de calcul
• Claude Code écrit chaque message de l’assistant plusieurs fois dans sa transcription, donc tout scan naïf surestime le total. Sur mes données, de 87 %
• Les lectures de cache représentent 94,8 % du volume Claude et 96,1 % de celui de Codex, donc le nombre principal de tokens dit très peu du travail effectué. Les nouveaux tokens sont l’unité honnête, avec ici un rapport de 22:1
• Avec un abonnement forfaitaire, le montant en dollars est un équivalent API, pas une facture. Le mien représente environ quarante-cinq fois l’abonnement qui le couvre, donc la facture ne peut pas dire si mon usage est raisonnable
• La fenêtre de quota a été la contrainte de cette mesure. Mon plafond Codex sur sept jours a atteint 100 % six jours sur vingt. Pour une nouvelle fenêtre côté Claude, relevez /usage ou les champs rate_limits de la barre d’état quand ils sont disponibles