Prompt caching Anthropic et OpenAI dans n8n : réduire coût et latence des appels IA répétitifs

Un workflow n8n qui classe des emails, interroge une base documentaire ou fait tourner un agent conversationnel envoie souvent le même bloc de texte à chaque appel : le même prompt système, les mêmes définitions d'outils, le même contexte RAG volumineux — seule la question change. Sans optimisation, le fournisseur du modèle facture et retraite ce bloc en entier à chaque requête. Le prompt caching, proposé nativement par Anthropic et OpenAI, mémorise le calcul de ce préfixe identique pour le réutiliser au prochain appel : jusqu'à 90 % de réduction sur ces tokens et une latence nettement plus courte. Ce guide explique comment ça fonctionne, pourquoi n8n ne l'active pas automatiquement, et comment le brancher malgré tout.

Ce que le prompt caching résout concrètement

Prenez un AI Agent n8n avec plusieurs outils personnalisés : à chaque tour de conversation, le modèle reçoit à nouveau l'intégralité du prompt système, la liste des outils disponibles et l'historique de la discussion. Même chose pour une boucle Loop Over Items qui classe 300 emails un par un avec des consignes de tri identiques à chaque itération, ou pour un chatbot RAG dont le contexte documentaire injecté reste stable sur plusieurs questions consécutives d'un même visiteur. Dans ces trois cas, une part importante — parfois la majorité — des tokens envoyés est rigoureusement identique d'un appel à l'autre. Le prompt caching cible exactement cette redondance.

Il ne faut pas le confondre avec le cache sémantique décrit dans notre guide sur le cache Redis pour réponses IA : ce dernier compare le sens de deux questions différentes pour réutiliser une réponse déjà calculée, et court-circuite complètement l'appel au modèle. Le prompt caching, lui, agit à l'intérieur même de l'appel : il ne change rien à la réponse générée, il accélère et réduit simplement le coût du traitement du préfixe commun. Les deux mécanismes sont complémentaires plutôt que concurrents.

Comment fonctionne le prompt caching chez Anthropic

Chez Anthropic, l'activation est explicite : on ajoute un champ "cache_control": {"type": "ephemeral"} sur les blocs de contenu à mettre en cache — le prompt système, un gros document injecté en contexte, la définition d'un jeu d'outils. Un appel peut définir jusqu'à quatre points de rupture (« breakpoints ») de ce type. Chaque bloc marqué doit dépasser un seuil minimal de tokens, de l'ordre de 1024 selon le modèle (le seuil exact figure dans la documentation officielle et varie selon la génération) : en dessous, le bloc n'est simplement pas mis en cache, sans erreur.

Le cache reste actif 5 minutes par défaut, rafraîchies gratuitement à chaque lecture réussie ; une option payante permet d'étendre la durée de vie à 1 heure. Côté tarification, l'écriture coûte plus cher que le tarif d'entrée standard (environ 1,25× pour un cache de 5 minutes, 2× pour 1 heure), mais la lecture d'un cache déjà écrit ne coûte que 0,1× le tarif standard — une remise de 90 %. Anthropic annonce, dans sa documentation officielle, des gains « jusqu'à 90 % sur le coût et jusqu'à 85 % sur la latence » pour les prompts longs et répétés.

Comment fonctionne le prompt caching chez OpenAI

OpenAI adopte une approche plus simple mais moins généreuse : la mise en cache est automatique, sans champ ni en-tête à ajouter. Dès qu'un prompt dépasse environ 1024 tokens, l'API réutilise le préfixe le plus long déjà rencontré récemment, par incréments de 128 tokens, avec une remise de 50 % sur ces tokens — moins spectaculaire que chez Anthropic, mais sans effort d'implémentation. Le cache reste disponible typiquement 5 à 10 minutes après le dernier appel, occasionnellement jusqu'à une heure en période creuse, sans garantie contractuelle sur cette durée.

La limite côté n8n : pas d'option native

C'est le point qui bloque le plus souvent : les nodes AI Agent, Basic LLM Chain et leurs sous-nodes de modèle (OpenAI Chat Model, Anthropic Chat Model) s'appuient sur l'intégration LangChain des credentials, qui ne propose aucun champ pour poser un point de rupture cache_control. Le prompt caching d'OpenAI s'applique malgré tout automatiquement en arrière-plan dès que le seuil de tokens est atteint, puisqu'il ne nécessite aucune configuration côté appelant. Ce n'est pas le cas d'Anthropic, dont le mécanisme est opt-in : sans le champ cache_control explicitement posé dans la requête, aucun cache n'est créé, et les nodes natifs de n8n ne le posent pas.

Pour l'activer avec Anthropic, il faut donc contourner les nodes LangChain et appeler directement l'API Messages via un node HTTP Request — le même réflexe que pour les API Batch d'OpenAI et Anthropic, qui ne sont elles non plus pilotables que via ce node.

Implémentation avec le node HTTP Request

La structure d'un appel à POST https://api.anthropic.com/v1/messages avec cache activé sur le prompt système ressemble à ceci :

{
  "model": "claude-sonnet-4-5",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "Vous êtes un assistant qui classe des emails entrants selon les règles suivantes : [... consignes longues et stables ...]",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [
    { "role": "user", "content": "{{ $json.emailContent }}" }
  ]
}

Dans n8n, ce corps se construit dans un node HTTP Request en méthode POST, authentifié via « Predefined Credential Type » en sélectionnant le credential Anthropic déjà utilisé par vos autres nodes IA — pas besoin d'en recréer un dédié. Le principe : tout ce qui est statique et réutilisé d'un appel à l'autre va dans le bloc marqué cache_control, et tout ce qui change à chaque exécution reste dans le tableau messages. La réponse inclut un objet usage qui détaille cache_creation_input_tokens et cache_read_input_tokens — un moyen simple de vérifier que le cache est bien sollicité plutôt que recréé à chaque appel.

Quels workflows n8n en profitent réellement

Le gain n'est réel que si le même préfixe est réutilisé plusieurs fois dans la fenêtre de vie du cache (5 minutes, ou 1 heure en option). Trois profils de workflows en tirent un bénéfice net :

• Boucles de classification : un Loop Over Items qui applique les mêmes consignes de tri à des dizaines ou centaines d'emails, tickets ou avis clients à la suite — le prompt système n'est facturé plein tarif qu'une fois, puis relu à prix réduit tant que la boucle reste sous la barre des 5 minutes entre deux appels.
• Agents conversationnels actifs : un chatbot RAG ou un widget de chat IA où un même visiteur enchaîne plusieurs messages en quelques minutes, avec un prompt système et un contexte documentaire stables d'un tour à l'autre.
• AI Agent avec un jeu d'outils volumineux : plus la liste d'outils personnalisés exposée au modèle est longue, plus le gain de mise en cache de leurs définitions est significatif à chaque nouvel appel de l'agent dans la même session.

À l'inverse, un cron quotidien isolé, ou un workflow dont les appels sont espacés de plusieurs dizaines de minutes, ne profite d'aucun gain réel : le cache aura déjà expiré avant le prochain appel, et l'écriture initiale (plus chère que le tarif standard) devient une dépense pure plutôt qu'un investissement amorti.

Un fondement technique, pas une remise arbitraire

Comme pour les API Batch, cette remise reflète un vrai gain d'efficacité côté serveur plutôt qu'un geste commercial. Le principe — mémoriser les clés et valeurs d'attention déjà calculées pour un préfixe de texte, plutôt que de tout recalculer à chaque requête — est documenté par In Gim, Guojun Chen, Seung-seob Lee, Nikhil Sarda, Anurag Khandelwal et Lin Zhong dans « Prompt Cache: Modular Attention Reuse for Low-Latency Inference » (MLSys 2024), qui mesure une réduction marquée du temps jusqu'au premier token. Le même principe sous-tend RadixAttention, décrit par Lianmin Zheng et ses coauteurs dans « SGLang: Efficient Execution of Structured Language Model Programs », un moteur d'inférence open source qui indexe automatiquement les préfixes partagés entre requêtes concurrentes.

Pièges à éviter

• Ordre des blocs dans le prompt : le cache repose sur un préfixe identique caractère pour caractère. Placez le contenu statique (système, outils, contexte) avant le contenu dynamique (la question) — un seul token qui change en tête de prompt invalide tout le cache en aval.
• Prompt trop court : en dessous du seuil minimal de tokens, Anthropic ignore silencieusement le champ cache_control, sans erreur ni gain. Vérifiez cache_creation_input_tokens dans la réponse pour confirmer que la mise en cache a bien eu lieu.
• Espacement des appels : un traitement trop lent entre deux items d'une boucle peut faire expirer le cache avant le prochain appel. Pour des boucles longues, l'extension à 1 heure côté Anthropic mérite d'être testée.
• Suivi du coût : combinez cette optimisation avec le suivi du coût des appels IA déjà en place, en distinguant tokens de cache et tokens standards — sans ce détail, une baisse de facture reste difficile à attribuer avec certitude au cache.

En résumé

Le prompt caching ne demande aucun node n8n dédié, mais il exige de sortir des nodes IA natifs pour construire l'appel à la main via HTTP Request — un contournement identique à celui déjà nécessaire pour les API Batch. En échange, les workflows qui réutilisent un gros prompt système ou un contexte volumineux à haute fréquence — classification par lots, agents conversationnels, AI Agent chargé d'outils — voient leur facture et leur latence baisser sensiblement, sans changer la qualité des réponses. Les workflows des Pack Inbox IA (79 €), Pack Assistant RAG (119 €) et Pack Conformité & Audit (149 €) — réunis dans le Bundle FlowKit Complet (269 € au lieu de 347 €) — sont construits sur des sous-nodes de modèle standards : brancher un appel HTTP Request avec cache_control en remplacement du node Chat Model, sur les étapes à fort volume, est une optimisation à ajouter une fois le workflow validé, pas un prérequis au démarrage.