L'estimation qui ne correspond jamais à la facture
La page tarifaire et la facture décrivent deux choses différentes. La page tarifaire décrit un token : $5 par million sur Claude Opus 4.8, une fraction de centime pour une question de client. Votre facture décrit la façon dont votre produit appelle réellement le modèle, et ce chemin est plus long, et bien plus coûteux, que le token que vous aviez chiffré. Personne ne vous surfacture.
L'écart n'est pas un frais mystérieux unique. C'est un petit ensemble de multiplicateurs précis et identifiables, et une fois que vous les voyez, vous pouvez les budgétiser. Les voici, un par un, chiffrés sur un chatbot de support fonctionnant sur Claude Opus 4.8.
| Élément | Montant |
|---|---|
| Votre estimation | $200 |
| Contexte multi-tours | + $1,260 |
| Votre facture | $1,460 |
Ce que vous budgétez vs ce qui vous est facturé
Chatbot de support · 10,000 conversations / mois · Claude Opus 4.8 ($5 / $25 par 1M)
Modélisé, pas un devis. Hypothèses : une conversation de 4 tours ; un prompt système de 1,500 tokens plus la connaissance récupérée, renvoyés à chaque tour ; un message client de ~500 tokens et une réponse de ~700 tokens par tour. Cela représente ~15,200 tokens d'entrée et ~2,800 tokens de sortie par conversation, soit $760 d'entrée + $700 de sortie sur 10,000 conversations. Vos chiffres différeront ; la forme, non.
Le propriétaire prudent estime $200 par mois : 10,000 conversations, chacune composée d'une question courte et d'une réponse plus longue, chiffrées honnêtement à $5 en entrée et $25 en sortie. La facture est de $1,460. Le propriétaire qui n'a compté que la question du client - les tokens d'entrée, un seul tour - avait budgété $25 et s'est trompé d'un facteur de près de soixante. Ni l'un ni l'autre n'a fait d'erreur de calcul. Ils ont estimé la mauvaise quantité.
Piège 1 : vous avez chiffré la question, mais la réponse coûte cinq fois plus
Sur chaque modèle Claude actuel, les tokens de sortie coûtent exactement cinq fois les tokens d'entrée. Fable 5 est à $10 en entrée et $50 en sortie. Opus 4.8 est à $5 et $25. Sonnet 5 est à $3 et $15 (avec un tarif de lancement à $2 et $10 jusqu'au 31 août 2026). Le rapport ne bouge jamais, et il va dans le mauvais sens par rapport à la façon dont on estime : on chiffre ce que l'on tape, qui est court, et on oublie ce que le modèle renvoie, qui est long.
Dans l'exemple du support, la question du client fait environ 500 tokens et la réponse environ 700. Ces réponses à elles seules - 700 tokens multipliés par 10,000 conversations à $25 par million - reviennent à $175 par mois, soit déjà sept fois l'estimation complète fondée sur la seule entrée, à $25. Si votre produit résume, rédige, explique ou écrit du code, c'est du côté de la sortie que se trouve votre argent, et c'est le côté que le prix affiché sous-pondère discrètement.
Piège 2 : une conversation n'est pas une question
C'est le gros morceau, et c'est le piège qui transforme une estimation bien nette en une facture surprenante. L'API n'a pas de mémoire. Elle ne se souvient pas de votre dernier tour. Donc, pour poursuivre une conversation, votre application renvoie l'intégralité de celle-ci à chaque tour : le prompt système, toute connaissance que vous avez récupérée, et l'ensemble des échanges jusque-là. Le tout vous est facturé, de nouveau, chaque fois que le modèle prend la parole.
Suivez la conversation de support sur quatre tours. Un prompt système et un extrait de connaissances de 1,500 tokens accompagnent chaque tour. Au quatrième tour, vous renvoyez aussi trois questions précédentes et trois réponses précédentes. En additionnant, une seule conversation de quatre tours consomme environ 15,200 tokens d'entrée, et non les 500 que vous imaginiez en regardant une seule question. C'est environ trente fois l'entrée que vous aviez estimée, et c'est pourquoi le contexte renvoyé, et non le modèle que vous avez choisi, constitue la plus grande ligne de la facture ci-dessus.
Cela s'accumule aussi. Comme chaque tour repaie tous les tours qui l'ont précédé, le coût total d'une conversation croît avec le carré de sa longueur, et non de façon linéaire. Une conversation de dix tours ne coûte pas dix fois une conversation d'un tour, elle coûte bien plus. Une fonctionnalité de chat qui paraît bon marché dans une démo de trois messages peut se comporter très différemment une fois que de vrais utilisateurs s'installent dans des fils de vingt messages.
Piège 3 : la réflexion que vous payez mais ne voyez jamais
Le modèle raisonne avant de répondre, et ce raisonnement est facturé comme de la sortie, que vous le voyiez ou non. Sur Fable 5, cette réflexion est toujours active : une requête qui renvoie une réponse bien nette de 500 tokens peut avoir dépensé plusieurs milliers de tokens à raisonner au préalable, et chacun de ces tokens invisibles est facturé au tarif de sortie de $50. La réponse affichée à l'écran n'est que la petite partie de ce que vous avez payé.
Le même levier existe sur la famille Opus via le réglage d'effort. Montez l'effort et le modèle réfléchit plus longtemps et appelle davantage d'outils, dépensant plus de tokens pour plus de fiabilité. Baissez-le et il va plus vite et coûte moins cher. Aucun des deux n'est mauvais, mais si vous n'avez jamais choisi de niveau, vous payez ce que coûte la valeur par défaut. Si vous comparez un modèle qui réfléchit en permanence à un modèle standard, la comparaison honnête n'est pas celle des deux grilles tarifaires mais celle des deux nombres de tokens qu'une tâche réelle produit - ce qu'aborde précisément notre comparatif Fable 5 contre Opus 4.8.
Piège 4 : le même texte, compté comme davantage de tokens
Voici celui qui piège même les équipes attentives. Lorsque vous passez à un modèle plus récent, son tokeniseur - ce qui découpe le texte en tokens facturables - peut compter le texte identique comme davantage de tokens qu'auparavant. Vous avez changé une chaîne de modèle, ajouté aucune fonctionnalité, gardé exactement le même prix au token, et la facture a quand même augmenté.
| Modèle | Montant |
|---|---|
| Sonnet 4.6 | $900 |
| Sonnet 5 | $1,170 |
| Différence | + $270 |
Même texte, même grille tarifaire, une facture plus élevée
Une mensuel charge de travail sur la grille tarifaire identique ($3 / $15 par 1M)
Le chiffre publié de dérive du tokeniseur (~30%) appliqué à un volume fixe. Le même ensemble de documents se tokenise en ~100M tokens sur Sonnet 4.6 (50M en entrée + 50M en sortie = $150 + $750 = $900) et en ~130M sur Sonnet 5 (65M + 65M = $195 + $975 = $1,170). Mêmes mots, même grille tarifaire, +$270 par mois.
Sonnet 5 compte environ 30 % de tokens de plus que Sonnet 4.6 pour les mêmes mots. Le tokeniseur d'Opus 4.7 se situe quelque part entre équivalent et environ 35 % plus lourd qu'Opus 4.6, selon le contenu. Ainsi, une montée de version qui paraît gratuite sur la page tarifaire peut discrètement gonfler une facture d'un tiers. La solution n'est pas d'éviter de monter de version - les modèles plus récents en valent généralement la peine - mais de mesurer à nouveau vos nombres de tokens réels après tout changement et de rebâtir votre budget sur les nouveaux chiffres, au lieu de supposer qu'une grille tarifaire identique signifie une facture identique.
Piège 5 : les tentatives que vous ne voyez jamais
L'échange requête-réponse net que vous imaginez est le scénario idéal. En production, il y a des erreurs transitoires que l'on réessaie, des refus de sécurité, et des boucles d'agent qui appellent un outil, lisent le résultat et rappellent le modèle. Chacun de ces allers-retours supplémentaires ajoute des tokens au compteur, et aucun n'apparaît dans votre représentation mentale de "une question, une réponse".
Il y a ici une nuance réelle qu'il vaut la peine de connaître. Sur Fable 5, une requête refusée avant de produire la moindre sortie n'est pas facturée du tout, tandis qu'une requête refusée en cours de flux facture la partie déjà diffusée. Les tentatives sont peu coûteuses à lancer et faciles à laisser sans limite, si bien qu'un petit bug - un agent qui boucle une fois de trop, une politique de réessai sans plafond - apparaît comme une ligne de facture, et non comme une trace d'exécution.
Toute la facture cachée sur une seule page
Six multiplicateurs se glissent entre la grille tarifaire d'un LLM et la facture. Cinq d'entre eux tiennent à la façon dont vous appelez le modèle ; le sixième tient à la façon dont vous planifiez le travail. Aucun n'est une astuce ou un frais caché, et chacun dispose d'un levier précis qui l'aplanit.
| Coût caché | Ce qui le déclenche | Ampleur typique | Le levier qui l'aplanit |
|---|---|---|---|
| Sortie facturée 5x l'entrée | Chaque réponse écrite par le modèle | Généralement la majeure partie de la facture | Raccourcir les réponses, plafonner la sortie maximale, baisser le niveau d'effort |
| Contexte renvoyé | L'API est sans état, l'historique est donc renvoyé à chaque tour | Le coût total de la conversation croît avec le carré du nombre de tours | Prompt caching (lectures à ~0.1x sur le préfixe mis en cache) |
| Tokens de réflexion | Raisonnement toujours actif (Fable 5) ou réglage d'effort élevé | Peut éclipser la réponse que vous voyez réellement | Adapter l'effort à la tâche, utiliser un palier sans réflexion pour les travaux simples |
| Dérive du tokeniseur | Un modèle plus récent compte le même texte comme davantage de tokens | ~+30% de Sonnet 4.6 à Sonnet 5 | Mesurer à nouveau les nombres de tokens après tout changement de modèle, puis rebâtir le budget |
| Réessais et boucles d'outils | Erreurs transitoires, refus, allers-retours d'agent | Chaque tentative échouée peut refacturer | Idempotence plus backoff, garder les boucles d'outils bornées |
| Travail de fond non regroupé en lots | Exécuter des tâches tolérantes à la latence sur l'API en direct | Prix plein pour un travail qui pourrait attendre | Batch API (-50% sur tout) |
La majeure partie de la facture est optionnelle
Relisez ce tableau et remarquez la colonne de droite. Presque chaque multiplicateur a une réduction en face, et les trois plus importants ne sont pas "passer à un modèle moins cher" - ce sont des choses que vous pouvez faire sur le modèle que vous utilisez déjà.
- Le prompt caching s'attaque directement au contexte renvoyé. Ce prompt système de 1,500 tokens que vous envoyez à chaque tour peut être mis en cache une fois puis relu à environ un dixième du prix d'entrée à chaque tour suivant. L'écriture du cache comporte un léger surcoût unique, ce qui le rend rentable précisément lorsque vous réutilisez beaucoup le même contexte, ce que fait exactement une fonctionnalité de chat.
- La Batch API retire 50 % sur tout pour les travaux qui tolèrent un peu de latence - résumés de nuit, classification en masse, tout ce qu'un utilisateur n'attend pas en temps réel.
- Le bon dimensionnement du modèle et de la sortie - envoyer la moitié facile de votre trafic vers un palier moins cher, plafonner la longueur des réponses, choisir un niveau d'effort à dessein - réduit le côté sortie à 5x de la facture sans changer une seule réponse à laquelle les utilisateurs tiennent.
Empilés dans le bon ordre, ils peuvent réduire une facture de plus de moitié sans dégrader l'expérience, ce qui fait l'objet d'un article entier à part. Si vous en êtes encore à décider si une fonctionnalité d'IA vaut la peine d'être construite, le point de départ honnête est le même que celui que défend cet article : estimer à partir du chemin d'appel réel, puis le comparer à ce que vaut la tâche. Notre guide de l'automatisation par IA concrète pour les petites entreprises est une bonne étape suivante.
