Pourquoi un tarif de token unique ment sur votre facture
9 septembre 2026
La plupart des tableaux de bord affichent un coût par requête calculé comme `tokens × prix par token`. C'est faux dès qu'un provider expose du prompt caching ou du raisonnement — et les deux sont désormais standards chez OpenAI et Anthropic.
Le total inclut déjà les catégories, pas à côté
Un détail contre-intuitif mais vérifiable dans les intégrations des principaux SDK : `prompt_tokens` est inclusif. Il contient déjà les tokens lus depuis le cache et ceux utilisés pour l'écrire, pas seulement les tokens « frais ». Idem côté sortie : `completion_tokens` inclut les tokens de raisonnement d'un modèle qui en produit.
Concrètement : `prompt_tokens = fresh_input + cache_read + cache_creation`. Traiter `prompt_tokens` comme un bloc homogène et le tarifer au prix plein revient à payer une lecture de cache — typiquement 5 à 10× moins chère qu'un token frais chez les providers qui l'exposent — au prix d'un token neuf.
L'écart n'est pas un arrondi
Sur un usage réel de prompt caching (system prompt volumineux, réutilisé sur des dizaines de tours), le delta entre « tarif plat » et « tarif par catégorie » n'est pas de quelques pourcents : c'est un facteur multiplicatif sur la part du coût qui vient du contexte relu. Un agent qui rejoue le même contexte de 20K tokens à chaque tour peut voir sa facture réelle chuter de moitié une fois la décomposition appliquée — la différence entre acheter le contexte à chaque appel et le louer.
L'écriture de cache, à l'inverse, coûte généralement plus cher qu'un token frais (l'investissement initial de mise en cache). Un tarif plat sous-facture donc cette catégorie précise — l'erreur va dans les deux sens, pas un seul.
Pourquoi ça compte au-delà du dashboard
Si un coût par requête alimente une limite dure — un budget mensuel par intégration, une alerte de dépassement — le tarifer au prix plein pénalise exactement le comportement qu'on veut encourager : le prompt caching. Une intégration qui fait bien les choses (contexte stable, réutilisé) se fait couper alors qu'elle consomme, en argent réel, une fraction de ce que le compteur affiche.
Ce que ça demande côté implémentation
Trois compteurs distincts par requête (lecture cache, écriture cache, raisonnement), chacun un sous-ensemble du total — jamais un ajout. Un tarif par catégorie résolu depuis le catalogue de pricing du modèle, avec repli explicite sur le tarif plein quand un modèle ne publie pas cette décomposition : mieux vaut sur-estimer un coût qu'inventer une remise que le provider n'accorde pas réellement.