Pourquoi ces 5 chiffres comptent

Sur douze optimiseurs de tokens mesurés de bout en bout sur de vraies sessions de code, un seul exactement rend les sessions moins chères avec une marge statistiquement significative — neuf ne produisent aucune différence mesurable, et deux rendent les sessions plus chères que de n'utiliser aucun outil. C'est le fait le plus utile de cette catégorie, et il contredit à peu près toutes les pages produit qu'on y trouve. L'écart vient de ce qu'on mesure. La plupart des outils du domaine annoncent des taux de compression : de combien un fichier, un log ou un message rétrécit après traitement. Ces chiffres sont réels et souvent impressionnants. Ils ne disent simplement pas ce que vous voulez savoir, parce qu'un agent qui compresse chaque fichier mais en lit ensuite quarante, ou qui ajoute un aller-retour pour décider quoi compresser, peut très bien finir plus cher. La compression est une entrée. Le coût de session est le résultat. Seul le résultat apparaît sur votre facture. Une divulgation d'emblée, parce qu'elle change la façon de lire ce qui suit : le benchmark ci-dessous est maintenu par moi, et mon propre outil y est premier. Il est public, reproductible, et j'y ai laissé les résultats qui ne m'arrangent pas — mais ce n'est pas un tiers indépendant, et vous ne devez pas le traiter comme tel. La méthode est publiée pour que vous puissiez la contester précisément plutôt qu'en bloc.

1. Combien d'optimiseurs rendent réellement les sessions moins chères ?

Un sur douze (THOL, 2026). Neuf des douze se sont révélés statistiquement indiscernables du contrôle : sur 170 runs chacun, la facture ne permet pas de dire si l'outil était installé. Deux ont fini mesurablement moins bons que l'absence totale d'outil. C'est le chiffre qui devrait changer votre façon d'acheter dans cette catégorie. Le résultat par défaut de l'installation d'un optimiseur de tokens, c'est qu'il ne se passe rien de mesurable. Pas de dégât, en général — juste aucun effet sur ce pour quoi vous l'avez installé. Tout outil qui vous demande de croire un pourcentage de compression vous demande de croire une métrique d'entrée pendant que la métrique de résultat reste non mesurée. Les neuf outils sans effet ne sont pas mal construits. Plusieurs relèvent d'une ingénierie remarquable. Ils optimisent simplement une seule couche — sorties de commandes, compression de messages, ou récupération — dans une session dont le coût se répartit sur toutes, plus le rejeu du transcript qui domine l'ensemble.

2. De combien l'outil en tête réduit-il le coût ?

23,2 % de moins que sans aucun outil, mesuré sur 17 tâches et 170 runs (THOL, 2026). C'est le chiffre agrégé sur l'ensemble des tâches, y compris les courtes où il y a peu à économiser. Deux remarques à son sujet. D'abord, il est plus petit que les pourcentages que cette catégorie affiche en une, et délibérément : c'est un coût de session de bout en bout, pas un taux de compression dans le meilleur cas sur un fichier favorable. Ensuite, c'est le seul chiffre des douze à avoir survécu au test statistique face au contrôle. Si vous le comparez à un « 90 % de réduction » annoncé par un concurrent, vous comparez deux grandeurs différentes. Demandez ce que mesure l'autre chiffre avant de conclure qu'il est quatre fois meilleur.

3. Où les économies se concentrent-elles réellement ?

Sur les longues sessions : 38,9 % de réduction au-delà de 200 000 tokens (THOL, 2026), mesuré sur 7 tâches et 70 runs. C'est le chiffre le plus actionnable de la page. Les économies ne sont pas réparties uniformément : elles augmentent avec la longueur de session, parce que le mécanisme attaqué est le transcript et le contexte rejoués à chaque tour. Une session courte a peu de contexte accumulé à élaguer. Une longue en a énormément. Ce qui correspond exactement à l'endroit où se situe la douleur. Personne ne s'inquiète du coût d'une session de cinq minutes. Les sessions qui épuisent le quota d'un plan ou produisent une facture surprenante sont les longues — et c'est là que l'effet mesuré double à peu près.

4. Un optimiseur peut-il aggraver les choses ?

Oui — l'outil le moins performant a rendu les sessions 55,7 % plus chères que sans aucun outil (THOL, 2026), et un second a fini 23,4 % plus cher. Ce n'est pas un risque théorique, et l'outil en question est l'un des plus populaires de la catégorie au nombre d'étoiles GitHub. Sa compression par message fonctionne comme annoncé. Le problème est tout ce qui l'entoure : le surcoût de traitement, les allers-retours supplémentaires, et des décisions de compression qui ne se rentabilisent pas une fois le comportement réel de l'agent dans la boucle. La leçon générale est inconfortable mais utile : la popularité et l'effet mesuré ne sont pas corrélés ici. Un outil-blague qui fait répondre le modèle en style télégraphique « homme des cavernes » a devancé plusieurs efforts d'ingénierie sérieux. Les étoiles mesurent l'enthousiasme, pas les résultats.

5. Quelle quantité de mesure derrière chaque résultat ?

170 runs par outil, sur 17 tâches de code déterministes (THOL, 2026), les résultats étant calculés sur les seuls runs réussis. La raison de ce volume, c'est la variance. Les sessions d'agent sont bruitées : la même tâche lancée deux fois peut différer sensiblement en coût selon les fichiers que l'agent décide de lire. Une simple comparaison avant/après, méthode de la plupart des benchmarks d'outils du domaine, ne peut pas distinguer un effet réel de ce bruit. La plupart des verdicts « aucune différence mesurable » ci-dessus auraient ressemblé à des victoires ou des défaites nettes dans un test à un seul run. C'est aussi pourquoi neuf outils atterrissent dans la catégorie sans effet plutôt que d'être classés avec assurance les uns contre les autres. Avec suffisamment de runs, les petits écarts cessent de paraître significatifs.

Notes de sources

Tous les chiffres de cette page proviennent du Token-Harness Optimizer Leaderboard (THOL), un benchmark public que je maintiens : pi-infected.github.io/token-harness-optimizer-leaderboard. Les résultats bruts, y compris les données par outil et par tâche derrière chaque chiffre, y sont publiés. Pour ceux qui veulent la provenance complète : la campagne en cours tourne sur Claude Code 2.1.206 avec Claude Sonnet, en sessions headless totalement isolées, avec des fixtures déterministes et une vérification programmatique face à une vérité terrain. Les ratios de coût sont des moyennes géométriques face à un contrôle sans outil, avec intervalles de confiance à 95 % par rééchantillonnage bootstrap ; « aucune différence mesurable » signifie que l'intervalle contient 1,0. Le chiffre des longues sessions est restreint aux tâches dépassant 200 000 tokens. L'entrée de Tokenade a été mesurée sur la version 0.8.13 dans des conditions identiques. Ce sont des données internes, pas une étude tierce — voir la divulgation en haut de page. C'est reproductible plutôt qu'indépendant, ce qui n'est pas la même garantie. Quand un outil est absent de la campagne en cours, ce site le dit au lieu de reprendre la promesse publiée par l'éditeur.

À voir aussi :

Meilleurs optimiseurs de tokens pour Claude Code — le terrain classé sur ces critères
Alternatives à ccusage — mesurer la dépense ou la réduire
Alternatives à Headroom — l'outil derrière le chiffre n°4
Le prix de Claude Code — de quoi la facture est faite au départ

Benchmark des optimiseurs de tokens : 5 chiffres

Key figures