Prompt caching et coûts

Le mécanisme

Quand un modèle traite un prompt, il calcule les activations (clés/valeurs des couches d’attention) de chaque token. Ce calcul est coûteux et dépend uniquement du préfixe : les premiers tokens du prompt produisent toujours les mêmes activations, tant qu’on ne touche pas à eux.

Le prompt caching exploite cette propriété. Le fournisseur stocke les activations d’un préfixe stable côté serveur, et les réutilise quand la requête suivante commence par le même préfixe. Résultat : moins de latence, moins de tokens facturés au plein tarif.

Point clé : Le cache n’améliore pas la qualité du modèle. Il ne fait qu’éviter de recalculer ce qui a déjà été calculé.

La règle du préfixe immuable

Le matching est strictement séquentiel. Le cache fonctionne tant que le préfixe est identique token par token. Au premier token qui diffère, le hit s’arrête et tout ce qui suit est recalculé.

Conséquence pratique

• Ce qui ne change pas (system prompt, instructions, documents de référence) va en début de prompt.
• Ce qui change (date du jour, question de l’utilisateur, état courant) va en fin.
• Un timestamp ou un identifiant aléatoire en début de prompt rend tout le reste non cachable.

Attention : Insérer un DateTime.UtcNow en haut d’un prompt est une erreur courante : chaque requête a un préfixe différent, donc aucun hit possible. Le timestamp doit aller en fin de prompt, après tout le contenu stable.

Économique : write vs read

Tous les fournisseurs facturent différemment l’écriture et la lecture du cache. Chez Anthropic, l’ordre de grandeur est :

Point clé : Break-even autour de la 2ᵉ lecture. En dessous, le cache coûte plus cher que de ne rien cacher. Au-delà, l’économie devient massive sur les longs préfixes.

Cache breakpoints

L’API d’Anthropic permet de poser jusqu’à 4 breakpoints dans le prompt via le paramètre cache_control. Chaque breakpoint marque la fin d’une zone que le serveur peut cacher indépendamment.

Cas typique :

1. Premier bloc : system prompt et docs de référence partagés — cache_control: ephemeral.
2. Deuxième bloc : conventions projet (CLAUDE.md) — cache_control: ephemeral.
3. Troisième bloc : historique de conversation jusqu’au dernier tour — cache_control: ephemeral.
4. Reste : le tour courant (jamais caché).

Avantage : si l’historique change mais pas les conventions, le serveur peut servir les blocs 1 et 2 en cache et ne recalculer qu’à partir du 3.

Pièges courants

TTL trop court. Le cache éphémère expire en 5 min (extensible à 1 h, à un coût d’écriture supérieur). Une session espacée de plus de 5 min entre deux tours paie la réécriture à chaque fois.

Cache pour une seule requête. Activer cache_control sur un préfixe qu’on n’appellera qu’une fois fait perdre 25 % : on paie le write mais jamais le read. À utiliser uniquement si on prévoit au moins 2 lectures.

Outils dynamiques. Les définitions d’outils (function calling, MCP) font partie du préfixe. Activer / désactiver un outil entre deux tours invalide le cache à partir de la zone d’outils.

Variables glissées dans le system prompt. Interpoler le nom de l’utilisateur ou la date dans le system prompt rompt la stabilité — ces valeurs doivent aller dans les messages, pas dans le préfixe.

Architecture pour maximiser les hits

Pour un agent type Claude Code ou un orchestrateur multi-tours, la structure idéale du prompt est :

[ stable: system prompt + CLAUDE.md + tools ]   ← cache breakpoint
[ stable: docs projet / specs / contexte ]      ← cache breakpoint
[ semi-stable: historique conversation ]        ← cache breakpoint
[ volatile: tour courant + variables ]          (jamais caché)

Point clé : Cette hiérarchie correspond à la structure en couches d’une architecture hexagonale : du plus stable (domain, conventions) au plus volatile (input courant). Penser au cache comme à une dépendance entrante : la fonctionnalité métier ne dépend pas de l’input du jour.