Le prompt caching réduit votre facture d'input en laissant le modèle relire un préfixe stable à environ 10 % du prix normal des input tokens, au lieu de payer plein tarif à chaque appel. C'est tout le tour de passe-passe : vous marquez l'avant immuable de votre prompt — les instructions du system prompt, les schémas des outils, le fichier que vous n'arrêtez pas de référencer — et à la requête suivante, le fournisseur le sert depuis le cache au lieu de le re-tokeniser de zéro. Si votre agent boucle sur le même context vingt fois dans une session, ce préfixe est le plus gros poste de dépense, et le caching est le levier le moins cher dont vous disposez.
Je passe le plus clair de mon temps à construire des outils qui grignotent les tokens des agents d'agentic coding, et le prompt caching est l'optimisation vers laquelle je me tournerais en premier, parce qu'elle ne vous coûte rien en qualité. Vous ne supprimez pas de context, vous ne résumez pas, vous ne jetez pas d'historique. Vous payez simplement moins cher des octets que le modèle a déjà vus. Le hic — et il y a toujours un hic — c'est que le caching ne fonctionne que si vous arrêtez de réordonner votre prompt. La plupart des gens cassent leur propre cache sans s'en apercevoir.
Fait partie de : Réduire l'utilisation de tokens des agents de coding IA
Qu'est-ce que le prompt caching et pourquoi réduit-il les coûts ?
Le prompt caching stocke un préfixe tokenisé de votre prompt côté fournisseur, de sorte que les requêtes répétées ne paient qu'une fraction du prix d'input pour ce préfixe. Avec l'API d'Anthropic, une lecture de cache (cache read) coûte environ 10 % du prix normal des input tokens ; en contrepartie, l'écriture initiale du cache (cache write) coûte un peu plus qu'un input token classique (environ 1,25x pour le palier 5 minutes). Le premier appel est donc légèrement plus cher, et chaque appel suivant qui réutilise le préfixe est radicalement moins cher. (Voir la documentation prompt caching d'Anthropic.) Chiffrons cela. Claude Opus 4.8 affiche un input à 5 $ par million de tokens (MTok) et un output à 25 $. Une lecture en cache sur cet input tourne autour de 0,50 $/MTok — un dixième. Si votre agent de coding transporte un préfixe de 30 000 tokens (system + context) et fait 15 allers-retours de tool-call dans une session, sans cache vous payez ~450 000 input tokens rien que pour le préfixe. Avec le cache, vous payez le plein tarif une fois et ~10 % sur les 14 autres lectures. C'est la différence entre 2,25 $ et environ 0,78 $ sur le préfixe pour une seule session — avant même d'avoir écrit une ligne d'output utile. Multipliez par chaque session, chaque jour. Le même calcul tient sur les modèles moins chers. Sonnet 4.6 est à 3 $/15 $ par MTok, Haiku 4.5 à 1 $/5 $, et GPT-5.5 à 5 $/30 $. Le caching réduit proportionnellement le côté input sur chacun. Il ne fait rien pour les output tokens — la génération est toujours facturée plein tarif — et c'est exactement pourquoi je traite le caching comme une optimisation de l'input et l'associe à d'autres tactiques pour le côté output. Si le vocabulaire ici reste flou, les entrées de glossaire token et prompt-caching sont courtes et valent deux minutes.Comment structurer un prompt pour que le cache fasse vraiment mouche ?
Mettez tout ce qui est stable à l'avant et tout ce qui est volatile à l'arrière, parce que le caching s'appuie sur une correspondance de préfixe exacte. Le cache est une recherche du plus long préfixe commun : le fournisseur compare votre nouvelle requête à ce qu'il a stocké et réutilise les tokens jusqu'au premier octet qui diffère. Un seul caractère modifié près du sommet invalide tout ce qui suit. La règle est donc d'une simplicité brutale — ordonnez votre prompt du plus stable au moins stable. Un prompt d'agent de coding qui se cache bien ressemble à ceci, de haut en bas :- System prompt et instructions de rôle — ils ne changent presque jamais au sein d'une session.
- Schémas d'outils / de fonctions — vos définitions d'outils MCP, fixes pour la session.
- Context épinglé — les fichiers, docs ou specs auxquels l'agent se réfère sans cesse.
- Historique de conversation — en mode append-only, pour que les tours plus anciens restent dans le préfixe caché.
- Le tour utilisateur courant — la seule chose qui change réellement à chaque appel.
cache_control ; le geste pratique est de marquer la fin de vos définitions d'outils et la fin de votre context épinglé. Tout ce qui précède le breakpoint est mis en cache ; le nouveau message utilisateur qui le suit est la seule partie facturée au plein tarif d'input.
Les erreurs qui tuent discrètement votre taux de hits :
- Injecter un timestamp ou un ID aléatoire dans le system prompt. « Current time: 2026-06-15T14:32:09Z » en tête signifie un cache miss frais à chaque appel. Si vous avez besoin de l'heure, mettez-la dans le dernier message utilisateur, pas dans le préfixe.
- Réordonner les définitions d'outils. Si votre framework sérialise les outils depuis un dict à l'ordre non déterministe, votre préfixe change de forme entre les appels. Triez-les.
- Éditer l'historique en cours de conversation. Résumer ou élaguer des tours antérieurs réécrit le préfixe et brûle le cache. Ajoutez ; ne réécrivez pas.
Le prompt caching expire-t-il, et quand cesse-t-il d'aider ?
Oui — les caches ont une durée de vie, et c'est dans ce TTL que se loge le plus gros de la déception. Le cache par défaut d'Anthropic vit environ 5 minutes à compter du dernier accès, avec un palier 1 heure disponible moyennant un coût d'écriture plus élevé. Le prompt caching d'OpenAI, à l'inverse, est automatique pour les prompts de plus de 1 024 tokens et il n'y a pas de surcoût d'écriture, mais vous avez beaucoup moins de contrôle sur ce qui est mis en cache, et la remise varie selon le modèle (voir le guide prompt caching d'OpenAI). Fournisseurs différents, règles différentes ; lisez celles du fournisseur que vous facturez réellement. La fenêtre de 5 minutes compte plus qu'il n'y paraît. Si un développeur déclenche une rafale d'appels d'agent, s'éloigne pour réfléchir, et revient 8 minutes plus tard, le cache s'est évaporé et l'appel suivant repaie le plein prix d'écriture. Au sein d'une session de coding active, vous resterez surtout au chaud ; au travers des écarts entre sessions, non. C'est pourquoi le caching est un gain au niveau de la session, pas une remise globale magique. Le caching cesse aussi d'aider dans trois cas honnêtes :- Les appels one-shot. Si vous ne réutilisez jamais le préfixe, vous avez payé la prime d'écriture de 1,25x pour rien. Les prompts à un seul tour ne devraient pas poser de breakpoint.
- Les préfixes minuscules. En dessous d'un minimum fournisseur (1 024 tokens chez Anthropic sur la plupart des modèles), le caching n'est même pas proposé. Il n'y a rien à amortir.
- Un préfixe qui change à chaque appel. Si votre context « stable » ne l'est pas vraiment, vous écrivez une nouvelle entrée de cache à chaque fois sans en lire aucune. C'est strictement pire que pas de caching du tout.
Comment le caching s'articule-t-il avec les autres façons de réduire les tokens ?
Le caching réduit le coût de l'input que vous gardez ; les autres tactiques réduisent la quantité d'input et d'output en premier lieu — et vous voulez les deux. Voyez cela comme deux molettes indépendantes. Le caching répond à « à quel prix puis-je relire ce préfixe ? ». Tout le reste répond à « ai-je seulement besoin de ces tokens ? ». En pratique, j'empile quatre mouvements par-dessus le caching :- Semantic code search au lieu de déverser des fichiers entiers dans le context. L'agent récupère les trois fonctions dont il a besoin, pas le module de 2 000 lignes. Un context épinglé plus petit signifie un préfixe plus petit (et toujours cacheable).
- Output filtering sur les tool calls bruyants. Un
git statusou un test runner peut cracher des milliers de tokens d'output dont le modèle n'a pas besoin ; les filtrer avant qu'ils n'atteignent le context réduit l'input qui alimente le tour suivant. - Skeleton compression pour les gros fichiers — donnez au modèle la structure (signatures, types, titres) et laissez-le demander le corps seulement quand il en a besoin.
- Lazy MCP loading pour ne pas coller le schéma complet de douze serveurs dans chaque prompt. Si vous faites tourner beaucoup de serveurs MCP, les bons pour Claude Code plus le lazy loading gardent votre bloc de définitions d'outils svelte — et un bloc d'outils svelte est moins cher à mettre en cache.
Un petit avant/après à faire vous-même
Lancez une vraie session deux fois et lisez la facture. Prenez une tâche de coding typique, exécutez-la avec votre prompt dans l'ordre par défaut de votre framework, et notez le nombre d'input tokens et le nombre de cache reads dans la réponse de l'API. Puis réordonnez : system prompt stable et schémas d'outils d'abord, fichiers épinglés ensuite, un seul breakpoint de cache après eux, tour utilisateur volatile en dernier. Relancez la même tâche. Si vous obteniez auparavant des cache hits proches de zéro — et beaucoup de configurations d'agent sont dans ce cas, parce qu'elles injectent un timestamp ou réordonnent les outils à chaque appel — vous verrez en général la part de cache reads dans votre input bondir de presque rien à la majorité des tokens du préfixe, ce qui sur Opus signifie payer 0,50 $/MTok au lieu de 5 $ sur le gros de votre input. C'est une réduction de 90 % sur la portion cachée, obtenue en ne changeant rien d'autre que l'ordre de votre prompt. Je n'ai pas encore trouvé d'optimisation moins chère. C'est, franchement, un peu gênant de voir combien d'argent traîne sur la table ici.À voir aussi
- Comment réduire l'utilisation de tokens des agents de coding IA — le pilier dont cet article sur le caching est un rayon.
- Tarification des tokens des API LLM — les tarifs actuels par MTok référencés ci-dessus.
- prompt-caching et context-window — les deux entrées de glossaire à lire en priorité ensuite.
Classé n°1 au Token-Harness Optimizer Leaderboard.
Tokenade est classé n°1 au Token-Harness Optimizer Leaderboard — un benchmark de bout en bout des optimiseurs de tokens, mesuré sur de vraies sessions de code. Installez-le une fois, il agit sur chaque prompt. Compatible avec Claude Code, Cursor, Codex, Copilot et plus.