# Prompt Caching

> Le prompt caching permet à un modèle de réutiliser un préfixe de prompt stable déjà traité, sans le refacturer au plein tarif — réduisant les coûts sur des sessions longues et répétitives.

Source: https://tokenade.net/fr/glossary/prompt-caching · Updated: 2026-10-07

## Qu'est-ce que le prompt caching ?

Le prompt caching est une fonctionnalité fournisseur qui permet à un modèle de réutiliser le travail déjà effectué sur un préfixe stable de votre prompt, au lieu de retraiter (et de refacturer intégralement) ce texte à chaque appel. On structure ou marque la partie invariante — un prompt système, des conventions de projet, du matériel de référence — pour que les requêtes répétées touchent le cache et que seuls les nouveaux tokens soient facturés au plein tarif.

Cela ne rend pas une seule requête plus petite ; cela rend *les requêtes répétées* qui partagent un préfixe commun bien moins chères. Les économies s'accumulent au fil d'une session.

## Pourquoi le prompt caching est important en 2026

Il est important parce que les sessions de codage agentiques sont longues et répétitives : le même prompt système et les mêmes règles de projet sont envoyés à chaque tour. Sans cache, ce contexte fixe est refacturé à chaque étape. Avec lui, le préfixe stable est facturé à une petite fraction du tarif d'input après le premier appel — c'est pourquoi garder ses instructions stables et compatibles avec le cache est un vrai levier sur les tokens. Voir [Réduire l'utilisation de tokens de Claude Code](https://tokenade.net/fr/articles/reduce-claude-code-token-usage).

Les chiffres, en octobre 2026 (pages tarifaires d'Anthropic et d'OpenAI) :

- **Anthropic :** une écriture en cache de 5 minutes coûte 1,25× le prix d'input de base, une écriture d'une heure 2×. Un cache hit coûte 0,1× sur la plupart des modèles Claude, 0,05× sur Opus 5.5 (0,20 $/MTok contre 4 $ en input) et 0,025× sur Fable 5.1.
- **OpenAI :** l'input en cache sur GPT-6 Astra est à 1 $ contre 10 $ pour l'input frais, soit 0,1×.
- **Rate limits aussi :** la documentation d'Anthropic précise que les tokens lus depuis le cache ne comptent pas dans la limite d'input tokens par minute sur la plupart des modèles ; un bon taux de hit achète donc aussi de la marge de [rate limit](https://tokenade.net/fr/glossary/rate-limit).

Notez ce que le caching ne fait *pas* : les tokens en cache occupent toujours la [context window](https://tokenade.net/fr/glossary/context-window) et restent facturés à chaque tour, simplement au tarif réduit. Le caching rend un gros préfixe moins cher ; il ne le rend pas plus petit.

## Quand le prompt caching n'aide pas

- **Quand le préfixe change constamment** — si le prompt système est réécrit ou le contexte réordonné à chaque tour, il n'y a rien de stable à mettre en cache.
- **Pour les prompts ponctuels** — une seule requête sans répétition n'a aucun préfixe à réutiliser.
- **Quand les hits sont rares** — une écriture coûte plus cher qu'un input normal (1,25× ou 2× chez Claude), donc un préfixe écrit puis jamais relu pendant sa durée de vie coûte plus cher que de ne pas utiliser de cache du tout.

## À lire aussi

- [Glossaire : Token](https://tokenade.net/fr/glossary/token)
- [Glossaire : Context window](https://tokenade.net/fr/glossary/context-window)
- [Article : Context engineering pour les agents de codage IA](https://tokenade.net/fr/articles/context-engineering)