Les erreurs de mise en cache des invites peuvent coûter à votre organisation près de 6x plus à chaque tour d’IA

Depuis, j’ai compris une partie de la raison. Une personne peut revenir à une conversation le lendemain, et quel que soit le moment où la conversation a commencé, il est devenu obsolète. Il faut le fournir à nouveau. Un harness, le programme autour d’un modèle qui assemble chaque requête et exécute la boucle, peut le faire en écrivant l’heure actuelle dans les instructions du modèle avant chaque requête. Le runner d’agent que nous utilisons en production a fait exactement cela.

Je connaissais la mise en cache d’invite depuis longtemps. Les fournisseurs stockent le début d’une requête et le facturent à une fraction du prix lorsque la prochaine requête commence de la même manière. Je ne connaissais pas bien ses mécanismes pour voir ce qu’une ligne comme l’heure lui fait. Nous sommes tombés sur la réponse dans nos propres coûts de production, et j’ai dirigé une série d’expériences pour la mesurer correctement, à travers un modèle actuel de chacun des 4 labs et contre les chiffres publics de OpenRouter pour ce que tout le monde paie.

La réponse est coûteuse. Sur GPT-6 Luna, l’heure écrite à mauvais endroit faisait que chaque tour d’une conversation coûtait 5.7× ce qu’il fallait, et rien n’a déclenché d’erreur. À travers les organisations de trafic, ces modèles sont envoyés, l’entrée est 96–99% des jetons et 66–87% des dollars réellement payés, donc le cache décide de la plupart de la facture. Pour une organisation qui construit son propre harnais, qui exécute une plateforme IA interne ou qui expédie des produits IA, une erreur comme celle-ci multiplie le coût de chaque tour, silencieusement, tant qu’elle fonctionne.

Chaque nombre par tour ici a été mesuré le 23 septembre 2026, à travers OpenRouter. Les chiffres du marché sont les propres de OpenRouter, lus le même jour.

Chaque appel à un modèle envoie toute la conversation à nouveau : les définitions d'outils, le prompt système (les instructions permanentes que le harnais écrit), chaque tour précédent, et le nouveau message.

Les fournisseurs gardent le début traité des requêtes récentes. Lorsque la prochaine requête commence par le même texte, le fournisseur lit ce préfixe stocké au lieu de le traiter à nouveau. Sur GPT-6 Luna, OpenRouter facturait une lecture à 0.10× le prix d'entrée indiqué et la première écriture à 1.25×. Un prompt qui est réécrit à chaque tour coûte donc plus qu'un prompt sans cache du tout.

Seul le début d'une requête peut être réutilisé. Un changement à tout moment annule tout ce qui suit :

graph LR
    A[Définitions d'outils] --> B[Prompt système]
    B --> C[Tours précédents]
    C --> D[Nouveau message utilisateur]
    B -. a changed line here voids B, C and D .-> D

Tout ce que le harnais écrit près du début et change à chaque tour met toute la conversation derrière lui à risque. L'heure actuelle est l'exemple le plus simple.

La découverte a commencé dans un agent que nous exécutons en production. Son registre de coûts évaluait chaque appel au prix de liste et ne montrait aucune mise en cache du tout. J’ai déclenché l’alarme et commencé à envisager un passage à un modèle différent.

L’agent avec lequel je travaillais a d’abord constaté que le registre lui‑même était erroné. Sur 33 appels il estimait $0.064 ; le fournisseur avait facturé $0.023, 2.7× moins. Évaluer chaque appel à partir des comptes de tokens avait effacé toutes les remises que le fournisseur appliquait. Lire le coût signalé par le fournisseur a montré que la mise en cache fonctionnait à l’intérieur de chaque tour et échouait au début de chaque nouveau tour.

Sa première explication était une clé de session manquante qui garderait les requêtes sur le même serveur. Sa propre enquête l’a réfuté : des invites identiques déjà lues depuis le cache à travers les tours sur GPT-6 Luna, et l’ajout d’une clé de session, d’une clé de cache ou d’un marqueur de cache explicite n’a rien changé. La cause résidait dans le prompt système lui‑même. À environ 95% du chemin d’entrée, le runner écrivait deux lignes qui changeaient à chaque tour : un répertoire de travail par tour et une horloge à la minute. Chaque premier appel d’un tour écrivait le prompt complet à nouveau à 1.25×.

Déplacer les deux lignes à la fin du message de l’utilisateur l’a corrigé en production. Les tours 2 et 3 s’ouvrent maintenant à 0.47–0.51× au lieu de 1.25×. Le reste est un bloc de contexte par tour que le runner envoie toujours dans le message de l’utilisateur.

Mon hypothèse, avant que rien de tout cela ne soit mesuré, était qu’une vérification déterministe pourrait fournir le temps uniquement lorsqu’il était obsolète, sous forme de message séparé, et laisser le reste de l’invite en cache. Elle fonctionne, à une condition, et cette condition est la règle sur laquelle le reste de l’article repose.

Pour la tester directement, nous avons construit un sondage qui exécute la même conversation avec l’horloge à différents endroits, les séparant de 65 secondes afin que la minute change entre chaque paire. GPT-6 Luna, un prompt système de 8.5K jetons, 3 reproduit :

Mon message séparé a conservé le cache dans les deux formes, à chaque tour et uniquement lorsqu’il est obsolète. La condition est où le message se trouve. Après les instructions stables, le fournisseur lit tout ce qui le précède. En tant que deuxième message système, il se trouve parmi les instructions, et GPT-6 Luna a réécrit tout le prompt à nouveau sur 12 de 12 tours.

La règle qui suit est courte. Tout ce qui change entre les tours vient après tout ce qui ne change pas.

Le cache compare le texte, donc une horloge est inoffensive tant que son texte reste le même. Dans le même sondage avec des intervalles de 4 secondes, une horloge minute dans l’invite système lisait le cache à chaque fois. Avec des intervalles de 65 secondes, elle forçait une réécriture complète à chaque tour.

La résolution détermine à quelle fréquence cela se produit. Une horloge heure et une ligne de date dans l’invite système lisent toutes les ouvertures de tour de 12 de 65 secondes, car aucune ne s’est écoulée. Elles se cassent aussi, une fois par heure et une fois par jour. Une horloge minute se casse à chaque tour qui commence dans une minute plus tard que le précédent.

Le cache lui‑même expire également. Dans des exécutions ponctuelles, GPT-6 Luna lisait toujours son préfixe stocké après 30 minutes d’inactivité et réécrivait tout l’invite à 1.25× après 60. DeepSeek V4.1 Flash lisait après 10 minutes et manquait après 60. Claude Opus 5.5 avait déjà manqué après 10, puisque le cache par défaut d’Anthropic dure 5 minutes et son cache de 1 heures coûte 2× à écrire. La personne qui revient à une conversation le lendemain, le cas que cet article a commencé, trouve à la fois un temps obsolète et un cache froid sur les trois. Ce premier retour de tour paie pour l’ensemble de l’invite peu importe ce que fait le harnais. Le placement décide si les tours après lui le font aussi.

GPT-6 Luna est la réponse d’un fournisseur. Pour voir dans quelle mesure la leçon est générale, nous avons exécuté les mêmes placements sur un modèle actuel de chaque laboratoire 4, avec une invite identique de 2.5K jetons, chacun fixé à un seul fournisseur :

GPT-6 Luna met en cache les messages complets. Une ligne modifiée annule le message qui la contient et tout ce qui suit.

Claude Opus 5.5 met en cache là où l’appelant le marque. Les modèles d’Anthropic ne mettent en cache que jusqu’à un marqueur cache_control que le harnais place. Sans marqueur, la même invite facturait le prix complet à chaque appel. Avec le marqueur dans l’invite système, une horloge à l’intérieur de ce bloc coûtait 1.24×, tandis qu’une horloge dans un second message système après elle lisait à 0.08×. Le placement que GPT-6 Luna pénalise est sûr sur Opus. À prix Opus, la différence par ouverture de tour était $0.0214 contre $0.0023. Opus comptait également l’invite identique comme 4,056 jetons alors que GPT-6 Luna comptait 2,395, donc le même texte coûte 1.69× plus de jetons avant toute application de prix.

DeepSeek V4.1 Flash met en cache en blocs de 256 jetons et ne facture rien de plus pour écrire. Les lectures revenaient en multiples exacts de 256 : 2 560 jetons pour l’invite inchangée, 2 304 avec l’horloge à la fin de l’invite système. Une ligne modifiée ne coûte que le bloc qui la contient. Les premiers appels étaient facturés au prix d’entrée simple, et les lectures à 0.03–0.04×. Sur 8 exécutions par placement, 2 appels uniques ont manqué le cache à un tour que la même exécution a ensuite lu, ce qui se lit comme la requête atterrissant sur un serveur différent plutôt que comme un effet de placement. Le propre point de terminaison de DeepSeek est le seul OpenRouter marqué comme mettant en cache automatiquement, et le paramètre de confidentialité de mon compte l’exclut parce que ce point de terminaison entraîne sur le trafic payant. Les exécutions ont passé par DeepInfra, qui a mis en cache, ainsi que Fireworks et Morph dans une vérification à 2 appels.

Muse Spark 1.3 lit son cache dans une boucle d’outil et manque au début de chaque nouveau tour. Nos premières enquêtes, qui posent une question fraîche contre la même invite système, ont servi au maximum 113 jetons du cache en 10 appels, à 2.9K, 8.9K et 19.4K jetons. Lorsqu'un appel de suivi étend la demande précédente, comme le fait la boucle d'outils d'un agent, Muse lit 2,801 de 2,966 tokens et facture 0.17×. Le prochain tour de l'utilisateur, avec tout l'historique devant lui, ne lit rien. OpenRouter rapporte un taux de cache 86.1% pour Muse sur le trafic en direct, ce qui correspond à une charge de travail dominée par les boucles d'outils. Au début d'un tour, l'horloge ne fait aucune différence sur Muse, puisque cet appel rate de toute façon.

La même décision de harnais coûte un montant différent sur chaque modèle. Savoir quel mécanisme votre fournisseur utilise vient avant d'ajuster quoi que ce soit.

Nous nous attendions à ce que les tours mis en cache répondent plus rapidement. Sur 10 paires séquentielles d'appels GPT-6 Luna à 8.5K jetons, l'appel initial médian a pris 437 ms depuis le cache et 490 ms sans celui-ci. Cet écart se situe dans la dispersion des échantillons. À cette taille, la mise en cache change le coût d'un tour et laisse la durée d'exécution à peu près la même.

Donc la pause que je me souviens lorsque je demande l'heure a une autre cause. Ce qu'un horloge dans le mauvais endroit coûte, c'est de l'argent.

Une horloge dans l’invite système se trouve devant toute la conversation, donc chaque réécriture couvre l’historique croissant derrière elle ainsi que les instructions. Voici le coût mesuré d’une conversation GPT-6 Luna à 12 tours, avec la facture complète fournie par le prestataire, incluant la sortie et les appels dans chaque tour :

Les deux lignes partagent leur premier tour, lorsque les deux écrivent le cache. À partir de là, chaque tour avec l’horloge dans l’invite système coûte 5.7× ce que le même tour coûte avec l’horloge à la fin du message utilisateur. Au tour 12 la conversation avait coûté 4.1× autant, et l’écart s’élargit à chaque tour.

Des fractions de cent deviennent un poste de dépense à grande échelle. Cette projection tarifie le premier appel de chaque tour pour un produit servant 10,000 conversations par jour, chacune avec une invite système de 8.5K tokens, 20 tours, et un historique croissant de 1,500 tokens par tour. Chaque modèle utilise son prix indiqué et le comportement de cache qu’il a montré ci‑dessus :

Les blocs de DeepSeek gardent l'invite système lorsque l'horloge change, et le modèle reste toujours 13× plus cher, car l'historique derrière l'horloge dépasse les instructions en quelques tours. Muse Spark montre l'autre côté : il a manqué au début de chaque tour dans nos exécutions, donc le placement n'a rien économisé là et chaque ouverture de tour a payé le plein prix, $2.1M par an pour le même trafic.

Nos mesures utilisent une invite contrôlée. OpenRouter publie ce que les mêmes modèles coûtent sur le trafic de tout le monde, et le même mécanisme apparaît là à grande échelle. Presque tout ce qui est envoyé à ces modèles est une entrée : 96,3 % des jetons de GPT-6 Luna le premier jour, 98,5 % de Claude Opus 5,5 et DeepSeek V4,1 Flash, et 98,9 % de Muse Spark 1,3. L'entrée est là où la mise en cache s'applique, donc le taux de réussite détermine la majeure partie de ce qu'une entreprise paie.

Les clients ont payé $0.87 par million de jetons d'entrée pour Claude Opus 5.5 contre un tarif listé $4.00, $0.30 contre $1.25 pour Muse Spark 1.3, et $0.036 contre $0.10 pour GPT-6 Luna. Sur les points de terminaison qui servent le même modèle le même jour, le prix payé suit le taux de réussite :

En tarif chaque échec comme une écriture de cache et chaque réussite comme une lecture prédit les prix publiés de chaque point de terminaison principal 5 à 2–13%. Le taux de réussite seul explique la dispersion. Sur GPT-6 Luna, le même schéma s'étend de $0.025 à un taux de réussite 88.1% jusqu'à $0.075 à 49.4%, un facteur de 3.

La même décision de placement se manifeste différemment sur chaque type d’organisation qui construit sur ces API.

Les constructeurs de harness définissent le taux de réussite pour chaque utilisateur en même temps. Les 5 applications qui ont envoyé Claude Opus 5.5 le plus de trafic le premier jour étaient toutes des agents, entre 2.9B et 16.3B tokens chacun. Pour un harness à 10B tokens d’entrée par jour sur ce modèle, chaque point de taux de réussite du cache vaut $175K par an. L’écart entre les points de terminaison 92.2% et 77.4% ci‑dessus s’élève à $2.07M par an à ce volume. Un horloge dans le prompt système qui réécrit chaque tour d’ouverture coûte entre $1.75M et $8.76M par an, selon que les ouvertures de tour soient 1 appel en 10 ou 1 en 2. La décision voyage également : chaque produit construit sur un harness hérite de son placement. En rédigeant ceci, nous avons trouvé la même horloge de prompt système dans un second harness de nous, qui exécute une version plus ancienne du même runner.

Les entreprises qui exploitent une plateforme IA interne la définissent pour chaque équipe derrière elles. Un gateway qui tamponne le prompt système de chaque requête avec un horodatage ou un ID de requête pour l’audit transforme chaque ouverture de tour d’application en écritures, quelle que soit la construction des équipes en haut. La comptabilité est la deuxième exposition. Facturé au prix de liste, les coûts d’entrée semblent 2.8× plus grands que la facture sur GPT-6 Luna, 4.1× sur Muse Spark 1.3 et 4.6× sur Claude Opus 5.5. Notre propre grand livre surestimait les appels 33 de 2.7×, et je suis arrivé près de changer de modèle sur la base de cela.

Les entreprises qui livrent des produits IA le paient à chaque conversation. Dans une conversation, le coût de l’horloge mal placée est de 5.7× par tour. Sur un marché, les enjeux sont plus grands. Le 21 septembre, Muse Spark 1.3 a traité 88,5 B tokens d’entrée via OpenRouter. Au prix de liste, cela représente $110.6K ; les clients ont payé $26.9K, et chaque point de taux de réussite sur ce trafic vaut $355K par an. DeepSeek V4.1 Flash a pris 2,68 T tokens d’entrée le même jour, et aux prix de DeepInfra chaque point vaut $1,33 M par an. Ces chiffres couvrent un seul router. Le trafic envoyé directement aux fournisseurs n'apparaît pas dans eux.

Chacun de ces coûts remonte au même mécanisme, et la solution en découle. Les conventions des harness d’agents bien construits se lisent comme leurs conséquences :

La correction ci‑dessus est une seule modification. Les conditions qui l’entourent continuent de bouger. Un harnais obtient un nouveau crochet, une passerelle commence à tamponner les requêtes avec un ID, une équipe passe à un modèle avec un mécanisme de cache différent, un fournisseur change la durée pendant laquelle un préfixe inactif reste chaud. Les quatre modèles ici mettent en cache de quatre façons différentes, et Claude Opus 5.5 laisse un cache se refroidir en 10 minutes d’inactivité. Le deuxième harnais où nous avons trouvé la même horloge était simplement resté sur une version plus ancienne. Rien de tout cela ne déclenche une erreur.

Chaque appel renvoie déjà ce qu’il faut pour le voir : tokens de prompt, tokens mis en cache, tokens d’écriture en cache et le coût facturé. Enregistré par appel, avec si l’appel a ouvert un tour ou en a continué un, ces champs donnent trois nombres à surveiller pour chaque route et modèle :

Un seuil sur ces chiffres attrape une chute soudaine. Nommer la cause sur des semaines de données est un problème de classification, et une nouvelle classe de modèle y convient. Jev, de TypeSafe, est ce que son créateur appelle un modèle System One. Il ne génère pas de texte. Il prend un état et des questions typées et renvoie des réponses typées avec une distribution de probabilité et une confiance : un choix parmi les options, une probabilité de oui, ou une position sur une échelle ordonnée. En fonction du profil de cache quotidien d’une route, il peut nommer le motif que le jour correspond (sain, réécriture d’ouvertures de tours, expiration du cache entre les tours, trafic atteignant un point de terminaison qui ne met pas en cache) et dire à quel point il en est sûr, de sorte qu’un changement de catégorie devienne l’alerte. Nous l’utilisons en production pour classer des documents et, en observation, pour évaluer les épisodes d’agents terminés. OpenRouter l’indique à $0.042 par million de tokens d’entrée sans frais pour la sortie. À ce prix, classifier un profil quotidien de 2K tokens pour chacune des 1,000 routes coûte environ $31 par an, contre $175K par an pour un seul point de taux de réussite à l’échelle du harnais ci‑dessus.

Un système qui continue de réécrire son cache paie la prime à chaque tour de chaque conversation, tant qu’il fonctionne, et la facture indique rarement pourquoi. La correction peut être aussi petite que l’endroit où l’heure est écrite. Le maintenir fixe prend un nombre que quelqu’un regarde.

Chaque chiffre mesuré ci‑dessus provient des champs par appel propres à OpenRouter (jetons mis en cache, jetons d’écriture en cache et coût facturé) le 23 septembre 2026. Les chiffres de marché proviennent des pages publiques du modèle de OpenRouter lues ce jour-là : le prix d’entrée pondéré réellement payé, le prix effectif de chaque point de terminaison et le taux de réussite du cache, ainsi qu’un jour d’activité de jetons par modèle. Claude Opus 5.5 et GPT-6 Luna ont été lancés le 22 septembre, leurs chiffres d’activité couvrant donc un premier jour partiel, et l’article ne les utilise que comme parts. Les expériences ont coûté $0.63 au total, et le sondage a refusé de démarrer une fois que l’utilisation du compte approchait un plafond $1. Les prix sont les prix affichés par OpenRouter lus le même jour. Le guide de mise en cache d’OpenRouter indique OpenAI lectures de cache à 0,25–0,50× ; GPT-6 Luna facturait ses lectures à 0,10×, et cet article rapporte ce qui a été facturé.

Toujours ouvert : le point exact auquel le cache inactif de chaque modèle expire, qui exécutions ponctuelles ne délimitent que les intervalles ; à quelle fréquence une horloge horaire ou de date se rompt sur de réelles lacunes de conversation ; pourquoi Muse Spark a manqué au début de chaque tour lorsque son historique était inchangé ; et le comportement de DeepSeek sur son propre point de terminaison. La correction par tour est en production dans notre agent, et la même découverte a été mise en file d’attente pour un deuxième harnais qui exécute une version plus ancienne du même lanceur.

Par moi. La question derrière l’article : pourquoi l’IA ne semblait jamais connaître la date et l’heure correctement, et prenait des secondes pour les dire alors qu’elle devrait être instantanée. L’idée que le temps devient obsolète au cours d’une session et doit être fourni à nouveau, mon hypothèse qu’un message déterministe, uniquement lorsqu’il est obsolète, laisserait le prompt en cache, et l’appel pour le tester par expérience. Le cadre de coût : quantifié pour les entreprises qui construisent sur ces modèles, des constructeurs d’harness aux entreprises qui gèrent leurs propres plateformes IA internes, tel qu’il se présente aujourd’hui et à mesure qu’il se cumule. La clôture sur l’observation continue, avec un modèle System One tel que Jev classifiant le profil de cache au fil du temps, car la correction ne tient que tant que quelqu’un continue de surveiller.

Par Claude Opus 5.5. Il a découvert que notre grand livre des coûts cachait le caching, 2.7× sur les appels 33, et a tracé la cause aux lignes 2 du prompt système qui changeaient à chaque tour. Il a construit la correction du runner qui est maintenant en production, le probe, l’analyse, et le modèle de coût derrière chaque chiffre ici, et a comparé le mécanisme aux chiffres de marché publics de OpenRouter. À travers les modèles 4 il a identifié 3 différents comportements de cache, y compris le comportement de message complet de GPT-6 Luna, et un quatrième modèle sans cache utilisable.