Le prompt caching, lu sur votre facture
Comment auditer ce que le prompt caching économise vraiment : les deux colonnes de cache de chaque requête, un taux de réussite que vous pouvez calculer, et les trois schémas qui tuent silencieusement vos économies.
Le prompt caching se vend comme une remise. Votre facture est l'endroit où cette remise est prouvée — ou silencieusement perdue. La plupart des explications s'arrêtent au mécanisme ; ce post vous apprend à lire vos propres chiffres — car une économie que vous ne pouvez pas vérifier n'est qu'un chiffre plus petit auquel vous faites encore confiance.
Transparence d'emblée : j'opère Teapot Router, une passerelle API dont l'espace de travail montre le coût par requête, les tokens et les colonnes de cache, avec export. La méthode d'audit ci-dessous vaut pour tout endpoint qui expose les mêmes chiffres.
Deux colonnes décident de votre remise
Le caching facture sur deux comptages de tokens spéciaux. Tokens de création de cache : la première écriture d'un préfixe stable de prompt, facturée avec une prime modeste sur le prix d'entrée normal. Tokens de lecture de cache : les réutilisations ultérieures de ce même préfixe, facturées avec une remise profonde — couramment un ordre de grandeur sous l'entrée froide. Les multiples exacts varient selon le fournisseur et le modèle ; s'ils ne figurent pas sur la grille publique, c'est déjà un constat.
Le mécanisme est la réutilisation de préfixe : ce qui reste stable en tête de votre prompt — prompt système, contexte du projet, la conversation précédente — est traité une fois puis relu à bas prix à chaque tour suivant. La remise n'est pas un bon de réduction. C'est la conséquence arithmétique du fait que la tête de votre prompt ne change pas.
Le chiffre qui mérite d'être calculé : le taux de réussite
Tirez une semaine de requêtes réelles et calculez un ratio : tokens de lecture de cache sur tokens d'entrée totaux. La valeur absolue dépend de votre charge — un utilisateur de chats toujours neufs et un agent à session longue atterrissent à des endroits différents — donc le signal, c'est la tendance, pas une cible universelle. Un taux qui glisse à la baisse sur une semaine signifie généralement que quelque chose en amont du prix a changé : vos prompts, la forme de vos sessions, ou votre endpoint.
Trois schémas qui tuent votre cache en silence
Quand la tendance glisse, cherchez l'un de ces trois avant d'accuser le fournisseur :
- Un préfixe instable. Un horodatage, une instruction tournante ou un prompt système fraîchement édité tout devant invalide le préfixe caché à chaque tour — vous repayez la prime d'écriture et ne touchez jamais une lecture. Le devant du prompt doit être ennuyeux.
- Le brassage de contexte au milieu. Les agents qui collent entre les tours des sorties d'outils géantes et toujours changeantes maintiennent le préfixe en mouvement ; selon l'endroit où se situe ce brassage, la réutilisation s'effondre. Purger les vieilles sorties d'outils est une décision de cache autant que de rangement.
- Des sessions plus courtes que le cache. Les caches vivent peu — des minutes, pas des jours. Les longs intervalles entre tours remettent l'horloge à zéro, et une session découpée en multiples petits morceaux ne relira peut-être jamais assez pour amortir la prime d'écriture. Des sessions moins nombreuses, plus longues et plus stables cachent mieux.
La question de l'auditabilité
Quel que soit votre endpoint, trois questions décident si la remise de cache est réelle pour vous : le registre par requête sépare-t-il création de cache, lecture de cache et tokens froids ? Les prix de cache figurent-ils dans la grille lisible par machine, pas seulement dans un post de blog ? Pouvez-vous exporter assez d'historique pour voir la tendance de votre taux ? Si une réponse est non, l'économie est une affirmation marketing invérifiable — et les remises non vérifiées ont une manière de s'évaporer.
Le registre de l'espace de travail et l'endpoint public de prix sont notre façon de répondre à ces questions sur notre propre service : les colonnes de cache de chaque requête, exportables, au même prix que le JSON que lit la calculatrice : https://teapotrouter.com/en/claude-code-cost-calculator
Le prompt caching n'est pas une fonction que vous activez ; c'est un comportement que vous mesurez. Lisez les deux colonnes, calculez le taux de réussite, surveillez la tendance, et corrigez le préfixe avant de chercher un meilleur tarif. Un fournisseur qui vous montre les colonnes vous laisse vérifier son travail — celui qui ne les montre pas vous demande de noter votre propre remise les yeux fermés.
FAQ
Le prompt caching économise-t-il toujours de l'argent ?
Non. Les écritures de cache portent une prime sur le prix d'entrée normal, donc un préfixe utilisé une seule fois coûte un peu plus cher. L'économie vient des préfixes stables relus de nombreuses fois — longues sessions, prompts système volumineux et statiques, documents réutilisés.
Comment calculer mon taux de réussite de cache ?
Depuis le registre par requête : tokens de lecture de cache divisés par tokens d'entrée totaux sur une semaine de travail réel. Jugez la tendance, pas une requête — un taux qui glisse pointe vers des changements de prompt ou de session avant de pointer vers le prix.
Pourquoi mes économies de cache ont-elles disparu ?
D'ordinaire l'un de trois : le préfixe a cessé d'être stable (éditions ou contenu volatil en tête), les intervalles d'inactivité ont dépassé la durée de vie du cache, ou l'endpoint a changé sa comptabilisation — ce qui ne se voit que si le registre sépare les colonnes.