Tarification de l’entrée mise en cache pour GPT 5.6 et Gemini 3.6 Flash : ce que ça coûte

DR

La tarification des entrées mises en cache peut réduire sensiblement le coût des charges de travail qui renvoient un long préfixe de prompt inchangé, mais les économies dépendent des règles spécifiques au modèle pour la lecture, l’écriture, le stockage, le routage et la rétention du cache. Un simple label « mise en cache prise en charge » ne suffit pas à estimer le coût ; utilisez le prix actuel publié pour le modèle et la route exacts.

TL;DR

• GPT-5.6 Terra dispose de tarifs explicites de lecture et d’écriture de cache chez OpenAI, CometAPI et OpenRouter, bien que les routes des passerelles et les paliers « long-context » puissent changer le montant.
• Google publie un tarif de mise en cache de contexte Standard de 0,15 $ par 1 M de jetons pour Gemini 3.6 Flash plus un coût de stockage ; CometAPI publie actuellement les tarifs d’entrée et de sortie standard du modèle sans ligne séparée pour l’entrée mise en cache.
• La comparaison pertinente n’oppose pas seulement l’entrée standard à la lecture de cache. Elle inclut aussi la première écriture de cache, tout coût de stockage, la durée de vie du cache, la constance de la route et le nombre d’accès ultérieurs au cache.

Key messages

• Vérifiez les prix au niveau du modèle et du niveau de service plutôt que d’appliquer un multiplicateur à l’échelle de la passerelle.
• Séparez lecture de cache, écriture de cache, stockage et mise en cache des réponses dans les calculs de coût.
• Vérifiez l’usage réel du cache dans les métadonnées de réponse API avant de prévoir des économies à partir du tarif publié.

Une requête qui répète un grand préfixe inchangé — une invite système, un ensemble de schémas d’outils, un long document de référence — n’a pas à être facturée au tarif d’entrée complet à chaque appel. La plupart des modèles de dernière génération prennent en charge une forme de tarification des entrées mises en cache : un tarif réduit pour la portion d’un prompt qu’un fournisseur reconnaît comme déjà traitée. Le mécanisme, l’ampleur de la remise et la clarté de la publication varient selon le fournisseur et la passerelle, et cette variation mérite d’être précisée plutôt que de traiter « la mise en cache est prise en charge » comme une fonctionnalité uniforme.

What cached input pricing is, and isn't

La tarification des entrées mises en cache applique une réduction aux jetons d’entrée d’une requête qui correspondent à un préfixe précédemment envoyé. Elle ne réduit pas les jetons de sortie, et ce n’est pas la même chose qu’une passerelle dédupliquant deux requêtes totalement identiques et renvoyant une réponse gratuitement — c’est un mécanisme différent que certaines passerelles proposent séparément. La tarification des entrées mises en cache consiste spécifiquement à payer moins pour la partie d’un prompt qu’un fournisseur de modèle a déjà vue récemment, pas à éviter la génération.

Ce n’est pas non plus gratuit à créer. Les notes de tarification GPT-5.6 d’OpenAI indiquent que les écritures de cache sont facturées à 1,25 fois le tarif d’entrée non mis en cache, tandis que les lectures de cache bénéficient d’une remise de 90 %. Cette prime de première écriture affecte le point mort et est facile à manquer si une comparaison n’affiche que le tarif de lecture remisé. D’autres fournisseurs peuvent utiliser des frais basés sur le stockage au lieu du même modèle d’écriture ; les coûts d’écriture et de stockage doivent donc être vérifiés séparément.

En pratique, l’unité de cache facturable est généralement un préfixe de prompt réutilisable plutôt qu’un ensemble arbitraire de phrases répétées. Les fournisseurs tokenisent et correspondent le contenu dans l’ordre, de sorte que le matériel réutilisable doit apparaître avant la partie variable de la requête. Les instructions système stables, définitions d’outils, politiques et documents de référence appartiennent au début ; un message utilisateur changeant, un horodatage, un ID de requête ou un extrait récupéré doivent venir plus tard. Même un changement sans incidence sémantique près du début peut modifier la tokenisation ou casser la correspondance pour tout ce qui suit.

Les règles d’éligibilité sont également spécifiques au modèle. Un fournisseur peut exiger une longueur minimale de prompt, ne reconnaître que des points de coupure documentés ou exposer un champ explicite de contrôle de cache. Une entrée de cache peut expirer entre deux appels, et une passerelle peut avoir besoin de conserver des requêtes liées sur une route amont compatible. Cela signifie qu’un déploiement doit considérer un hit de cache comme un résultat observé, pas comme une hypothèse basée sur la similarité des prompts. Un prompt bien structuré améliore la probabilité de réutilisation, mais ce sont les métadonnées de réponse et la facture qui déterminent si le tarif réduit a réellement été appliqué.

What's actually published, by model and by gateway

Le tableau ci-dessous est une capture des tarifs vérifiée le 29 juillet 2026. Les prix sont en dollars US par 1 million de jetons, sauf mention contraire. Les lignes comparent les informations publiques actuelles pour GPT-5.6 Terra et Gemini 3.6 Flash chez le fournisseur du modèle, CometAPI et OpenRouter ; elles ne doivent pas être considérées comme un tarif permanent.

Interprétez le tableau comme une capture spécifique au modèle et à la route. La page modèle GPT-5.6 de CometAPI détaille GPT-5.6 Terra à 2,00 $ d’entrée standard, 0,20 $ d’entrée mise en cache et 2,50 $ d’écriture de cache par 1 million de jetons. Sa page modèle Gemini 3.6 Flash publie actuellement 1,20 $ d’entrée et 6,00 $ de sortie, mais n’affiche pas de tarif séparé pour l’entrée mise en cache ni le stockage du cache. La tarification de l’API Gemini Developer de Google liste le niveau Standard à 1,50 $ d’entrée, 0,15 $ pour la mise en cache de contexte, et 1,00 $ par 1 million de jetons par heure pour le stockage. OpenRouter expose désormais des champs de cache spécifiques au modèle via son Models API : la route par défaut de GPT-5.6 Terra inclut un tarif promotionnel plus bas et un palier séparé plus élevé pour le contexte long, tandis que son entrée Gemini 3.6 Flash expose des valeurs différentes pour Standard, Flex et Priority. C’est plus précis que d’appliquer un multiplicateur de cache générique à chaque modèle.

Pourquoi les prix des passerelles et des fournisseurs peuvent diverger

Le prix d’une passerelle n’est pas nécessairement une majoration d’un tarif amont immuable. Il peut refléter une capacité négociée, une promotion temporaire, un niveau de service différent, ou un accord commercial spécifique à une route. Un nom de modèle peut également correspondre à plusieurs variantes amont dont les prix changent avec la longueur de contexte ou les garanties de latence. L’entrée OpenRouter de GPT-5.6 Terra, par exemple, publie une route par défaut et une substitution à prix plus élevé une fois le seuil de contexte long atteint. Google sépare les prix Standard, Batch, Flex et Priority pour Gemini 3.6 Flash. Une seule ligne de comparaison a donc besoin d’une date, d’une route, d’un niveau et d’une hypothèse de contexte pour rester significative.

L’inverse est également important : si la page d’une passerelle ne publie pas de ligne séparée pour la lecture de cache, cette absence ne doit pas être interprétée comme « la mise en cache est indisponible » ou « la remise directe du fournisseur s’applique automatiquement ». La passerelle peut transmettre une fonctionnalité amont sans l’itemiser, ne l’exposer que sur certaines routes, ou facturer la requête à son tarif d’entrée normal. L’approche défendable consiste à utiliser la page modèle actuelle de la passerelle pour la planification, puis à confirmer le taux réel à partir des relevés d’usage ou des données de facturation. La documentation du fournisseur reste utile pour comprendre le mécanisme, mais n’établit pas à elle seule les conditions commerciales d’un intermédiaire.

Où la remise a réellement un impact

Le scénario où cela change concrètement le coût est un grand préfixe statique associé à une petite requête variable — une invite système ou un ensemble de schémas d’outils renvoyés à chaque appel dans une boucle d’agent, un long document de référence interrogé à plusieurs reprises avec des questions différentes, ou un historique de conversation renvoyé à chaque tour de chatbot. Pour une telle charge, l’écart entre payer le prix d’entrée complet pour tout le préfixe à chaque fois et payer la prime d’écriture une fois puis le tarif de lecture remisé ensuite se cumule avec le volume d’appels. Cela ne change rien pour les charges qui ne répètent pas de préfixe — une requête ponctuelle n’a aucun contenu mis en cache à réduire.

Un calcul pratique du point mort compare le coût non mis en cache du préfixe répété sur tous les appels au coût d’écriture ou de stockage du cache plus les lectures de cache à tarif réduit sur les appels ultérieurs. Le résultat dépend de la taille du préfixe, du nombre de hits de cache réussis, de l’expiration du cache et du fait que la passerelle conserve les requêtes sur une route fournisseur compatible. Si ces conditions sont instables, la remise affichée peut surestimer les économies réalisées en production.

Un modèle de coût simple pour un préfixe répété

Soit P le nombre de jetons dans le préfixe stable et N le nombre d’appels qui le réutilisent. Si U est le prix d’entrée non mis en cache par jeton, le préfixe coûte N × P × U sans cache. Une estimation simplifiée avec cache est P × W + (N − 1) × P × R + S, où W est le prix d’écriture de cache, R est le prix de lecture de cache, et S tout coût de stockage sur la période. La formule suppose que le premier appel crée le cache et que chaque appel ultérieur est un hit réussi. Elle exclut la partie variable de chaque requête, les jetons de sortie, les réessais, et tout changement de route causant un miss.

Considérons un préfixe illustratif de 100 000 jetons réutilisé pour 20 appels au tarif officiel de GPT-5.6 Terra. À 2,50 $ par 1 million de jetons d’entrée non mis en cache, traiter ce préfixe de façon répétée coûterait 5,00 $. En utilisant le tarif de première écriture à 1,25 fois et la remise de 90 % pour la lecture, une écriture de 100 000 jetons coûterait environ 0,3125 $ et dix-neuf lectures environ 0,475 $, pour un coût de préfixe combiné d’environ 0,7875 $. La différence est d’environ 4,21 $ avant les coûts d’entrée variables et de sortie. Il s’agit d’une illustration, pas d’un devis : elle ne tient que si les dix-neuf appels ultérieurs touchent le même cache valide et si aucun coût de stockage ou de routage supplémentaire ne s’applique.

Le point mort découle directement du même modèle. Une prime d’écriture n’est justifiée que lorsque suffisamment de lectures à tarif réduit se produisent avant expiration. Pour une charge avec des sessions courtes, des modifications fréquentes du prompt ou une faible affinité de route, le cache peut être recréé plus souvent que prévu. Pour une boucle d’agent de longue durée ou une analyse répétée de documents avec un préfixe stable, le nombre de hits peut être bien plus élevé. Les prévisions doivent donc utiliser une fourchette de taux de hits observée plutôt que de supposer une séquence parfaite après le premier appel.

Modèles d’implémentation qui améliorent la réutilisation du cache

La construction du prompt a un effet plus grand sur le taux de hits que ce que beaucoup de feuilles de calcul de prix laissent entendre. Placez d’abord le matériel le plus stable et gardez sa sérialisation déterministe : instructions système, schémas d’outils, texte de politique et contexte de référence partagé doivent conserver le même ordre, les mêmes espaces et la même représentation des champs sur les appels liés. Ajoutez ensuite le contenu volatile. Évitez d’injecter des horodatages, des identifiants aléatoires, des compteurs qui changent en continu ou des résultats de récupération spécifiques à la requête dans le préfixe réutilisable sauf si leur présence y est réellement nécessaire.

Faites versionner le matériel stable de manière délibérée. Si un schéma d’outil ou une politique change, assignez la nouvelle version de façon cohérente au lieu de laisser circuler plusieurs variantes presque identiques. Pour les charges conversationnelles ou agentiques, réutilisez un identifiant de session stable ou une clé de cache lorsque l’API le prend en charge, et évitez de changer de fournisseur au milieu d’une séquence dépendante du cache. OpenRouter documente un routage collé au fournisseur pour la mise en cache des prompts et expose des contrôles comme session_id et prompt_cache_key ; ces contrôles peuvent améliorer la continuité, mais ils ne garantissent pas un hit lorsque le cache amont est froid ou expiré.

Les applications doivent aussi se dégrader proprement en cas de miss. La mise en cache est une optimisation de coût et de latence, pas une dépendance de correction. La requête doit toujours produire le même résultat valide lorsque le cache est indisponible, et la logique de réessai ne doit pas créer aveuglément des écritures répétées. Cette séparation rend les comparaisons de routes plus sûres : les équipes peuvent changer la politique de cache ou la configuration de passerelle sans changer le comportement sémantique de l’application.

Comment vérifier l’économie du cache en production

Commencez par la télémétrie par requête plutôt que par la facture mensuelle. Journalisez l’identifiant de modèle exact, la route de passerelle ou le fournisseur lorsqu’ils sont exposés, le niveau de service, le total de jetons d’entrée, les jetons de lecture de cache, les jetons d’écriture de cache, les jetons de sortie, la latence et le coût facturé. L’objet d’usage d’OpenRouter inclut cached_tokens et cache_write_tokens ; d’autres fournisseurs exposent des détails équivalents sous des noms de champs différents. Conservez les champs d’usage bruts afin qu’un changement de prix ultérieur n’efface pas les éléments nécessaires pour reconstituer le coût.

Agréguez les données par version de prompt et par charge, pas seulement par modèle. Des mesures utiles incluent la part des requêtes éligibles qui touchent un cache, la part des jetons d’entrée facturés au tarif de lecture, le nombre d’écritures par lecture réussie, le temps entre l’écriture et le dernier hit, et le coût réalisé par requête. Un taux de hits élevé au niveau des requêtes peut apporter peu de valeur si le préfixe mis en cache est petit, tandis qu’un taux de hits plus faible sur un très grand préfixe peut économiser davantage. Associez ces mesures aux centiles de latence, car une route moins chère qui rate ou reroute fréquemment peut être opérationnellement pire.

Enfin, examinez les anomalies au lieu de les lisser. Une chute soudaine des jetons mis en cache peut indiquer un déploiement de version de prompt, une sérialisation instable, des entrées expirées, une limite de palier « long-context » ou un changement de route de passerelle. Comparez les requêtes affectées avec la page modèle actuelle et la documentation du fournisseur, puis vérifiez le tarif facturé. Cela réduit l’écart entre une remise publiée et les économies réellement réalisées par l’application.

À vérifier avant de supposer qu’un tarif s’applique

Confirmez cinq éléments avant d’utiliser un tarif publié dans un budget : le modèle exact et le niveau de service, le préfixe réutilisable minimal ou les points de coupure explicites du cache, le coût de première écriture ou de stockage, la durée de vie du cache, et la preuve que les requêtes touchent effectivement le cache. OpenAI indique actuellement une durée de vie minimale du cache de 30 minutes pour GPT-5.6, mais ce n’est pas une règle de rétention universelle. Google publie des tarifs différents pour les niveaux Standard, Batch, Flex et Priority. Les passerelles peuvent également router entre fournisseurs ou niveaux, donc la route sélectionnée compte. La documentation de mise en cache des prompts d’OpenRouter recommande de vérifier les champs d’usage de la réponse tels que cached_tokens et cache_write_tokens. Pour toute estimation de production, comparez la page modèle actuelle avec la facturation et les métadonnées d’usage réelles plutôt que de vous fier uniquement à un label général « mise en cache prise en charge ».