Coût d’écriture du prompt cache : quand le surcoût paie

Une écriture dans le prompt cache est rentabilisée dès la première relecture pendant le TTL : l’écriture est facturée 1.25x le tarif d’entrée, contre 0.1x pour la lecture. Sur deux appels, un seul hit suffit donc à passer d’un surcoût de 25% à une économie de 32.5%. Pourtant, dans l’un des cinq scénarios de notre suite d’agents, ce même surcoût a entraîné une perte mesurée de 6%. Tout dépend d’un chiffre : le ratio lecture:écriture de votre trafic. L’objectif de cet article est de le mesurer avant qu’il n’apparaisse sur la facture. Toutes les mesures ci-dessous ont été effectuées via la gateway Synthorai à partir des données de facturation réelles. Les chiffres sur les agents proviennent d’une suite de 150 épisodes ; les résultats sur le TTL et le regroupement des requêtes, de sondes salées dédiées.

TL;DR

• Les écritures explicites dans le cache sont facturées 1.25x avec un TTL de 5 minutes, ou 2x avec celui d’une heure. Les seuils explicites de GPT-5.6 suivent la même structure, à 1.25x/0.1x. Une seule relecture suffit pour atteindre le seuil de rentabilité.
• Dans notre suite d’agents, l’effet net du surcoût allait de +6% pour le RAG, avec un ratio lecture:écriture de 0.2, à -83% pour le batch, avec un ratio de 15.7.
• Les hits rafraîchissent gratuitement le TTL de Claude : avec un trafic régulier, l’écriture est facturée une fois par période d’inactivité, pas une fois par fenêtre.
• Les performances du cache implicite varient fortement : GPT-5.5 a maintenu 7 hits sur 8 après un appel d’amorçage, tandis que Gemini n’en a obtenu que 1 à 3 sur 12, même avec des appels regroupés. Dans les deux cas, aucun surcoût.

Combien coûte réellement une écriture dans le cache ?

Les providers que nous comparons utilisent trois modèles tarifaires, dont deux facturent l’écriture. Avec le cache explicite de Claude, la création est facturée 1.25x le tarif d’entrée pour le TTL par défaut de 5 minutes, et 2x pour celui d’une heure ; les lectures sont facturées 0.1x. GPT-5.6 est passé à des seuils explicites avec les mêmes multiplicateurs, soit 1.25x en écriture et 0.1x en lecture. Les deux principales implémentations explicites du marché ont donc désormais la même tarification. Le troisième modèle est le cache implicite, utilisé par Gemini, Kimi et les modèles OpenAI antérieurs à 5.6 : aucun surcoût à l’écriture, uniquement des lectures à prix réduit lorsque le provider trouve une entrée en cache.

Le calcul du seuil de rentabilité des écritures explicites est simple. Sans cache, un préfixe de P tokens coûte P au tarif normal. Avec le cache, le premier appel coûte 1.25P ; chaque relecture pendant le TTL coûte 0.1P au lieu de P. Dès la première relecture, les deux appels coûtent au total 1.35P, contre 2P sans cache, soit une économie de 32.5%. Chaque hit supplémentaire réduit ensuite de 90% le coût de son préfixe. Le risque ne vient pas du surcoût lui-même, mais des blocs écrits puis jamais relus. Il dépend directement du profil de la charge.

Dans quels cas le surcoût d’écriture fait-il perdre de l’argent ?

Lorsque le préfixe change plus vite qu’il ne se répète. Nous avons mesuré le ratio de tokens lus sur les tokens écrits dans cinq scénarios d’agents, avec les mêmes modèles et la même stratégie de marquage. Nous avons ensuite calculé l’effet net du cache aux tarifs de 1.25x/0.1x :

La ligne RAG est la plus importante. Les documents récupérés changent à chaque requête. Chaque appel réécrivait donc un préfixe inutilisable par l’appel suivant : cinq tokens écrits pour un seul relu. Le surcoût de 1.25x finit alors par produire une perte nette. Il ne s’agit pas d’une erreur de configuration ; cette charge ne permet tout simplement pas d’amortir l’écriture. La solution consiste à séparer les couches plutôt qu’à désactiver entièrement le cache. Marquez le prompt système et les définitions d’outils, qui restent stables entre les requêtes, puis placez les documents récupérés après le dernier seuil, sans les marquer. La même règle s’applique à toutes les données volatiles : timestamps, noms d’utilisateur et contexte propre à chaque requête. Elle vaut aussi pour les réglages qui invalident silencieusement le préfixe. Modifier output_config.effort entre deux tours entraîne un nouveau rendu du prompt et invalide le cache. L’effort doit donc rester constant au sein d’une session mise en cache. Notre étude sur LangChain a trouvé le même problème côté framework : certains builders permettent de tout marquer aussi facilement que de ne marquer que les bons éléments.

À quelle fréquence l’écriture est-elle réellement refacturée ?

Une fois par période d’inactivité, et non une fois par fenêtre de TTL, car chaque hit réinitialise gratuitement le compteur. Nous l’avons vérifié avec un préfixe salé de 4,981 tokens sur Claude Opus 4.8 :

L’appel 4 intervient bien après l’expiration du TTL initial de 5 minutes et lit pourtant correctement le cache, car les appels 2 et 3 ont chacun renouvelé gratuitement la fenêtre. Seules les 7 minutes d’inactivité ont imposé une nouvelle écriture. Conséquence pratique : sur une route dont l’intervalle entre les requêtes reste inférieur au TTL, le surcoût d’écriture n’est payé qu’une fois et le tier de 5 minutes se comporte comme un cache sans limite de durée. Le tier d’une heure, avec une écriture à 2x dont nous avons vérifié la facturation dans son propre bucket ephemeral_1h_input_tokens via la gateway, vise les autres profils de trafic. Payer 2x une seule fois revient moins cher que 1.25x plusieurs fois dès qu’une seule réécriture est évitée. Il convient donc aux routes dont les périodes d’inactivité durent entre cinq minutes et une heure. Après plus d’une heure sans trafic, aucun des deux tiers ne permet de réutiliser le cache entre les exécutions. Pour une tâche planifiée, le budget doit se calculer selon ce qui se passe pendant une exécution : un cron qui envoie une seule requête ne gagne rien à écrire dans le cache ; un cron qui lance de nombreuses requêtes partageant le même préfixe est simplement un batch et bénéficie du cache de la même manière.

Peut-on améliorer le cache implicite en adaptant le trafic ?

Tout dépend du cache implicite du provider, car les garanties best-effort couvrent des réalités très différentes. Parmi les meilleurs résultats, le cache automatique de GPT-5.5 s’est comporté comme un mécanisme fiable : après un appel d’amorçage, l’entrée était lisible deux secondes plus tard, avec un hit dès la première sonde pour les deux sels testés. Lors d’une rafale suivante, 4,864 tokens sur les 5,170 du prompt ont été servis depuis le cache sur sept sondes sur huit, sans aucun surcoût. C’est une économie nette qui ne demande rien d’autre que l’envoi du même préfixe deux fois. À l’autre extrémité se trouve Gemini 3.6 Flash : dans la même suite d’agents, où le cache explicite servait 77-78% des tokens d’entrée de Claude, le cache implicite de Gemini n’en servait que 4%, alors même que les préfixes se répétaient réellement.

Nous avons tenté d’améliorer les moins bons résultats en adaptant le trafic : regrouper les appels partageant le même préfixe afin que le cache du provider reste chaud. Sur Gemini 3.6 Flash, douze appels consécutifs n’ont produit qu’un seul hit, lors de l’appel 10 ; l’appel 11 a de nouveau manqué le cache. Huit appels espacés de 3 minutes n’en ont produit aucun. Pour écarter un résultat accidentel, nous avons relancé la série regroupée sur un second chemin de requête indépendant, puis sur Gemini 3.5 Flash. Les résultats ont été respectivement de trois hits et d’un hit sur douze. Les hits ne se sont jamais enchaînés longtemps, et le seul bloc mis en cache est revenu avec les mêmes 4,073 tokens sur les deux chemins. Le fonctionnement est cohérent, pas la probabilité d’un hit.

Une partie des échecs vient du délai d’ingestion, qui varie selon le provider. L’entrée de GPT-5.5 était lisible deux secondes après l’amorçage, tandis que Gemini met plusieurs dizaines de secondes à construire la sienne. Les rafales envoyées immédiatement après le premier appel arrivent donc trop tôt pour son cache. Dans tous nos tests Gemini, aucun hit n’est survenu avant le quatrième appel. Amorcer une fois le préfixe, puis attendre 45 secondes avant la rafale, a porté le résultat à 3 hits sur 8, soit le meilleur score obtenu en adaptant le trafic. Après 90 secondes d’attente, le résultat est retombé à zéro sur 8 : l’entrée avait déjà disparu à notre retour. Quelques jours plus tôt, une série de préchauffage plus longue sur le même modèle avait maintenu les hits. Le taux varie donc également dans le temps et selon la charge. Entre le délai de construction, la faible durée de vie et cette variabilité, le regroupement n’améliore les moins bons résultats que dans la mesure où trois hits valent mieux qu’un. (Pour tester un cache implicite, espacez les appels, ajoutez un scénario avec amorçage suivi d’une attente, et mesurez directement le délai de construction avec des sondes successives après l’amorçage. Des appels envoyés sans pause mesurent surtout votre débit de requêtes, pas le cache.)

La règle doit donc être définie par provider, et non par type de mécanisme. Mesurez si le cache implicite se comporte comme celui de GPT-5.5, qu’il suffit d’amorcer avant de lui faire confiance, ou comme celui de Gemini, où chaque hit doit être considéré comme une remise ponctuelle. Kimi K3 se situe entre les deux : aucun surcoût, un minimum peu élevé, et 57-62% des entrées servies depuis le cache sans configuration. Un constat indique clairement quelle approche l’emporte : OpenAI disposait du meilleur cache implicite de nos mesures, mais a tout de même adopté des seuils explicites avec GPT-5.6. Le provider a remplacé une remise automatique sans garantie par des marqueurs contrôlés par le client.

Quelles charges amortissent le surcoût ?

La décision dépend du ratio lecture:écriture et de la période d’inactivité. Ces deux valeurs peuvent être calculées à partir de vos propres données d’usage avant de vous engager :

Les mesures conduisent à deux règles finales. Premièrement, évaluez le cache en comparant cache_read à cache_creation dans le détail de votre propre consommation, et non selon l’impression que les hits sont fréquents. Le scénario RAG semblait adapté au cache, mais son ratio mesuré n’était que de 0.2. Deuxièmement, lorsque le ratio est bon, le surcoût devient négligeable : avec un ratio lecture:écriture de 3.5, celui de l’ensemble de la suite, le coût du préfixe baisse de 64%, toutes les écritures comprises.

FAQ

Le prompt cache est-il rentable pour le RAG ?

Pas pour les documents récupérés. Dans nos mesures, le RAG écrivait cinq tokens pour chaque token relu, transformant le surcoût de 1.25x en perte nette de 6%. Mettez en cache les couches stables, c’est-à-dire le prompt système et les définitions d’outils, puis placez le contenu récupéré après le dernier seuil. Le guide complet du prompt cache décrit en détail cette organisation en couches.

Faut-il choisir un TTL de cache de 5 minutes ou d’une heure ?

Choisissez selon la durée des périodes d’inactivité, pas celle des sessions. Les hits rafraîchissent gratuitement le TTL de 5 minutes. Une route dont les requêtes sont espacées de moins de 5 minutes ne réécrit donc jamais le cache, et le tier le moins cher fonctionne sans limite de durée. Ne payez l’écriture à 2x du tier d’une heure que lorsque les pauses durent entre cinq minutes et une heure ; il devient rentable dès qu’il évite une seule réécriture à 1.25x. Au-delà d’une heure sans trafic, calculez le budget comme s’il n’y avait aucun cache.

Le cache implicite facture-t-il des frais d’écriture ?

Non, et sa structure ne le permet pas : un surcoût d’écriture n’a de sens que si l’appelant choisit d’activer le cache. Ces surcoûts n’existent donc que pour les mécanismes explicites, avec les multiplicateurs de 1.25x/2x d’Anthropic, les seuils de GPT-5.6 et le stockage facturé des API de contenu explicitement mis en cache, comme le tarif par token-heure de Gemini. Toutes les implémentations implicites que nous avons mesurées, Gemini, Kimi et les modèles OpenAI antérieurs à 5.6, ainsi que les principaux tarifs publiés par DeepSeek, Qwen et Grok, facturent uniquement les lectures implicites à prix réduit. Seule la fiabilité varie : le cache implicite de GPT-5.5 a maintenu 7 hits sur 8 sondes après amorçage, tandis que celui de Gemini a servi 4% des entrées dans notre suite d’agents et que le regroupement des appels n’a presque rien changé. Une remise fiable sans aucun surcoût est la meilleure option. Une remise aléatoire vaut moins qu’un faible surcoût pour un mécanisme que vous contrôlez.

Mesures réalisées du 2026-07-25 au 2026-07-29 via la gateway Synthorai : ratios lecture:écriture des scénarios calculés sur 150 épisodes d’agents exécutés avec Claude, avec ventilation du cache par appel ; parts de Gemini et Kimi tirées de leurs propres exécutions de la suite ; sondes de rafraîchissement du TTL et du bucket d’une heure sur claude-opus-4-8, avec des préfixes salés de 4,981 et 3,742 tokens ; sondes du cache implicite sur gemini-3.6-flash et gemini-3.5-flash, avec des préfixes salés d’environ 6,800 tokens et des scénarios regroupés, espacés ou avec amorçage suivi d’une attente, ainsi que sur gpt-5.5 avec un prompt salé de 5,170 tokens et une rafale après amorçage. Les pourcentages d’effet net ont été calculés à partir des ratios mesurés avec des multiplicateurs de 1.25x en écriture et 0.1x en lecture. Les tarifs et le comportement du cache peuvent changer ; vérifiez-les dans vos propres données d’usage.

← Retour au blog