Guide des coûts du Prompt Caching : Cache Hits, préfixes et dépenses réelles d'API

Le coût de la mise en cache des prompts dépend de trois variables : la part de votre prompt qui constitue un préfixe réutilisable, la fréquence à laquelle ce préfixe se répète dans la fenêtre active du cache, et la manière dont un fournisseur donné tarifie les écritures en cache par rapport aux hits de cache. Si vous maîtrisez ces trois chiffres, la mise en cache peut réduire significativement votre facture de tokens d'entrée sur les charges de travail répétitives ; si vous vous trompez, vous risquez de payer une prime d'écriture pour un cache qui n'est jamais réutilisé.

Ce guide distingue ce que les fournisseurs documentent, ce que vous pouvez vérifier sur les surfaces API publiques et ce que vous devriez tester avant d'engager des dépenses de production dans une stratégie de mise en cache.

Points clés à retenir

• Le coût de la mise en cache des prompts comporte deux composantes : un coût d'écriture (généralement facturé lors de la création d'une nouvelle entrée de cache) et un coût de hit (généralement facturé lorsqu'une requête réutilise cette entrée). La documentation d'Anthropic décrit explicitement cette distinction entre écriture et hit ; vous devez confirmer les multiplicateurs actuels sur la page de documentation avant de modéliser vos dépenses.
• Les hits de cache nécessitent une correspondance exacte ou quasi exacte du préfixe jusqu'à un point de rupture défini. Réorganiser les instructions système, les définitions d'outils ou les exemples de few-shot avant ce point de rupture invalide le cache et force une réécriture.
• Les entrées de cache expirent après une durée de vie (TTL) définie par le fournisseur. Si votre volume de requêtes pour un préfixe donné est trop faible pour tenir dans cette fenêtre, vous paierez des coûts d'écriture répétés au lieu d'accumuler des économies grâce aux hits.
• La documentation d'OpenRouter note que le comportement et la tarification de la mise en cache des prompts varient selon le fournisseur et le modèle sous-jacents. Par conséquent, une stratégie de mise en cache qui permet d'économiser de l'argent sur un backend ne se transfère pas automatiquement à un autre. Vérifiez la prise en charge par modèle avant d'acheminer le trafic en fonction d'économies supposées.

Ce que la mise en cache des prompts vous facture réellement

La mise en cache des prompts permet à un fournisseur d'API de stocker la représentation traitée d'un préfixe de prompt afin que les requêtes ultérieures partageant ce préfixe évitent les calculs redondants. Le modèle de facturation qui en découle n'est pas « les tokens mis en cache sont gratuits ». Il est plus proche de « les tokens mis en cache sont moins chers lors de la réutilisation, mais la première écriture coûte plus cher qu'un token d'entrée standard ».

La documentation sur la mise en cache des prompts d'Anthropic présente directement cette structure : une requête qui crée une nouvelle entrée de cache est facturée différemment d'une requête qui utilise une entrée existante. Les multiplicateurs exacts changent au fil du temps et selon le modèle ; considérez donc tout chiffre que vous voyez dans un article de blog, y compris celui-ci, comme une donnée à vérifier par rapport à la documentation actuelle plutôt que comme une constante fixe.

L'implication pratique est que la mise en cache des prompts est un pari sur la réutilisation. Si votre prompt système, votre schéma d'outil ou votre bloc de contexte récupéré est envoyé une fois et jamais répété, la mise en cache ajoute une prime d'écriture sans économies de hit pour compenser. Si ce même bloc est envoyé des centaines de fois dans la fenêtre active du cache, les économies réalisées sur les hits peuvent largement dépasser le coût d'écriture.

Comment fonctionnent les hits de cache : préfixes, préfixes et points de rupture

Les hits de cache sont basés sur les préfixes, et non sur le contenu au sens flou du terme. La partie mise en cache d'un prompt doit correspondre token par token à la requête entrante jusqu'au point où la limite du cache, parfois appelée point de rupture (breakpoint), est définie. La documentation d'Anthropic décrit cela comme un mécanisme explicite où les développeurs marquent la partie du prompt éligible à la mise en cache, généralement les instructions système stables, les définitions d'outils et les longs documents de référence qui ne changent pas entre les appels.

Cela a une conséquence technique directe : tout ce que vous placez avant le point de rupture du cache doit être identique octet par octet entre les requêtes, y compris les espaces et l'ordre. Une erreur courante consiste à intercaler des variables propres à chaque requête (comme un horodatage ou un ID utilisateur) dans le prompt système avant la limite du cache. Cette variable unique annule le cache pour l'ensemble du préfixe, et vous payez des coûts d'écriture à chaque appel au lieu d'accumuler des hits.

La solution est simple : gardez le contenu réellement statique (définitions d'outils, instructions de style, documents de référence volumineux) dans le préfixe mis en cache, et poussez tout ce qui est spécifique à la requête dans le suffixe non mis en cache, généralement le message utilisateur.

La durée de vie du cache compte tout autant que la conception du préfixe. La documentation d'Anthropic décrit une durée de cache par défaut mesurée en minutes, avec une option de durée plus longue disponible pour les charges de travail qui en ont besoin. Si votre modèle de trafic envoie un préfixe partagé toutes les quelques minutes, un cache à courte durée de vie peut expirer avant l'arrivée de la requête suivante, et vous finissez par payer des coûts d'écriture de manière répétée. Les charges de travail à haute fréquence (sessions de chat, boucles d'agents, pipelines de traitement par lots s'exécutant les uns après les autres) sont de bien meilleurs candidats que les appels sporadiques à basse fréquence.

Modéliser les dépenses API réelles : une approche pratique

Plutôt que d'affirmer un pourcentage d'économies, modélisez votre propre charge de travail avec la structure suivante. Cet exemple illustre conceptuellement la structure de la requête ; vérifiez les noms de champs exacts et la tarification actuelle dans la documentation du fournisseur avant de l'implémenter.

{
  "model": "claude-sonnet-5",
  "system": [
    {
      "type": "text",
      "text": "You are a support agent. Full policy document follows...",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [
    { "role": "user", "content": "What is the refund window for order 48213?" }
  ]
}

Le marqueur cache_control sur le bloc système signale que ce contenu est un candidat à la mise en cache. Le premier appel d'une session paie le coût d'écriture pour ce bloc. Chaque appel ultérieur dans la fenêtre active du cache qui réutilise le préfixe identique paie le tarif de hit au lieu du tarif d'entrée complet pour ces tokens.

Pour estimer si cela vaut la peine d'être implémenté pour votre service, rassemblez quatre chiffres à partir de vos propres journaux :

1. Taille du préfixe : le nombre de tokens du contenu stable que vous avez l'intention de mettre en cache (prompt système, schéma d'outil, document de référence).
2. Fréquence d'appel dans la fenêtre TTL : combien de requêtes réutilisent ce préfixe exact pendant la durée active du cache.
3. Tarifs d'écriture et de hit : extraits de la documentation actuelle du fournisseur, et non supposés de mémoire.
4. Variabilité du suffixe : si la partie non mise en cache de votre prompt est petite par rapport à la partie mise en cache, car les économies augmentent avec la part du prompt total située derrière le point de rupture du cache.

Si votre préfixe est volumineux, que votre fréquence d'appel dans la fenêtre TTL est élevée et que votre suffixe est petit, la mise en cache est susceptible de réduire vos dépenses. Si l'une de ces trois conditions est faible, effectuez une comparaison des coûts côte à côte avant de déployer la mise en cache à grande échelle. Le guide de TokenLab sur la réduction des coûts des API d'IA explore un ensemble plus large de leviers au-delà de la mise en cache, notamment la sélection de modèles et le traitement par lots, sur /blog/cut-ai-api-costs-30-percent.

Tableau de décision : quand la mise en cache des prompts est-elle rentable ?

Modèle de charge de travail	Le cache est-il susceptible d'aider ?	Notes
Long prompt système ou schéma d'outil réutilisé sur de nombreux appels dans une session	Oui	Cas classique ; le coût d'écriture s'amortit sur les hits
Grand document récupéré réutilisé sur une courte rafale de questions de suivi	Oui, si les appels tombent dans le TTL	Confirmez le TTL par rapport aux docs actuelles avant de supposer une fenêtre de réutilisation
Prompts uniques sans trafic répété	Non	Prime d'écriture sans hit pour la compenser
Prompts à haute variabilité où la section « stable » change constamment	Non	Tout changement avant le point de rupture invalide le cache
Boucles d'agents avec définitions d'outils répétées sur de nombreux tours	Oui	Les schémas d'outils sont des candidats privilégiés à la mise en cache
Tâches par lots à basse fréquence espacées au-delà du TTL du cache	Non	Le cache expire avant la réutilisation ; payez le coût d'écriture à chaque fois
Routage multi-fournisseur où seuls certains backends prennent en charge la mise en cache	Vérifiez par modèle	Ne supposez pas que la prise en charge de la mise en cache se transfère entre les fournisseurs

Utilisez ce tableau comme liste de contrôle initiale, pas comme réponse finale. Confirmez le TTL, la tarification écriture/hit et les mécanismes de point de rupture par rapport à la documentation du fournisseur pour le modèle spécifique que vous prévoyez d'utiliser, car ces détails changent et varient selon la famille de modèles.

Différences entre fournisseurs à vérifier avant de s'engager

La mise en cache des prompts n'est pas implémentée de manière identique partout, et cela compte si vous acheminez le trafic vers plusieurs fournisseurs ou modèles. La documentation d'OpenRouter sur les meilleures pratiques de mise en cache des prompts note que la prise en charge et le comportement de la mise en cache diffèrent selon le fournisseur sous-jacent, ce qui signifie qu'une stratégie ajustée aux mécanismes de cache d'un modèle ne s'applique pas automatiquement lorsque vous changez de modèle ou que vous acheminez via un backend différent.

Si votre architecture utilise le routage de modèles pour contrôler les coûts (par exemple, en envoyant des tâches de classification de routine vers un modèle à moindre coût comme DeepSeek V4 Flash, GLM-5.2 ou Gemini 3.5 Flash tout en réservant Claude Sonnet 5 ou GPT-5.5 pour des tâches de raisonnement plus complexes), vous devez vérifier la prise en charge de la mise en cache indépendamment pour chaque modèle dans cette table de routage. Une stratégie de mise en cache validée par rapport à la documentation d'un modèle n'est pas une hypothèse sûre pour un autre. La page de classement de TokenLab suit les différences au niveau du modèle que vous pouvez utiliser comme point de référence initial sur /models/rankings, et l'analyse comparative du routage sur /blog/ai-model-routing-benchmark-cost-per-task couvre la façon dont les décisions de routage interagissent avec le coût par tâche, ce qui se cumule avec les décisions de mise en cache plutôt que de les remplacer.

Limites de cette analyse

Ce guide décrit les mécanismes généraux de la mise en cache des prompts tels que documentés par Anthropic et référencés par OpenRouter aux dates observées ci-dessus. Il n'inclut pas les multiplicateurs exacts d'écriture/hit, les durées TTL exactes ou la tarification par modèle, car ces chiffres changent et diffèrent selon le modèle. Avant de construire un modèle de coût pour le trafic de production, extrayez les chiffres actuels directement de la documentation du fournisseur liée ci-dessus plutôt que de vous fier à un chiffre fixe cité dans un contenu tiers, y compris cet article. Le comportement de mise en cache pour les modèles orientés raisonnement, les prompts multimodaux et les très longues fenêtres de contexte peut également différer du modèle général de mise en cache de préfixe décrit ici ; vérifiez par rapport à la documentation du modèle spécifique que vous prévoyez d'utiliser.

FAQ

La mise en cache des prompts réduit-elle toujours les dépenses API ? Non. Elle ne réduit les dépenses que lorsqu'un préfixe stable est réutilisé suffisamment fréquemment dans la fenêtre active du cache pour compenser le coût d'écriture. Les prompts sporadiques ou très variables coûtent souvent plus cher avec la mise en cache activée que sans.

Qu'est-ce qui rompt un hit de cache ? Tout changement dans le contenu du prompt avant le point de rupture du cache, y compris les espaces, l'ordre des tokens ou une variable unique insérée dans un prompt système par ailleurs statique. La correspondance doit être exacte jusqu'au point de rupture.

La mise en cache des prompts est-elle implémentée de la même manière chez tous les fournisseurs ? Non. Anthropic documente un mécanisme explicite de contrôle du cache avec une tarification définie pour l'écriture et le hit. La documentation d'OpenRouter note que la prise en charge et la tarification de la mise en cache varient selon le fournisseur et le modèle sous-jacents ; vous devez donc vérifier la prise en charge par modèle plutôt que de supposer qu'elle est transférable.

Si vous évaluez si la mise en cache des prompts, le routage de modèles ou une combinaison des deux correspond à votre modèle de trafic, commencez avec TokenLab pour comparer les options de modèles et la structure des coûts avant d'engager des dépenses de production.