Does n8n support Anthropic Prompt Caching in the AI Agent Node?

Hi n8n Community!

I am using n8n Cloud (Starter Plan) with the Anthropic Claude AI Agent Node to run AI booking agents for German small businesses (restaurants and beauty studios).

Anthropic recently recommended enabling Prompt Caching to reduce API costs significantly — up to 90% savings on system prompts that repeat with every message.

My use case:
• System prompt: ~1,500 tokens (repeats with every single message)
• Average conversation: 10–20 messages
• Multiple clients running simultaneously

Anthropic’s recommended approach (automatic caching):

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

My questions:

  1. Does n8n currently support Anthropic Prompt Caching in the AI Agent Node?
  2. If yes — where can I find the cache_control option? I checked:
    • AI Agent Node → Add Option (not there)
    • Anthropic Model Node → Add Option (not there)
  3. If not yet supported — is it on the roadmap?

This would be very valuable for anyone using long system prompts with the Anthropic AI Agent Node. The cost savings could be significant for production use cases.

Thank you for your help!

Best regards , KAMI1a

@kami1a not natively, the Anthropic Chat Model node doesnt expose cache_control so the agent wont set cache breakpoints on its own (theres an open feature request for it). what people do on n8n Cloud is point the Anthropic credentials Base URL at a small proxy (cloudflare worker) that injects “cache_control”: {“type”:“ephemeral”} into the request body before it reaches anthropic, caching the system+tools prefix. a few have it running in production. just keep the breakpoint on a stable prefix, moving markers or extended-thinking blocks break the cache hit.

Hey KAMI1a,

As an AI Automation Engineer running production workloads with Anthropic and n8n daily, I completely feel your pain. When you are running 10–20 messages per conversation across multiple clients, un-cached system prompts will absolutely eat your API budget alive.

@achamm is spot on—n8n doesn’t natively expose the cache_control parameter inside the Advanced Options of the Anthropic Chat Model node yet.

While we wait for native support to land on the roadmap, you don’t have to bleed API costs. The absolute best production-grade workaround right now is to intercept the request and inject the cache headers yourself.

Here is exactly how to set this up:

The Solution: The Cloudflare Worker Proxy Trick

Instead of sending requests from n8n directly to Anthropic, you point n8n to a lightweight, free Cloudflare Worker. The Worker takes n8n’s payload, injects the cache_control: {"type": "ephemeral"} block into the system prompt array, and forwards it to Anthropic.

1. Deploy the Cloudflare Worker

Create a new Cloudflare Worker and drop in a script that intercepts the incoming POST request body. Your JavaScript code inside the worker should look something like this:

JavaScript

export default {
  async fetch(request, env) {
    if (request.method === "POST") {
      let body = await request.json();
      
      // Inject cache_control into the system prompt if it exists
      if (body.system && typeof body.system === 'string') {
        body.system = [
          {
            type: "text",
            text: body.system,
            cache_control: { type: "ephemeral" }
          }
        ];
      }

      // Forward the modified request to 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. Update n8n Credentials

  1. Go to your Credentials manager in n8n and open your Anthropic API configuration.

  2. Toggle on the Base URL override option (you may need to enable advanced settings).

  3. Replace https://api.anthropic.com/v1 with your deployed Cloudflare Worker URL (e.g., https://your-worker-name.workers.dev).

Crucial Production Gotchas to Keep in Mind

Since you’re running this for real clients, keep these two rules in mind to make sure you actually get a cache hit:

  • Keep the Prefix Static: Anthropic requires the cached block (system prompt + tools) to be entirely stable. If your AI Agent node dynamically injects variable data (like the current time or a changing customer name) directly into the system prompt string, it will invalidate the cache every single turn. Keep dynamic data inside the user messages instead.

  • Mind the Token Minimum: Anthropic only triggers prompt caching if your prompt prefix is greater than 1,024 tokens (Sonnet/Opus). Since your system prompt is ~1,500 tokens, you’re perfectly in the clear, but keep this in mind if you try to scale down smaller prompts!

This little proxy middleware layer should drop your recurring message costs by up to 90% immediately until the native feature drops.

Let me know if you need any help tweaking the worker script to match your exact tool payload structure!

Hey @kami1a, great solution from @achamm and @Swapnil above. One thing worth adding for your specific setup, since you’re running a booking agent (likely with several tools attached, calendar lookup, availability check, booking creation, etc.), don’t forget the tools array also counts toward the cacheable prefix and needs its own cache_control breakpoint, not just the system prompt. Tool definitions are usually static and a great second place to cache, especially if your tool schemas are verbose.

In the Worker script above, you’d add the same cache_control block to the last tool in the body.tools array (Anthropic caches everything up to and including the marked block):

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

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

}

This way you’re caching both the system prompt and your tool definitions, which for a multi-tool booking agent can be a meaningful chunk of your token cost per turn.

Thank you very much. That’s very thoughtful of you! :heart:

Thank you very much. Merci :heart:

The proxy approach achamm described is the right fix for cache_control injection. One thing worth adding to the proxy while it is already in place: per-client cache efficiency tracking.

Anthropic’s response body returns cache_creation_input_tokens and cache_read_input_tokens in the usage object. The proxy sees this before forwarding the response. A small logging step writes:

{timestamp, client_id (from the X-Client-ID header you route on), model, cache_creation_input_tokens, cache_read_input_tokens, total_input_tokens}

A Google Sheets append or any lightweight append destination. After a week of data, the cache_read ratio per client (cache_read_input_tokens / total_input_tokens) shows where the 90% savings are actually landing versus where the proxy is injecting cache headers but the cache is evicting before reuse.

For your booking agent setup across restaurants and beauty studios, the likely pattern: clients with back-to-back sessions in the same hour will show high hit ratios because the cache is still warm. Clients with sparse bookings (one per hour or less) will show near-zero hit ratios. The 5-minute default cache TTL expires between calls, and you pay creation cost on every request.

Those low-hit-ratio clients are the ones to optimize for. Two options: restructure the system prompt so the stable segment (the part that does not change between calls) is first and longer, covering more of the token cost when the cache does hit; or add a session warmup call at the start of each booking window (a lightweight no-op message that refreshes the cache before real traffic starts). ShawnWilliams’s point about the tools array applies here too: if tool definitions are being re-cached every call, restructuring those separately from the system prompt can improve the hit window.

The monitoring data tells you which clients have the problem and how much it costs per week. Without it, you are optimizing for aggregate averages across clients with very different booking patterns.

@cadence_flows this is the right diagnostic. Per-client cache_read ratio is how you stop optimizing for the restaurant that keeps the 5-minute window warm and treating the sparse beauty studio as “prompt caching isn’t working.”

One gap that ratio will also surface, that the Worker can’t close: prefix cache and whole-request identity are different mechanisms.

cache_read_input_tokens only counts Anthropic reusing a prefix inside the ephemeral TTL. For kami1a’s sparse clients, that number going to zero is expected — the cache expired, you pay creation again. Warmup and putting the stable segment first will help when the next call lands inside the window.

What that usage object still can’t see: two studios asking “is 2pm free on Saturday?”, or the same FAQ twice in a day, are often byte-identical whole requests. Once the prefix TTL is gone, prompt caching has nothing to replay. An exact-match layer in front of Anthropic serves those as a HIT instead of creating a new prefix cache every time. It stacks with the proxy you already described: cache_control still fires on a miss; identical full calls never reach Anthropic.

That’s the unfashionable half we built at Metrecept — MISS then HIT, signed receipt you can check in the browser: Waste demo — miss → HIT, then verify the receipt · Metrecept

If you log cache_read ratio per client, the low-ratio rows are the ones to inspect for duplicate whole requests, not just a cold prefix. Different fix, same spreadsheet.

New version n8n@2.42.0 got released which includes the GitHub PR 35804.