Les maths cachées du pricing LLM
Pourquoi ta facture est 3× plus salée que ce que tu crois

Voilà un chiffre qui devrait t'inquiéter : le prix affiché sur les pages de pricing des APIs LLM, c'est presque jamais ce que tu payes réellement par sortie utile.

Claude Sonnet 4.6 est listé à 3 $ par million de tokens en entrée. Le mois dernier, on a instrumenté une app RAG de taille moyenne et on a mesuré le coût effectif : 8,40 $ par million de tokens d'input réellement visibles par l'utilisateur. Soit 2,8× le prix affiché. Et c'était une app bien écrite par une équipe qui pensait savoir ce qu'elle faisait.

Si tu build avec des LLM et que tu n'as pas lancé ce calcul sur ta propre stack, ta facture est quasi certainement plus grosse que ce que tu crois. Voici exactement où l'argent fuit.

Le mensonge du prix affiché

Quand un provider te dit "3 $ par million de tokens en entrée", le chiffre est exact, pour l'appel API brut. Le problème c'est que "tokens consommés" et "tokens qui ont produit de la valeur utilisateur" sont deux nombres totalement différents.

Six multiplicateurs se composent en silence entre les deux :

1. La répétition du system prompt
2. L'accumulation du context en conversation multi-tour
3. Les reasoning tokens invisibles
4. Le prompt caching qui rate
5. Les retry loops sur erreurs transitoires
6. L'explosion du tool use

Chacun paraît petit isolément. Empilés, tu obtiens 2-5× ta facture "prévue". Décomposons.

1. La taxe system prompt

Chaque appel que tu fais renvoie ton system prompt à chaque fois. Si ton system prompt fait 2 000 tokens (réaliste, une persona carefully-engineered plus les instructions plus quelques exemples few-shot), et que le message utilisateur fait 50 tokens, 97,5 % de ton input est le system prompt.

L'utilisateur a envoyé 50 tokens. Tu es facturé pour 2 050.

Une app de chat avec un system prompt de 2K tokens et un tour utilisateur moyen de 100 tokens dépense 95 % de son budget input dans le system prompt. À chaque tour. Pour toujours.

Le prompt caching résout ça, mais seulement si tu l'utilises correctement (voir section 4).

2. L'accumulateur de conversation

Le chat multi-tour, c'est un problème d'intérêts composés. Tour 1 coûte X. Tour 2 coûte X + (tour 1). Tour 3 coûte X + (tour 1) + (tour 2). Au tour 10 d'une conversation modeste, tu payes dix fois pour les mêmes tokens du début.

Chiffres réels d'un de nos chatbots :

Le tour 30 coûte 45× ce que le tour 1 a coûté. Même utilisateur. Même type de question. Les premiers tours de la conversation sont payés 30 fois quand on arrive au tour 30.

La plupart des équipes ne plafonnent jamais la longueur des conversations, parce que la pénalité UX est visible et la pénalité coût est invisible jusqu'à la facture mensuelle.

3. Les reasoning tokens invisibles

Celui-là nous a fait le plus mal.

Le extended thinking de Claude et les modèles raisonneurs style o1 d'OpenAI produisent des tokens que tu ne vois jamais mais que tu payes toujours. C'est le brouillon interne du modèle, sa "réflexion" avant d'écrire la réponse.

Pour un prompt complexe avec extended thinking activé, les reasoning tokens peuvent être 3-5× les tokens de sortie visibles. Tu poses une question de 200 tokens, le modèle produit 400 tokens de réponse, et tu viens de payer pour 2 000 tokens de raisonnement que tu n'as jamais lus.

# Ce que ton dashboard montre
input_tokens = 200
output_tokens = 400
# "Coût : 0,018 $"

# Ce que tu as réellement payé
input_tokens = 200
reasoning_tokens = 1 800   # invisibles
output_tokens = 400
# "Coût réel : 0,045 $"

Les reasoning tokens sont facturés au tarif output (15 $/M pour Opus). Ils se composent avec tout le reste de cette liste. Si tu actives l'extended thinking sans mesurer le delta, ta facture double en silence.

4. Le prompt caching qui ne cache pas

Le prompt caching, c'est le plus gros levier de coût que la majorité des équipes n'utilise pas correctement. Les lectures de cache chez Anthropic sont à 10 % du prix input normal. Une remise de 90 %, ignorée.

Pourquoi ? Trois raisons qu'on voit en permanence :

• Cache miss par drift. Change un caractère dans le system prompt, un bump de version, un timestamp, un champ user-specific injecté en haut, et le cache s'invalide. Les équipes ne réalisent pas que leur taux de cache hit est à 20 % au lieu des 95 % qu'elles supposaient.
• TTL trop court. Le cache expire au bout de 5 minutes. Un chatbot à usage sporadique ne touche jamais un hit.
• Cache breakpoints mal placés. Tu peux placer les cache markers manuellement, mais la plupart des équipes ne le font pas, donc le SDK choisit des défauts non optimaux pour leur workload.

Un fix simple, placer les champs user-specific à la fin du prompt au lieu du début, peut te faire passer de 20 % à 90 % de cache hit. C'est 4-5× de réduction de coût à lui seul, sans aucune réécriture de code au-delà de l'ordre des sections.

5. La taxe retry

Les APIs LLM échouent. Rate limits, 529, timeouts, content filter. La plupart des SDK retry automatiquement avec backoff exponentiel.

Chaque retry est facturé.

Un appel qui réussit au 3e essai te coûte 3× ce qu'un appel clean coûte. La plupart des équipes ne trackent pas le taux de retry par endpoint. Dans un cas qu'on a diagnostiqué, les "outages occasionnels d'Anthropic" d'une équipe étaient en fait 8 % de leurs appels qui retrynaient deux fois, un surcoût silencieux de 16 % qu'ils ne voyaient jamais dans les logs, seulement sur la facture.

6. L'explosion tool use

Le function calling, "tool use" chez Claude, c'est là où les coûts deviennent vraiment bizarres. Chaque appel d'outil est un aller-retour : le modèle génère une requête d'outil, tu l'exécutes, tu renvoies le résultat comme nouveau message, le modèle le lit et génère l'étape suivante.

Chaque aller-retour renvoie toute la conversation. Un agent qui fait 5 appels d'outils pour répondre à une question paye pour son contexte complet 5 fois, plus les résultats d'outils.

Question utilisateur (200 tok)
  → LLM réfléchit + demande outil A (400 tok output, 200 tok input)
  → Résultat outil A ajouté (300 tok)
  → LLM relit tout + demande outil B (700 tok input, 200 tok output)
  → Résultat outil B ajouté (500 tok)
  → LLM relit tout + écrit la réponse (1 400 tok input, 300 tok output)

Ce que l'utilisateur voit : une question, une réponse. Ce que tu as payé : 2 300 tokens en input + 900 tokens en output sur une question qui faisait 200 tokens à la base.

Le vrai calcul

Appliquons les six multiplicateurs à un scénario réaliste : un chatbot de support client, Claude Sonnet 4.6, 10 000 conversations par jour.

Calcul naïf :

• Conversation moyenne : 4 tours, 500 tokens chacun → 2 000 tokens input, 400 output
• Coût journalier : 10 000 × (2 000 × 3 $/M + 400 × 15 $/M) = 120 $/jour

Coût réel avec tous les multiplicateurs :

• System prompt : 1 500 tokens × 4 tours = 6 000 tokens répétés
• Accumulation conversation : +40 % de tokens input au tour 4
• Taux de cache hit : 30 % (non optimisé) → tarif effectif 2,40 $/M sur la partie cachée, 3 $/M sur le reste
• Taux de retry : 5 % des appels retryent une fois
• Tool use (2 outils en moyenne par conversation) : +60 % de tokens input

Coût journalier révisé : 312 $/jour. Soit 2,6× l'estimation naïve.

Delta mensuel : 5 760 $ de plus que budgété. Pour une équipe qui pensait maîtriser le truc.

Comment mesurer ça pour de vrai

Tu peux pas fixer ce que tu ne mesures pas. Trois instrumentations que je défendrais pour toute app LLM-heavy :

1. Coût effectif par conversation, pas par token. Divise ta dépense totale par le nombre de conversations utilisateur terminées. C'est ton vrai chiffre.

2. Taux de cache hit, décomposé par endpoint. S'il est sous les 80 % sur un endpoint à fort trafic, tu as une fuite de coût de 3-5× facile à fixer avec un réordonnancement de prompt.

3. Taux de retry par code erreur. 529 et 429 sont des problèmes différents, et ils indiquent souvent que tu es sur le mauvais tier, pas que le provider est instable.

Si tu ne trackes pas ces chiffres, ta facture est décidée par des patterns que tu ne vois pas.

L'angle routing

Une fois que tu peux voir le coût réel par conversation, la question suivante devient : est-ce que le modèle que j'ai utilisé était vraiment nécessaire ?

C'est là que le smart routing paye. La plupart des conversations, salutations, questions factuelles courtes, lookups simples, n'ont pas besoin du modèle top-tier. Un router qui envoie celles-là vers Haiku tout en gardant le raisonnement complexe sur Sonnet/Opus peut diviser par 2-3 la facture effective sans que l'utilisateur remarque.

Les maths cachées ne sont pas inévitables. Elles sont juste cachées.

Prochain dans la série : pourquoi apporter ses propres clés API (BYOK) est le remède le plus propre au problème d'opacité du pricing.