109,8 milliards de tokens, c’est un excellent nombre pour produire une capture LinkedIn et une assez mauvaise unité pour comprendre ce qui s’est réellement passé.
CodeHerder a pourtant un avantage rare : son énorme chiffre est accompagné de beaucoup de détails.
L’équipe publie l’historique de deux mois d’un système qui distribue des tâches de développement à des agents. Depuis le premier commit du 26 mai, elle dit avoir enregistré 1 166 207 appels assistant, 30 134 sessions d’agents, 5 742 tâches terminées et 109,8 milliards de tokens.
Première correction : ce ne sont pas « 109,8 milliards de tokens Claude ». Le workflow fait tourner Claude Code ou Codex selon les agents et les périodes.
Deuxième correction : ce n’est pas une facture de 109,8 milliards de tokens au sens où on lirait une ligne de carte bancaire. CodeHerder utilise des abonnements forfaitaires et reconstruit des équivalents de prix API pour une partie des analyses de coût.
Le chiffre qui raconte réellement quelque chose est plus petit : 0,5 %.
Presque rien de ce volume n’est de la sortie
Sur la fenêtre où CodeHerder dispose de données assez précises pour tarifer les catégories de cache, 83,7 milliards de tokens, 0,41 milliard seulement sont des tokens de sortie.
Le reste est annoncé ainsi :
- 97,3 % de cache reads ;
- 2,1 % de cache writes ;
- 0,1 % d’input non caché ;
- 0,5 % d’output.
Un appel moyen reçoit environ 97 543 tokens d’entrée pour 491 tokens de sortie selon leur calcul.
« Entrée » ne veut pas dire que l’agent lit 97 543 nouveaux tokens de code à chaque appel. CodeHerder y compte le prompt système, les instructions de l’étape, l’historique de conversation, les retours des outils, les fichiers ouverts, les logs de tests et le code produit plus tôt dans la session.
Et surtout, un cache read est précisément du contexte déjà assemblé qui revient dans un appel suivant.
C’est pour ça que 109,8 milliards est un chiffre à manier avec des gants. En divisant grossièrement les totaux, on obtient environ 3,64 millions de tokens comptabilisés par session d’agent. Ça ne signifie pas que chaque session a découvert 3,64 millions de tokens uniques. Une grande partie du volume est la même matière remise sur la table plusieurs fois.
Le système écrit peu par rapport à tout ce qu’il doit garder présent pour décider quoi écrire.
Cinq agents pour faire passer une histoire jusqu’à done
CodeHerder ne lance pas un seul agent avec « développe cette feature » puis attend que la magie remplisse l’écran.
Son workflow par défaut découpe le travail : plan → code → review → merge → verify. Chaque étape part dans un contexte frais, sur une worktree Git isolée. Une review peut renvoyer le travail vers le code. Une vérification après merge peut faire la même chose.
Cette architecture produit une télémétrie assez propre pour attribuer les appels à une étape précise.
Dans le jeu de données publié, 2 677 user stories seraient allées d’une description courte jusqu’au code mergé sans qu’un humain écrive ou édite le code. Parmi elles, 2 444 ont franchi tous les contrôles du premier coup, soit 91,3 %.
Le nombre est impressionnant. Il ne démontre pas que le découpage en étapes cause ce taux.
CodeHerder le dit lui-même : il n’existe pas de groupe de contrôle où les mêmes stories auraient été exécutées sans ces gates. On observe un système qui fonctionne selon son propre protocole, pas un essai randomisé de l’orchestration logicielle.
C’est une nuance que beaucoup de billets « nous avons remplacé notre équipe par des agents » oublient mystérieusement de rencontrer.
La vérification après merge trouve encore des choses
Les gates donnent quand même une information pratique.
Sur 3 017 résolutions au stade review, 233 sont renvoyées vers le code, soit 7,7 %. Après le merge, le stade verify renvoie encore 63 cas sur 2 728, soit 2,3 %.
Ce dernier chiffre est assez parlant.
Même après qu’un agent a implémenté, qu’un autre a relu et qu’un agent de merge a fait son travail, un test exercé sur l’état mergé trouve encore des échecs.
Ce n’est pas une preuve que 2,3 % de tous les changements d’agents seraient cassés sans cette étape. Les cohortes et dénominateurs ne permettent pas cette généralisation. C’est simplement la preuve que, dans ce workflow précis, le dernier gate n’est pas vide.
Ça rejoint une règle plus générale pour le travail agentique : faire relire un raisonnement n’est pas la même chose qu’exercer l’artefact final.
Même le coût de 7,54 dollars n’est pas une facture
Pour les stories qui passent sans rework, CodeHerder publie un coût médian de 7,54 dollars en équivalent API et un lead time médian d’environ 50 minutes. Le p10 est à 4,57 dollars, le p75 à 10,06 et le p90 à 14,44.
Mais ces dollars sont notionnels.
L’équipe indique faire tourner ses agents sur des abonnements forfaitaires. Elle recalcule ce que les appels auraient coûté aux tarifs API publiés, modèle par modèle et catégorie de token par catégorie de token. La fenêtre de prix ne commence que le 29 juin, parce qu’avant cette date leurs logs ne permettaient pas de connaître assez précisément la durée des cache writes.
Dire « une feature leur coûte 7,54 dollars » sans cette phrase transforme une mesure analytique en fausse facture.
Les modèles compliquent encore la lecture. Dans le workflow mesuré, les étapes de jugement, planification, review et vérification, tournent presque toujours sur le tier de raisonnement, tandis que code et merge utilisent surtout un tier plus rapide et moins cher.
Le plan représente ainsi 31,4 % du coût médian d’une story dans l’analyse principale, légèrement plus que le code à 28,6 %. Une partie de cet écart vient du travail. Une autre vient du modèle choisi pour le faire.
CodeHerder a publié ensuite une analyse séparée d’une migration de modèle de raisonnement. Selon ses données, ce changement a déplacé le coût médian d’une story d’un facteur 2,4 et son lead time presque d’un facteur 3 sur la même période de codebase.
Encore une fois, données maison. Mais le déplacement est suffisamment grand pour rappeler qu’une « architecture d’agents » contient aussi une politique d’allocation de modèles.
Deux humains, mais pas exactement le même compteur
Le site actuel de CodeHerder affiche aussi un joli compteur : CodeHerder construit CodeHerder, avec plus de 3 100 tâches d’agents, 76 jours et deux humains au 10 août.
Il ne faut pas fusionner ce compteur avec les 5 742 tâches du billet des 109,8 milliards. Les pages ne définissent pas ces cohortes comme identiques.
CustomLabs, le studio qui finance et exploite CodeHerder, se présente lui-même comme une petite structure d’ingénieurs seniors. Ça rend l’expérience intéressante : une petite équipe peut aujourd’hui produire assez d’activité de modèles pour que la comptabilité des appels ressemble à celle d’un service beaucoup plus gros.
Mais « deux humains ont produit 109,8 milliards de tokens » serait une simplification que les données publiées ne permettent pas proprement.
Il manque toujours le fichier CSV
Le principal défaut du dossier reste simple : toutes ces mesures viennent du vendeur du produit qui organise les agents.
CodeHerder détaille sa méthodologie mieux que beaucoup de retours d’expérience, explique les biais de modèle, distingue facture et prix notionnel, exclut certaines sessions ambiguës et refuse plusieurs conclusions causales tentantes.
C’est plutôt bon signe.
Mais je n’ai trouvé ni jeu de données brut public, ni audit indépendant permettant de reproduire les 109,8 milliards, les taux de passage ou les cohortes de coût. Les nombres restent donc des mesures auto-déclarées, pas un benchmark public.
La partie la plus utile de l’histoire n’a heureusement pas besoin de croire qu’ils décrivent toute l’industrie.
Sur leur workload, les agents consomment presque toute leur activité tokenisée à maintenir et relire le contexte nécessaire au travail, pas à émettre le diff final.
Si cette forme de développement se généralise, l’optimisation intéressante risque de se déplacer avec elle. Moins « comment générer encore plus de code », davantage « quelle information mérite vraiment de revenir dans le prochain appel, et comment prouver qu’elle est encore utile ».