n8n Anthropic Prompt Caching: When the Toggle Pays Off

For most of 2026 the answer on the n8n forum was "you can't, put a Cloudflare Worker in front of the Anthropic credential." People did exactly that. Then two PRs shipped a real option, and the threads never quite caught up. Here's where it lives now:

The steps are boring, which is good. Click the Anthropic Chat Model hanging off your AI Agent, hit Add Option, pick Prompt Caching, choose a TTL. A notice appears telling you token counts are now "only an approximation of actual billable usage." Keep that notice in mind, because it's the reason most people think caching isn't working (more on that below).

Check your version before you go hunting for the option. My own self-hosted instance runs n8n 2.38.3. I opened the container and grepped the built node files: the Chat Model has the promptCaching option, and the Anthropic node's message.operation.js has zero references to caching. That matches the n8n release notes: the Message operation didn't get it until 2.42 on September 29.

One field, at the top level of the request body:

{ "cache_control": { "type": "ephemeral", "ttl": "5m" } }

That's Anthropic's automatic caching. Instead of you marking a specific block, the API puts the breakpoint on the last cacheable block of the request and caches everything up to it: tool definitions, then the system prompt, then the messages. No beta header. On the next request it looks backward up to 20 blocks for an entry an earlier request wrote, reads that part at a discount and writes the new tail.

The author of the Anthropic node PR tested it against the live API with a 9,138-token system prompt. The first cached call reported 3 regular input tokens and 9,135 cache-creation tokens; the identical repeat reported 3 input and 9,135 cache-read tokens. Same request, about 90% cheaper input on the second call (details in n8n PR #35804).

The design choice that matters: the breakpoint follows the last block, wherever that is. Whether that's great or terrible depends entirely on what your last block is.

Tool loops. This is the case it was built for.An AI Agent that calls four tools makes five model calls in one execution, and each call re-sends everything before it. Call two starts with call one's exact request, so the lookback finds call one's entry and bills that whole prefix as a read.

Here's the math on Claude Sonnet 5.5 ($2 per million input, $2.50 for 5-minute writes, and $0.10 for reads since Anthropic halved the read price on October 7). Assume 6,000 tokens of tools and system prompt, a 200-token user message, and four tool rounds that each add about 700 tokens:

That's a 67% cut on input, and it grows with longer loops because each extra call re-reads a bigger prefix. Output tokens are untouched, so the total bill drops less than that, but on agents with fat tool schemas input is usually the larger line.

Busy chat agents also win.If a user sends turn two within five minutes, the request for turn two starts with turn one's request, so the history reads from cache. That holds as long as your memory node replays the conversation byte for byte, which brings us to the traps.

Picture the most common n8n Claude workflow there is: a trigger fires, a 4,000-token system prompt classifies or rewrites one item (an email, a lead, a ticket), done. One model call per execution, no tools.

With the toggle on, the breakpoint lands on the user message, which is a different email every run. Run one writes an entry for "system prompt + email A." Run two computes the hash for "system prompt + email B," finds nothing, and walks back to the end of the system prompt. Nobody ever wrote an entry there, because writes only happen at the breakpoint. Anthropic's own docs describe this exact case: "You pay for a fresh cache write on every request and never get a read."

On Sonnet 5.5 that one-shot run goes from $0.0086 to $0.0108 with the 5-minute TTL (+25%), and to $0.0172 with the 1-hour TTL (+100%). At 30,000 runs a month that's $258 becoming $322 for nothing. An explicit breakpoint on the system block, with runs arriving faster than every five minutes, would have made the same run about $0.001.

The fix is the HTTP Request node, since neither Anthropic node lets you place the marker yourself. POST to https://api.anthropic.com/v1/messages with your Anthropic credential (or x-api-key and anthropic-version: 2023-06-01 headers) and put cache_control on the static block:

{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": {{ JSON.stringify($('Config').item.json.systemPrompt) }},
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [
    { "role": "user", "content": {{ JSON.stringify($json.emailBody) }} }
  ]
}

Now every run writes and reads at the same spot: the end of the system prompt. The email rides after the breakpoint as plain input. You lose the Anthropic node's convenience, but for a single call there's no tool loop to rebuild.

If you turned it on for an agent and see no reads, it's almost always one of these. I go deeper on the API side in my prompt cache miss diagnostics post; these are the n8n-flavored versions.

1. The prefix is too short.Below the model's minimum, the API silently skips caching. No error. Tools count toward the prefix, so a small system prompt plus a few tool schemas can still clear it.

One forum user had a 1,500-token booking prompt. That caches fine on Sonnet 4.6 or Haiku 5.5, and never caches on Haiku 4.5, which wants 4,096. If you're still on Haiku 4.5, that's one more reason to look at my Haiku 5.5 vs 4.5 cost breakdown.

2. Something in the system message changes every run. Today is {{ $now }} is the classic. It changes the prefix every second and every request misses. Same for a customer name or a record ID templated into the system message. Move per-run values into the user message.

3. Your memory window is sliding. Simple Memory and the Postgres or Redis chat memories keep the last N exchanges. Once a conversation passes N, the oldest message drops off the front, every message block after the system prompt shifts, and the cache misses on every turn from then on, paying the write premium each time. Raise the window for long chats or accept the misses. (Picking the memory backend itself is covered in Postgres vs Redis for n8n agent memory.)

4. Tools or settings change between calls. Tool definitions sit first in the cache order, so editing one invalidates everything. An MCP Client tool whose server returns its tool list in a different order does the same. Changing the effort or thinking options also invalidates the message history.

5. The gap is longer than the TTL. A lead-scoring agent that fires twice an hour will never see a 5-minute read across executions. It still gets reads inside each tool loop, which is usually where the money is anyway.

Not from the token count n8n shows. Both PRs deliberately add cache_creation_input_tokens and cache_read_input_tokens into the prompt token total, because Anthropic reports cached tokens outside input_tokens. Without that, turning caching on would have made usage look like it fell 99%. The upshot: a working cache and a broken cache show the same token count in n8n. The difference is in what each token costs.

To actually see it, use one of these:

• Anthropic node with Simplify Output off. The raw response includes the usage object with both cache fields. Run twice within the TTL and the second run should show reads.
• The Claude Console usage page for the API key your n8n credential uses. Compare daily input cost for a week before and after you flip the toggle.
• Tracing. If you already ship agent runs to Langfuse or similar, as I describe in n8n AI agent observability, log the raw usage per call and chart the read ratio per workflow.

Turn it on for every AI Agent that calls tools. Leave it off on single-call workflows and use the HTTP Request node with an explicit breakpoint when the system prompt is big. That one sentence covers nearly every Claude workflow I run in n8n. If you can rip out a Cloudflare Worker proxy you built in the spring for this, do it, unless that Worker places explicit breakpoints for one-shot traffic. In that case it's doing something the toggle can't.

I'd also default to the 5-minute TTL. The 1-hour write costs 2x base input, so it needs two reads just to break even. That only pays when executions are spaced 5 to 60 minutes apart and the prefix is big. For the general pricing picture outside n8n, my Anthropic prompt caching cost guide has the full breakdown.

How I checked this: option names, defaults and the top-level cache_controlpayload come from n8n PRs #34482 and #35804 and the built node files in my own n8n 2.38.3 container. Prices, minimums and the lookback rules are from Anthropic's prompt caching page, read on October 13, 2026. The dollar figures are computed from list prices for the token counts stated, not taken from an invoice.