n8n supporte-t-il Anthropic Prompt Caching dans le nœud AI Agent ?

Salut à la communauté n8n !

J’utilise n8n Cloud (Plan Starter) avec le nœud Anthropic Claude AI Agent pour exécuter des agents de réservation IA pour les petites entreprises allemandes (restaurants et studios de beauté).

Anthropric a récemment recommandé d’activer le Prompt Caching pour réduire considérablement les coûts des API — jusqu’à 90 % d’économies sur les invites système qui se répètent à chaque message.

Mon cas d’usage :
• Invite système : ~1 500 tokens (se répète à chaque message)
• Conversation moyenne : 10–20 messages
• Plusieurs clients s’exécutant simultanément

Approche recommandée par Anthropric (mise en cache automatique) :

Exemple Python :
response = client.messages.create(
model=“claude-sonnet-4-6”,
max_tokens=1024,
cache_control={“type”: “ephemeral”},
system=“Your system prompt here…”,
messages=[…]
)

Mes questions :

  1. Est-ce que n8n supporte actuellement le Prompt Caching d’Anthropric dans le nœud AI Agent ?
  2. Si oui — où puis-je trouver l’option cache_control ? J’ai vérifié :
    • AI Agent Node → Add Option (pas là)
    • Anthropic Model Node → Add Option (pas là)
  3. Si ce n’est pas encore supporté — est-ce au programme ?

Ce serait très utile pour tous ceux qui utilisent de longues invites système avec le nœud Anthropic AI Agent. Les économies de coûts pourraient être importantes pour les cas d’usage en production.

Merci pour votre aide !

Cordialement, KAMI1a

@kami1a non nativement, le nœud Anthropic Chat Model n’expose pas cache_control donc l’agent ne définira pas les points de rupture de cache de lui-même (il y a une demande de fonctionnalité ouverte pour cela). ce que les gens font sur n8n Cloud, c’est pointer l’URL de base des identifiants Anthropic vers un petit proxy (cloudflare worker) qui injecte « cache_control »: {« type »:« ephemeral »} dans le corps de la requête avant qu’elle n’atteigne anthropic, en mettant en cache le préfixe système+outils. quelques-uns l’ont en production. gardez simplement le point de rupture sur un préfixe stable, déplacer des marqueurs ou des blocs extended-thinking casse le cache hit.

Salut KAMI1a,

En tant qu’ingénieur en automatisation IA exécutant quotidiennement des charges de production avec Anthropic et n8n, je comprends parfaitement ta frustration. Quand tu exécutes 10–20 messages par conversation sur plusieurs clients, les system prompts non mis en cache vont absolument dévorer ton budget API.

@achamm a tout à fait raison—n8n n’expose pas nativement le paramètre cache_control dans les Options avancées du nœud Anthropic Chat Model pour le moment.

En attendant que le support natif arrive sur la feuille de route, tu n’as pas besoin de saigner ton budget API. Le meilleur contournement de qualité production en ce moment est d’intercepter la requête et d’injecter toi-même les en-têtes de cache.

Voici exactement comment mettre ça en place :

La Solution : L’astuce du proxy Cloudflare Worker

Au lieu d’envoyer les requêtes de n8n directement à Anthropic, tu pointes n8n vers un Worker Cloudflare léger et gratuit. Le Worker récupère le payload de n8n, injecte le bloc cache_control: {"type": "ephemeral"} dans le tableau du system prompt, et le transmet à Anthropic.

1. Déployer le Cloudflare Worker

Crée un nouveau Cloudflare Worker et colle un script qui intercepte le corps de la requête POST entrante. Ton code JavaScript à l’intérieur du worker devrait ressembler à ceci :

JavaScript

export default {
  async fetch(request, env) {
    if (request.method === "POST") {
      let body = await request.json();
      
      // Injecter cache_control dans le system prompt s'il existe
      if (body.system && typeof body.system === 'string') {
        body.system = [
          {
            type: "text",
            text: body.system,
            cache_control: { type: "ephemeral" }
          }
        ];
      }

      // Transmettre la requête modifiée à Anthropic
      const modifiedRequest = new Request("https://api.anthropic.com/v1/messages", {
        method: "POST",
        headers: request.headers,
        body: JSON.stringify(body)
      });

      return fetch(modifiedRequest);
    }
    return new Response("Method not allowed", { status: 405 });
  }
};

2. Mettre à jour les identifiants n8n

  1. Va dans ton gestionnaire Credentials dans n8n et ouvre ta configuration API Anthropic.

  2. Active l’option de remplacement Base URL (tu devras peut-être activer les paramètres avancés).

  3. Remplace https://api.anthropic.com/v1 par l’URL de ton Cloudflare Worker déployé (par exemple, https://your-worker-name.workers.dev).

Les pièges critiques de production à retenir

Puisque tu exécutes ça pour de vrais clients, garde ces deux règles en tête pour t’assurer que tu obtiens réellement un cache hit :

  • Garde le préfixe statique : Anthropic exige que le bloc mis en cache (system prompt + outils) soit entièrement stable. Si ton nœud AI Agent injecte dynamiquement des données variables (comme l’heure actuelle ou le nom d’un client changeant) directement dans la chaîne du system prompt, ça invalidera le cache à chaque tour. Garde les données dynamiques à l’intérieur des messages utilisateur à la place.

  • Fais attention au minimum de tokens : Anthropic déclenche le cache du prompt seulement si ton préfixe de prompt est supérieur à 1 024 tokens (Sonnet/Opus). Puisque ton system prompt fait ~1 500 tokens, tu es parfaitement couvert, mais garde ça en tête si tu essaies de réduire les prompts plus petits !

Cette petite couche de middleware proxy devrait réduire immédiatement tes coûts de messages récurrents de jusqu’à 90 % jusqu’à ce que la fonctionnalité native arrive.

Fais-moi savoir si tu as besoin d’aide pour ajuster le script du worker pour qu’il corresponde à ta structure de payload d’outils exacte !

Salut @kami1a, super solution de la part de @achamm et @Swapnil ci-dessus. Un détail important à ajouter pour ta configuration spécifique, puisque tu exécutes un agent de réservation (probablement avec plusieurs outils attachés, recherche calendrier, vérification de disponibilité, création de réservation, etc.), n’oublie pas que le tableau tools compte aussi dans le préfixe pouvant être mis en cache et nécessite son propre point de rupture cache_control, pas seulement le system prompt. Les définitions d’outils sont généralement statiques et constituent un excellent deuxième endroit pour mettre en cache, surtout si tes schémas d’outils sont détaillés.

Dans le script Worker ci-dessus, tu ajouterais le même bloc cache_control au dernier outil du tableau body.tools (Anthropic met en cache tout ce qui se trouve jusqu’au bloc marqué inclus) :

if (body.tools && body.tools.length > 0) {

  body.tools[body.tools.length - 1].cache_control = { type: "ephemeral" };

}

De cette façon, tu mets en cache à la fois le system prompt et tes définitions d’outils, ce qui pour un agent de réservation multi-outils peut représenter une part significative de ton coût en tokens par tour.

Merci beaucoup. C’est très gentil de votre part ! :heart:

Merci beaucoup. Merci :heart:

L’approche proxy qu’achamm a décrite est la bonne solution pour l’injection de cache_control. Une chose utile à ajouter au proxy pendant qu’il est déjà en place : le suivi de l’efficacité du cache par client.

Le corps de réponse d’Anthropic retourne cache_creation_input_tokens et cache_read_input_tokens dans l’objet usage. Le proxy voit cela avant de transférer la réponse. Une petite étape de journalisation écrit :

{timestamp, client_id (depuis l’en-tête X-Client-ID sur lequel vous routez), model, cache_creation_input_tokens, cache_read_input_tokens, total_input_tokens}

Vers Google Sheets ou n’importe quelle destination d’ajout légère. Après une semaine de données, le ratio cache_read par client (cache_read_input_tokens / total_input_tokens) montre où les économies de 90 % se concrétisent vraiment par rapport à l’endroit où le proxy injecte les en-têtes de cache mais où le cache s’évince avant la réutilisation.

Pour votre configuration d’agent de réservation sur les restaurants et les studios de beauté, le schéma probable : les clients avec des sessions dos à dos dans la même heure afficheront des ratios de hit élevés car le cache est encore chaud. Les clients avec des réservations éparses (une par heure ou moins) afficheront des ratios de hit quasi nuls. Le TTL de cache par défaut de 5 minutes expire entre les appels, et vous payez le coût de création à chaque demande.

Ce sont les clients avec un faible ratio de hit que vous devez optimiser. Deux options : restructurer le système prompt de sorte que le segment stable (la partie qui ne change pas entre les appels) soit d’abord et plus long, couvrant plus du coût en tokens quand le cache fait un hit ; ou ajouter un appel de préchauffage de session au début de chaque fenêtre de réservation (un message sans opération léger qui rafraîchit le cache avant le trafic réel). Le point de ShawnWilliams sur le tableau tools s’applique aussi ici : si les définitions d’outils sont mises en cache à chaque appel, les restructurer séparément du système prompt peut améliorer la fenêtre de hit.

Les données de monitoring vous disent quels clients ont le problème et combien cela coûte par semaine. Sans cela, vous optimisez pour les moyennes agrégées sur les clients avec des schémas de réservation très différents.

@cadence_flows c’est le bon diagnostic. Le ratio cache_read par client, c’est comment tu arrêtes d’optimiser pour le restaurant qui garde la fenêtre de 5 minutes chaude et de traiter le studio de beauté clairsemé comme si « la mise en cache rapide ne fonctionnait pas ».

Une lacune que ce ratio va aussi mettre en évidence, que le Worker ne peut pas combler : le cache de préfixe et l’identité de l’ensemble de la requête sont des mécanismes différents.

cache_read_input_tokens compte seulement quand Anthropic réutilise un préfixe dans le TTL éphémère. Pour les clients clairsemés de kami1a, ce nombre qui tombe à zéro, c’est attendu — le cache a expiré, tu paies la création à nouveau. Le préchauffage et la mise du segment stable en premier vont aider quand l’appel suivant arrive dans la fenêtre.

Ce que cet objet usage ne peut toujours pas voir : deux studios qui demandent « est-ce que 14h est libre samedi ? », ou la même FAQ deux fois dans une journée, sont souvent des requêtes entières identiques à l’octet près. Une fois que le TTL du préfixe est parti, la mise en cache rapide n’a rien à rejouer. Une couche d’appariement exact devant Anthropic les sert en HIT au lieu de créer un cache de préfixe neuf à chaque fois. Ça s’empile avec le proxy que tu as déjà décrit : cache_control tire quand même sur un manque ; les appels complets identiques n’atteignent jamais Anthropic.

C’est la moitié peu à la mode qu’on a construite chez Metrecept — MISS puis HIT, reçu signé que tu peux vérifier dans le navigateur : Waste demo — miss → HIT, then verify the receipt · Metrecept

Si tu enregistres le ratio cache_read par client, les lignes avec un faible ratio, c’est celles à inspecter pour les requêtes entières dupliquées, pas juste un préfixe froid. Différent correctif, même feuille de calcul.

La nouvelle version n8n@2.42.0 a été publiée, qui inclut la demande de fusion GitHub 35804.