Mise en cache des prompts

Comment fonctionne une lecture en cache

Un modèle de langage lit chaque requête à partir du premier token. Un agent IA en pleine tâche envoie ses instructions, ses définitions d'outils et toute la conversation jusque-là à chaque appel, si bien que sur une tâche longue cette relecture répétée représente l'essentiel de ce que vous payez. La mise en cache des prompts permet au fournisseur de sauter un travail qu'il vient de faire : si le début de votre requête correspond, token pour token, au début d'une requête récente, cette portion est servie à partir de ce que le fournisseur a conservé et facturée au tarif du cache.

Trois détails décident si cela se produit :

• C'est une correspondance de préfixe. Le cache couvre tout, du premier token jusqu'à la première différence, et rien au-delà. Changez un seul caractère près du début et chaque token situé après ce point est relu, et facturé, en totalité.
• Il expire. Les entrées survivent à quelques minutes d'inactivité, pas à des jours, et la fenêtre varie selon le fournisseur et le modèle : une requête envoyée après une longue pause paie donc le plein tarif même si rien en elle n'a changé.
• Il a un plancher. En dessous d'une longueur minimale de prompt, rien n'est mis en cache, et ce minimum est fixé modèle par modèle. Relevez-le dans la documentation actuelle du fournisseur plutôt que de reprendre un chiffre copié d'un vieil article de blog.

En septembre 2026, Anthropic, OpenAI et Google facturent chacun une lecture en cache sur leurs modèles actuels à environ un dixième du prix normal des entrées. Google et OpenAI appliquent la mise en cache automatiquement ; Anthropic met en cache jusqu'aux points de rupture que vous marquez dans la requête et facture un supplément pour écrire une entrée. Un écart de dix contre un est assez important pour que la part de vos entrées servie depuis le cache, plutôt que la taille de votre prompt, décide souvent de ce que coûte l'exécution d'un agent.

Pourquoi alléger le contexte a rendu nos agents plus chers

Nous faisons tourner des agents de longue durée qui construisent et modifient des sites web pour nos clients, et une session de création de site nous a montré ce que coûte un contexte sans limite. En un peu moins de quatre heures, elle a effectué 622 appels au modèle, pendant que la conversation relue à chaque appel grossissait jusqu'à environ 310 000 tokens. Le texte réellement écrit par le modèle représentait à peu près 6 % de la facture. Tout le reste consistait à relire le même historique.

La solution évidente était l'élagage : avant chaque appel, retirer les anciens résultats d'outils sur lesquels l'agent avait déjà agi. Nous l'avons mesuré sur notre propre espace de test, 366 appels réels au modèle au total, et sur la période où il s'est réellement déclenché, chaque appel a coûté environ 28 % de plus alors que chaque prompt ne perdait qu'environ 23 000 tokens. L'élagueur avançait à partir du résultat le plus ancien, si bien qu'à chaque appel il réécrivait un point un peu plus loin à l'intérieur du préfixe que le fournisseur venait de mettre en cache. Les entrées hors cache par appel sont passées de 2–8 milliers de tokens à 5–25 milliers, et avec un rapport de prix de dix contre un, cela a englouti l'économie. Le calcul mérite d'être retenu : un changement à l'intérieur d'un préfixe mis en cache doit retirer environ neuf fois plus de tokens qu'il n'en invalide, rien que pour rentrer dans ses frais.

Ce qui a fonctionné à la place, c'est un plafond plutôt qu'une coupe. Nous avons limité à 200 000 tokens le contexte qu'un agent peut accumuler, de sorte que son historique est compacté en une seule passe à l'approche de cette limite au lieu d'être retouché un peu à chaque appel, et nous avons désactivé l'élagage par appel. Une réécriture unique suivie d'une longue série d'appels qui ne font qu'ajouter : c'est la forme que la mise en cache récompense. La leçon que nous en avons tirée est de lire les entrées en cache et hors cache de chaque appel avant de croire qu'un changement a fait économiser de l'argent, parce que la taille du prompt, à elle seule, nous disait l'inverse de ce que disait la facture.

Comment préserver vos lectures en cache

L'essentiel de l'économie vient de l'ordre, pas de la configuration. Si vous construisez sur l'API d'un modèle, quatre habitudes en couvrent presque la totalité :

• Le stable d'abord, ce qui change en dernier. Instructions, définitions d'outils et documents de référence vont en haut et restent identiques à l'octet près d'un appel à l'autre. Un horodatage, le nom d'un utilisateur ou un identifiant de requête placé près du début d'un prompt système neutralise discrètement le cache à chaque requête.
• Ajoutez, ne modifiez pas. Ajoutez les nouveaux tours à la fin de la conversation. Réécrire, réordonner ou résumer sur place des tours antérieurs invalide tout ce qui suit la modification — l'erreur que notre élagage commettait une étape après l'autre.
• Réécrivez rarement, et d'un seul coup. Si l'historique doit rétrécir, faites-le en une seule compaction, à un plafond que vous avez choisi, et acceptez un appel coûteux en échange d'une longue série d'appels bon marché derrière lui.
• Mesurez la répartition, pas la taille. Les fournisseurs indiquent séparément les entrées en cache et hors cache dans les données d'usage de chaque réponse. Un changement qui raccourcit votre prompt et fait grimper le volume hors cache a rendu les choses plus chères, quoi qu'en dise la longueur du prompt.

Les chiffres ci-dessus viennent de l'exploitation d'AgentCeres — l'AI Growth Officer sur agentceres.com — où une équipe d'agents spécialisés rédige pages, publications et prises de contact, et où tout travail sortant attend par défaut l'approbation d'une personne. Si vous fixez le prix d'un produit bâti sur des appels de ce type, comment fixer le prix d'un produit d'IA quand mes coûts sont variables ? explique pourquoi un coût par appel mesuré doit servir de socle au prix.