Stratégies de cache : prompt caching & context caching

Les débuts de prompt répétés coûtent de l'argent et du temps à chaque appel. Le prompt caching les met en cache et économise les deux.

Le problème : le même texte, encore et encore

Un agent envoie souvent, à chaque requête, le même long début : prompt système, définitions d'outils, gros documents. Sans cache, le modèle recalcule cette partie entièrement à chaque appel – ça coûte du temps (latence) et de l'argent (prix des tokens), alors même que le texte n'a pas changé.

Comment fonctionne le prompt caching

Anthropic et OpenAI proposent le prompt caching pour ça. Le fournisseur retient le début (préfixe) d'un prompt que tu as déjà envoyé une fois. Si tu renvoies ce même début peu après – par exemple le même prompt système plus un nouveau tour utilisateur –, le modèle n'a besoin de traiter que la nouvelle partie. Le reste vient du cache.

Ce que ça économise

Chez Claude, un cache hit ne coûte qu'une fraction du prix normal des tokens d'entrée, tandis qu'une écriture de cache est un peu plus chère que la normale. Chez OpenAI, le prompt caching est activé automatiquement dès qu'un prompt est assez long, et il fait baisser sensiblement les coûts et le temps de latence, sans aucun changement de code.

TTL : le cache expire

Un cache ne vit pas éternellement. Chez Claude, la valeur par défaut est de 5 minutes ; après ça, l'entrée disparaît, et le prochain appel réécrit un nouveau cache. Il existe aussi une option plus longue et plus chère. Celui qui envoie beaucoup de requêtes rapprochées profite le plus du cache.

EXEMPLE

Un agent avec un prompt système de 6 000 tokens plus des définitions d'outils fait 10 requêtes en 3 minutes. Sans cache, tu paies le plein prix pour ces 6 000 tokens sur les 10 appels. Avec le cache, tu le paies une fois (écriture, 1,25x) et seulement 0,1x pour les 9 autres – une économie nette, tant que les requêtes restent dans la fenêtre de TTL de 5 minutes.

🛠️ EXERCICE — À TOI DE JOUER

Découvre dans l'un de tes scripts d'agent (ou dans la doc API de ton fournisseur de modèle) si et comment le prompt caching est utilisé.

Regarde le prompt système / les définitions d'outils de ton agent : combien de tokens fait environ cette partie fixe ?
Vérifie dans la réponse API (si tu utilises Claude) les champs cache_read_input_tokens et cache_creation_input_tokens – le cache est-il touché (hit) ?
Réfléchis : avec quel schéma d'utilisation (beaucoup de requêtes rapprochées vs. requêtes isolées et rares) le cache est-il le plus rentable chez toi ?

✅ AUTO-VÉRIFICATION

☐ Peux-tu expliquer pourquoi un cache hit est moins cher qu'une écriture de cache ?
☐ Sais-tu combien de temps vit un cache par défaut chez Claude, avant d'expirer ?
☐ As-tu identifié une partie concrète de ton propre prompt qui conviendrait pour un breakpoint de cache ?

QUIZ RAPIDE

Pourquoi une entrée de prompt cache expire-t-elle d'elle-même ?