La veille, j'avais construit et testé en une seule journée le pipeline à trois agents qui produit ce blog. Au bout de cette session très longue et très chargée, j'ai touché pour la première fois le plafond d'usage de mon abonnement, depuis que je l'ai. Ma première lecture : un symptôme de taille, pas un problème de qualité. Mon projet a grossi — plus d'agents spécialisés, plus de fichiers `reflexion/`, plus de contexte à recharger à chaque instance — et un projet plus gros fait grimper la consommation de tokens plus vite qu'avant.
Le mécanisme est simple et documenté : chaque tour renvoie toute la conversation accumulée, donc même une question d'une ligne, posée dans une session ouverte depuis des heures, coûte le prix de tout l'historique qu'elle traîne avec elle. C'est explicitement listé, dans la documentation officielle de Claude Code, comme la première raison pour laquelle l'usage grimpe dans une longue session — et plus un projet a de matière à charger (agents, docs, conventions), plus cette mécanique joue vite.
Le pipeline construit la veille en est un bon exemple. `blog-curateur`, `blog-redacteur` et `blog-illustrateur` me font vraiment gagner du temps, mais c'est précisément le facteur de coût multi-agents que j'ai déjà chiffré : jusqu'à 15 fois plus de tokens qu'un chat simple, chez Anthropic comme chez moi. Un coût accepté en connaissance de cause en construisant ce pipeline, pas une surprise découverte en touchant le plafond.
Si ce projet était pour une entreprise, je crois que j'aurais été content de remplir un KPI de quantité — plus de contenu produit, plus d'agents qui tournent, ça se lit bien sur un dashboard. Ici, la mesure qui compte est différente : la qualité reste maîtrisée malgré la croissance du projet, et c'est la taille réelle du projet — plus d'agents, plus de documentation, plus de contexte à porter — qui explique la facture, pas une dérive de ce que je produis.
Ça ne veut pas dire que la croissance est gratuite. Le contexte qui grandit accumule aussi du bruit — le "context rot", documenté par une étude de Chroma menée en 2025 sur 18 modèles frontière, dont Claude Sonnet 4 et Opus 4 : la performance décline de façon continue et mesurable dès que le contexte grandit, bien avant d'atteindre la limite réelle de la fenêtre, et Claude montre l'écart le plus marqué de tous les modèles testés entre un prompt court et un prompt long. Le savoir vérifié qu'on accumule au fil d'une session — décisions tranchées, conventions établies — compte pour de vrai, mais il reste en concurrence directe avec ce bruit, pas à l'abri de lui.
Ce qui monte avec le contexte — et ce qui n'est pas garanti
Ça me donne une idée à tester : recompresser ma documentation et mes fichiers `.md` utiles, pour revenir à un usage tout aussi qualitatif mais qui fait redescendre la consommation de tokens. Pas fait pour l'instant, juste une piste qui devient de plus en plus concrète à mesure que le projet grossit — le plafond de session n'est sans doute que le premier signal d'un projet qui a changé d'échelle.