Le prompt caching est le levier de coût au plus fort effet de levier sur un agent de code, et le chiffre phare est simple : un cache read token chez Anthropic coûte 10 % d'un input token frais — une remise de 90 % sur tout le contexte que vous renvoyez inchangé. [1] Cette page rassemble les vrais chiffres du caching — taux de remise, surcoût du write, calcul du seuil de rentabilité et réductions en production que les équipes ont réellement publiées — à partir de sources primaires, pour qu'ils soient tous au même endroit. Tous les chiffres sont cités à jour de juin 2026. La mécanique du caching et les multiplicateurs changent (Anthropic a discrètement modifié un TTL par défaut à la mi-mars 2026 — voir plus bas), donc revérifiez à la source primaire avant toute citation commerciale.

À retenir

Les chiffres clés en un coup d'œil

•Un cache read coûte 10 % de l'input de base chez Anthropic — une remise de 90 % sur le contexte répété. [1]
•Les cache writes portent un surcoût de 1,25× pour un TTL de 5 minutes et de 2× pour un TTL de 1 heure ; le write se rentabilise après un re-read (5 min) ou deux re-reads (1 heure). [1]
•Le système de sécurité agentique de ProjectDiscovery a réduit ses coûts LLM de 59 % avec le caching, jusqu'à 70 % après réglages. [2]
•GitHub a atteint un taux de cache hit de 93 %+ dans des workflows agentiques en production en gardant les prompts et les définitions d'outils byte-stable. [3]
•OpenAI accorde aux modèles de classe GPT-5 une remise de 90 % sur l'input mis en cache automatiquement, mais seulement une fois qu'un prompt dépasse 1 024 tokens. [4]
•La remise ne vaut rien si le préfixe n'est pas byte-identique — une seule instruction réordonnée invalide tout le cache. [1]

Combien coûte réellement un cache read chez Anthropic ?

Un cache read token est facturé à 10 % du prix d'input de base dans le prompt caching d'Anthropic — donc sur Claude Sonnet 4.6 ($3.00/MTok en input) un cache hit coûte $0.30/MTok, et sur Claude Opus 4.8 ($5.00/MTok en input) il coûte $0.50/MTok. [1] C'est une remise de 90 % sur chaque token que le modèle relit depuis un préfixe mis en cache au lieu de le retraiter. C'est le chiffre qui compte, à cause de la façon dont les agents fonctionnent vraiment. Un agent relit tout son contexte — system prompt, définitions d'outils, historique de conversation, contenu des fichiers, sortie des commandes — à chaque tool call. Au tour 30 d'une session de débogage, il paie pour relire des dizaines de milliers de tokens d'historique accumulé à chaque requête. Le caching est ce qui transforme cette relecture du plein tarif à un dixième du prix. Pour la mécanique sous-jacente, les entrées de glossaire prompt caching et context window couvrent le schéma d'accumulation qui rend cela si précieux.

Modèle	Input de base ($/MTok)	Cache read ($/MTok)	Write 5 min ($/MTok)	Write 1 heure ($/MTok)
Claude Opus 4.8	$5.00	$0.50	$6.25	$10.00
Claude Sonnet 4.6	$3.00	$0.30	$3.75	$6.00
Claude Haiku 4.5	$1.00	$0.10	$1.25	$2.00

Cache read = 0,1× input de base ; write 5 min = 1,25× input de base ; write 1 heure = 2× input de base. Source : Anthropic, Prompt Caching docs (platform.claude.com, juin 2026) [1]

Qu'est-ce que le surcoût du cache write, et quand devient-il rentable ?

Écrire dans le cache n'est pas gratuit : un cache write token coûte 1,25× le prix d'input de base pour un TTL de 5 minutes et 2× pour un TTL de 1 heure chez Anthropic. [1] Vous payez ce surcoût une seule fois, quand le préfixe est mis en cache pour la première fois, puis vous le relisez à 10 % de la base tant qu'il reste chaud. Le seuil de rentabilité est généreux. Avec le cache de 5 minutes, un seul re-read bat déjà le fait de payer le plein tarif d'input deux fois. Avec le cache de 1 heure, deux re-reads couvrent le write à 2×. Concrètement, pour un préfixe stable de 10 000 tokens (system prompt plus définitions d'outils) sur Sonnet 4.6 au fil d'une session de 50 tours :

Sans caching : 10 000 × 50 × $3 / 1 000 000 = $1.50 pour ce seul bloc statique.
Avec caching (1 write + 49 reads, TTL 5 min) : (10 000 × 1,25 × $3 / 1 000 000) + (10 000 × 49 × $0.30 / 1 000 000) = $0.038 + $0.147 = $0.185 — soit une réduction d'environ 88 % sur ce bloc.

L'arithmétique est ennuyeuse à dessein. L'idée est que le surcoût du write n'est qu'une erreur d'arrondi face aux économies de read dès qu'un préfixe est réutilisé ne serait-ce qu'une poignée de fois — exactement ce que fait une boucle agentique.

Combien les vraies équipes économisent-elles réellement ?

ProjectDiscovery, qui exploite un système de sécurité agentique appelé Neo, a publié le chiffre de production le plus net que j'aie vu : le caching a réduit leurs coûts LLM de 59 %, grimpant à 66 % après optimisation supplémentaire et 70 % sur leurs dix derniers jours mesurés. [2] Leur configuration est un cas d'école pour le caching — des system prompts de plus de 20 000 tokens de YAML par agent, une moyenne de 26 étapes et 40 tool calls par tâche, et toute la conversation renvoyée à chaque étape. Une seule tâche Opus complexe a brûlé 60 millions de tokens avant qu'ils ne touchent au caching. [2] Le résultat mesuré par GitHub porte sur le taux de hit plutôt que sur les dollars : ils ont atteint un taux de cache hit de 93 %+ sur le contexte répété dans leurs propres workflows agentiques en gardant les définitions d'outils et les system prompts stables d'un tour à l'autre. [3] C'est la métrique en amont — vos économies en dollars valent à peu près le taux de hit multiplié par la remise de 90 % par token sur la portion mise en cache de votre prompt.

59–70%

réduction totale du coût LLM sur un système agentique en production avec le caching

Source : ProjectDiscovery, 2026 [2]

93%+

taux de cache hit sur le contexte répété avec des prompts byte-stable

Source : GitHub, 2026 [3]

Une mise en garde sans détour sur le chiffre de 59–70 % : c'est un pourcentage de ce qu'ils dépensaient déjà, sur une charge de travail particulièrement favorable au caching (énorme préfixe stable, des dizaines de re-reads). Votre résultat varie selon la part de votre prompt qui est réellement identique d'un tour à l'autre. Les économies se logent dans le préfixe stable, pas dans le pourcentage affiché.

Comment se compare le caching d'OpenAI ?

OpenAI met en cache automatiquement — pas de breakpoint cache_control, pas de modification de code — et pour les modèles de classe GPT-5 la portion mise en cache du prompt est facturée à 10 % de l'input, une remise de 90 %, du même ordre que chez Anthropic. [4] Les différences structurelles comptent plus que le taux :

Longueur minimale : le caching d'OpenAI ne s'active qu'une fois qu'un prompt dépasse 1 024 tokens ; en dessous, rien n'est mis en cache et cached_tokens indique zéro. [4] Anthropic impose de même un préfixe minimal cacheable (1 024 tokens sur la plupart des modèles actuels, 2 048 sur le plus petit).
Pas de surcoût de write : OpenAI ne facture rien de plus pour peupler le cache, là où Anthropic facture le write à 1,25×/2×. La contrepartie, c'est le contrôle — Anthropic vous laisse décider exactement où se situe la frontière du cache, ce qui rend un taux de hit de 93 %+ atteignable à dessein plutôt que par chance.
La remise varie selon le modèle : la remise sur l'input mis en cache d'OpenAI est de 50 %, 75 % ou 90 % selon le modèle ; la classe GPT-5 atterrit à 90 %. [4] Ne supposez pas la remise maximale sur un modèle plus ancien ou plus petit.

Fournisseur	Remise cache read	Surcoût write	Activation	Préfixe min.
Anthropic (Claude)	−90% (10% de l'input)	1.25× (5 min) / 2× (1 heure)	cache_control explicite	1 024 tokens
OpenAI (GPT-5.5)	−90% (10% de l'input)	aucun	automatique	1 024 tokens

Le tarif de base de GPT-5.5 est de $5/$30 par MTok input/output ; l'input mis en cache est facturé à 10 % de l'input sur les modèles de classe GPT-5. Sources : Anthropic [1], OpenAI [4] (juin 2026).

Pourquoi un préfixe byte-identique décide-t-il de tout ?

La remise est conditionnée à une correspondance exacte du préfixe : le bloc mis en cache doit être byte-identique d'une requête à l'autre, et tout changement — même réordonner des instructions ou ajouter un token avant la région mise en cache — invalide le cache et force un retraitement au plein tarif. [1] C'est la partie que les équipes ratent. Un timestamp dans le system prompt, un ID utilisateur par requête injecté près du sommet, une liste d'outils qui se re-trie elle-même — chacun fait silencieusement chuter votre taux de hit à zéro, et vous continuez à payer le plein tarif d'input en croyant que le caching est actif. Cela casse aussi de façons que vous ne contrôlez pas. En mars 2026, Anthropic a fait passer un comportement de TTL de cache par défaut d'une heure à cinq minutes, et une vague d'utilisateurs de Claude Code a vu ses coûts et ses quotas gonfler avant que quiconque n'en identifie la cause. [5] La leçon n'est pas « le caching n'est pas fiable » — c'est que le caching est autant un problème de mesure qu'un problème de configuration. Si vous ne surveillez pas votre ratio cache-read sur input, vous ne remarquerez pas quand il régresse. C'est exactement la comptabilité pour laquelle j'ai construit Tokenade : il garde le préfixe cacheable stable au fil des tours d'un agent, élague le contexte volatile qui ferait sauter le cache, et fait remonter votre ratio de cache hit sur un dashboard d'économies, de sorte qu'un changement de TTL ou un timestamp égaré apparaisse comme une ligne sur un graphique plutôt qu'une surprise sur la facture. Il se branche sur Claude Code, Cursor, Codex, Copilot et Windsurf, et le moteur est source-available (MIT). Le palier gratuit couvre jusqu'à ≈10M tokens par mois ; Pro est à 19,90 $/mois (HT) avec postes illimités. Pour le tableau de coûts plus large dans lequel s'inscrivent ces économies, voir coûts en tokens des agents de code IA et le guide pratique réduire l'usage de tokens des agents de code IA. L'entrée output filtering couvre le levier complémentaire sur ce que le modèle réécrit en retour.

Notes sur les sources

Les multiplicateurs de cache read, de cache write et l'exigence de préfixe byte-identique proviennent de la documentation du prompt caching d'Anthropic (source primaire). Le caching automatique d'OpenAI, la remise de 90 % en classe GPT-5 et le minimum de 1 024 tokens proviennent des docs de prompt caching d'OpenAI (source primaire). La réduction de 59–70 % est une étude de cas d'ingénierie publiée par un fournisseur (ProjectDiscovery — données de production, pas une étude académique). Le taux de cache hit de 93 %+ provient du blog d'ingénierie de GitHub. Le changement de TTL de mars 2026 est documenté dans une issue publique de Claude Code (source secondaire/communautaire, incluse parce qu'elle illustre une vraie régression, non comme chiffre de tarification). Revérifiez tous les chiffres aux sources primaires avant tout usage commercial.

Sources et références

[1]Anthropic. "Prompt caching — Claude API Docs". platform.claude.com, 2026. Link ↗
[2]ProjectDiscovery. "How We Cut LLM Costs by 59% With Prompt Caching". projectdiscovery.io, 2026. Link ↗
[3]GitHub. "Improving token efficiency in GitHub Agentic Workflows". github.blog, 2026. Link ↗
[4]OpenAI. "Prompt caching — OpenAI API". developers.openai.com, 2026. Link ↗
[5]anthropics/claude-code. "Cache TTL silently regressed from 1h to 5m around early March 2026". GitHub issue #46829, 2026. Link ↗

Économies du prompt caching : les vrais chiffres

Key figures