Je tiens à 20$ par mois avec Claude Code, en usage courant, et ça marche bien. Deux amis, pour ce qui ressemble à un usage comparable, sont montés jusqu'à 200$. Pendant longtemps je n'ai pas compris cet écart de coût — mon résultat me semblait bon, mais je voyais bien qu'on n'avait pas la même vision : moi plutôt un binôme humain + IA qui fonctionne bien, avec quelques appels agentiques en plus pour tester ; eux, un vrai système agentique complet. J'ai regardé les chiffres pour comprendre, et j'ai enfin compris.
Première chose que j'ai vérifiée : la différence n'est pas une histoire de modèle. Les paliers d'abonnement Claude sont Pro à 20$, Max 5x à 100$, Max 20x à 200$ — et le plan Max ne débloque aucun modèle ni aucune fonctionnalité en plus de Pro. Uniquement plus de volume d'usage. Donc si mes amis payent dix fois plus pour un résultat qui semble similaire, l'explication la plus probable n'est pas qu'ils obtiennent mieux : c'est qu'ils consomment dix fois plus de tokens. Rassurant sur un point — je ne rate rien en restant à 20$, mon usage est juste structurellement différent.
D'où vient ce volume, en général ? Anthropic chiffre le coût de son propre système multi-agents : un agent seul consomme 4 fois plus de tokens qu'un simple chat, et un système multi-agents complet monte à 15 fois. Leur propre retour d'expérience est direct là-dessus : des équipes ont investi des mois dans des architectures multi-agents élaborées pour découvrir qu'un meilleur prompting sur un agent unique donnait des résultats équivalents. Leur règle : rester en agent unique quand la tâche tient dans une fenêtre de contexte, que les étapes sont séquentielles, que le workflow est assez déterministe pour être spécifié — ou que le budget est serré. Le multi-agent ne se justifie vraiment que pour éviter la pollution de contexte, pour des tâches réellement parallélisables, ou pour une spécialisation qui améliore le focus.
Tokens consommés, à tâche comparable (chiffres Anthropic)
La phrase qui m'a le plus servi, face à la pression ambiante à parler d'agents plutôt que de scripts pour cocher des KPI : la plupart des tâches de code ont beaucoup moins de sous-tâches parallélisables que la recherche. Le cas d'usage qui justifie le facteur 15, chez Anthropic, c'est leur propre système de recherche interne — ça ne généralise pas à de l'ingénierie logicielle. Je navigue à vue sur cette pression, mon but reste juste de construire des choses solides, pas de faire de la politique interne — mais c'est un fait technique que je peux citer plutôt qu'une simple préférence.
Mon architecture perso, en comparaison, est délibérément étroite : des conversations ciblées, des sous-agents précis, l'humain qui valide avant que ça parte. Et il y a un mécanisme que je n'avais pas pleinement saisi avant de creuser : chaque sous-agent garde son propre cache de prompt. Reprendre un sous-agent déjà utilisé, dont le contexte a déjà été envoyé une fois, coûte le tarif du cache — bien moins cher. Un nouveau chat qui redécouvre tout depuis mes fichiers `.md` repaie le contexte plein à chaque fois. Ça change complètement la lecture de mon propre agent `architecte-agents` : ce n'est pas « un agent de plus qui coûte cher », c'est un raccourci de cache vers une synthèse déjà faite. Architecturalement, ça n'a rien à voir avec un essaim d'agents qui tournent en parallèle, même si les deux s'appellent « agent ».
Autre supposition que j'ai vérifiée plutôt que crue : je pensais qu'un sous-agent basculait automatiquement sur un modèle plus léger. Faux. Le champ `model:` d'un sous-agent vaut `inherit` par défaut — si je ne le précise pas, il tourne silencieusement sur le même modèle que la session principale. Un choix que je croyais faire, mais qui ne se faisait pas. Ça éclaire aussi, en creux, pourquoi Copilot — imposé sur une mission — part vite n'importe comment même en sélectionnant Sonnet comme modèle : le harnais (les outils, la gestion du contexte, la mémoire, l'orchestration) est un produit à part entière, indépendant du modèle branché dessus. Le lien avec le coût est direct : personnaliser cette couche-là, c'est exactement ce qui rend mon usage à 20$ tenable.
Tout ça restait une explication plausible, pas une preuve. Mon côté data engineer n'aime pas s'arrêter là, donc j'ai voulu mesurer mon propre usage plutôt que de me contenter d'une anecdote. J'ai installé `ccusage`, un outil qui reconstitue le coût équivalent tarif API à partir des journaux locaux de Claude Code.
Premier piège, découvert en générant le rapport : `ccusage` agrège par défaut tous les projets Claude Code de la machine, pas seulement celui en cours — aucun filtre par projet en ligne de commande, seulement par date ou par identifiant de session. Pour isoler le coût réel de ce repo, il a fallu croiser les identifiants de session avec les fichiers de journal propres à son dossier. Résultat : 77,61$ équivalent tarif API sur 6 sessions pour ce repo, contre 301,29$ tous projets confondus sur la même période. Un facteur 4 entre ce que je croyais mesurer et ce que je mesurais vraiment, si je n'avais pas vérifié.
Coût équivalent tarif API mesuré avec ccusage
×4 — l'agrégat par défaut de ccusage sur la même période
Ce facteur 4, c'est tout le billet résumé en une ligne. Sans cette vérification, j'aurais cru un chiffre quatre fois trop élevé pour ce projet précis — exactement le genre de réflexe qui vient de mon métier : ne jamais faire confiance à un agrégat sans connaître précisément son périmètre.
Vérifié plutôt que supposé, quatre fois dans cette histoire
model: inherit par défaut — il tourne sur le même modèle que la session principaleccusage mesure directement le coût de ce repoUne mesure ponctuelle ne suffit pas, j'ai voulu pouvoir suivre ça dans la durée — donc j'ai construit un petit dashboard. Deux surprises techniques en chemin, pas prévues au départ. D'abord, un fichier Numbers n'est pas un format texte : c'est une archive zip de fichiers propriétaires, illisible et inéditable par un script. Direction CSV/JSON à la place. Ensuite, une limite plus fondamentale : une page ouverte en `file://` ne peut pas aller chercher un fichier JSON voisin — les navigateurs bloquent ça. C'est exactement pour cette raison que le reste de mes sites utilise un bouton « Importer » manuel plutôt qu'un chargement automatique : pas un choix arbitraire, une contrainte du navigateur. Solution retenue : générer le HTML avec les données embarquées dedans directement au moment de la construction — une commande, et la page est à jour, ouvrable en double-clic, sans serveur, sans dépendance, sans librairie de graphique.
En creusant ensuite le coût par sous-agent, je pensais avoir besoin d'une table de correspondance entre les noms utilisés par `ccusage` et les miens. En fait non : la colonne « Agent » de `ccusage` désigne l'outil en ligne de commande (Claude Code contre un autre), pas mes sous-agents — deux concepts homonymes sans rapport. Le vrai nom d'un sous-agent est écrit en clair ailleurs, dans les journaux bruts d'une session. En vérifiant le calcul à la main, j'ai trouvé un vrai piège de comptage : un message avec plusieurs blocs (du texte plus plusieurs appels d'outil) écrit une ligne de journal par bloc, en répétant le même identifiant de message et le même total cumulé à chaque fois. Sommer sans dédupliquer par cet identifiant fait presque doubler le total — vérifié sur une session précise, où 277 lignes avec des tokens ne correspondaient qu'à 133 messages réellement uniques. Une fois ce doublon corrigé et les tarifs publiés par Anthropic appliqués, mon calcul recoupait à environ 5% près le total donné par l'outil lui-même.
Je n'ai rien inventé dans la façon de présenter tout ça : la logique de dashboard suit un standard existant, FOCUS (FinOps Open Cost and Usage Specification), porté par la FinOps Foundation et étendu aux usages IA récemment. Coût dans le temps, coût par modèle, coût moyen par appel — les mêmes vues qu'on attendrait d'un dashboard de coûts cloud classique, appliquées à mon usage perso de Claude Code.
Alors, pourquoi je reste à 20$ pendant que d'autres montent à 200$ ? Pas par petit budget, et pas non plus par chance. Parce que mon usage — du human-in-the-loop par défaut, des sous-agents ciblés et réutilisés à chaud plutôt qu'un essaim parallèle — est structurellement plus économe, exactement dans le sens où Anthropic décrit son propre usage recommandé : un agent unique bien prompté pour l'essentiel, le multi-agent réservé à ce qui est vraiment parallélisable. Mes amis n'ont pas forcément tort : leur usage vise sans doute plus de structure, là où le mien répond juste au besoin du moment — et seul sur mon propre projet, en train de tester, la sur-ingénierie ne peut de toute façon pas s'appliquer. Mon but est un résultat pas cher, quitte à y passer plus de mon propre temps à la place. Mais « plus cher » ne veut pas dire « meilleur », et j'ai maintenant un chiffre pour l'affirmer plutôt qu'une impression.