6 Prompt Caching Tricks That Cut Your AI API Costs Overnight

Most teams running AI at scale are leaving money on the table. Not because they are using the wrong model or writing bad prompts—because they are re-sending the same thousands of tokens with every single API call and paying full price each time.

Prompt caching changes that math. For workloads where a significant portion of the prompt stays the same across requests—a system prompt with company knowledge, a long policy document, a fixed few-shot example set—caching the static portion means you process those tokens once and pay a fraction of the cost for every subsequent call.

The savings are not marginal. For the right workloads, the bill reduction is 50-90%. This post covers six concrete techniques for getting there.

Provider note: Most examples below reference Anthropic's Claude prompt caching, which is the most commonly deployed at the time of writing. The principles apply to OpenAI and Google's equivalent features, but implementation syntax differs. Check each provider's current documentation for specifics.

The Math Behind Prompt Caching

A typical customer support automation workflow might look like this:

• System prompt with company policies, product details, and response guidelines: 15,000 tokens
• User message: 200 tokens
• Total per request: 15,200 tokens

At Claude Sonnet 4.6 standard pricing (~$3.00/million input tokens), processing 10,000 requests per day costs:

• Without caching: ~$456/day in input tokens alone
• With caching (the 15,000-token system prompt cached at ~$0.30/million): ~$46/day

That is a $410/day difference on a single workflow. The output quality is identical. The only change is where in the request the cache boundary sits.

The 6 Techniques

1. Cache Your System Prompt — The Foundational Win

The single biggest impact change for most production workflows. If your system prompt is longer than 1,024 tokens (the minimum cacheable threshold for Claude) and does not change between requests, caching it is a straightforward optimization that requires minimal code change.

When this applies: Any automation with a substantial system prompt that stays constant across requests. Customer support bots, document analysis agents, classification pipelines, email generators—all of these typically have a large fixed system prompt.

How to implement with Claude:

{
  "system": [
    {
      "type": "text",
      "text": "Your full system prompt here...",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [
    {"role": "user", "content": "User's specific request"}
  ]
}

The cache_control flag signals that everything up to that point should be cached. Subsequent calls with the same prefix are served from cache at ~90% lower cost.

Expected savings: 60-90% reduction in input token costs for high-volume workflows with long system prompts.

2. Cache Reference Documents Inside the Prompt

Many AI workflows inject reference documents—product documentation, policy manuals, knowledge base articles—into the prompt alongside every request. If the same documents appear in every call, they are cacheable.

When this applies: RAG-lite patterns where you inject the same set of documents repeatedly rather than doing semantic retrieval. Classification workflows that include a full category definition document. Legal or compliance agents that always reference the same policy text.

How to implement: Structure your prompt so that the document content appears before the cache breakpoint, and the user's specific query appears after.

{
  "system": [
    {
      "type": "text",
      "text": "[Your static system prompt here]"
    },
    {
      "type": "text",
      "text": "[Full text of your reference document — 5,000 tokens]",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "User query about the document"}]
}

Every request now re-uses the cached document rather than re-processing it. The user query still gets fresh processing.

Practical tip: If your reference documents do change (updated policies, new product versions), structure the prompt so the stable parts are cached and the volatile parts remain outside the cache boundary. You can have one cache breakpoint in your prompt—plan its position carefully.

3. Cache Few-Shot Examples to Improve Consistency and Cut Costs

Few-shot prompting—including 3-10 examples of desired input/output behavior in the prompt—improves model consistency for structured tasks. The cost: those examples consume tokens on every single request.

If your examples are static (the same 5 examples every time), they are perfect caching candidates.

When this applies: Classification tasks with fixed example sets, formatting tasks where examples demonstrate the required output structure, extraction tasks with example input/output pairs.

How to implement: Place the few-shot examples before the cache breakpoint and the actual input after it.

{
  "system": [
    {
      "type": "text",
      "text": "You are a document classifier. Classify the document into one of: Invoice, Contract, Report, Correspondence.\n\nExamples:\nInput: 'Please find attached invoice #4521...' → Invoice\nInput: 'This agreement is entered into...' → Contract\n[...more examples...]",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "New document to classify: [document text]"}]
}

You keep all the consistency benefits of few-shot prompting while paying cached rates for the examples on every request after the first.

Expected savings: If your 5 examples total 2,000 tokens and you run 5,000 requests per day, caching the examples saves roughly $27/day at Claude Sonnet pricing—meaningful for a small optimization.

4. Structure Prompt Layers to Maximize Cache Hits

Prompt caching works best when the cached portion is identical across as many requests as possible. If you have three "tiers" in your prompt—base instructions, customer-specific customization, and request-specific content—structure them so the most stable tier is deepest and the most variable is last.

Prompt structure for maximum cache hits:

[Tier 1: Base system prompt — never changes] ← cache here
[Tier 2: Customer-specific rules — changes per customer] ← potentially cache per customer
[Tier 3: Request-specific context — changes per request] ← never cached

If you serve multiple customers with different configurations, you have two options:

• One shared cache for the base layer + uncached customer customization
• Separate cached prompts per customer configuration (works well if each customer sends high request volume)

Implementation principle: Think of caching as a commit point. Everything before the last cache_control marker gets cached together. Structure your prompt layers so that the cache breakpoint sits at the boundary between stable and variable content.

Pro Tip: If your prompt has content that is stable for 30 days and content that changes hourly, only cache the 30-day stable portion. Caching content that changes frequently is worse than not caching—you will constantly invalidate and rebuild the cache, paying write costs without getting read savings.

5. Use Caching for Conversation History in Multi-Turn Workflows

In multi-turn conversations or agentic workflows, the conversation history grows with each turn. Turn 10 of a conversation includes the full history of turns 1-9. Without caching, every turn re-processes the entire history.

With conversation caching: Cache the conversation history up to the most recent turn. Each new turn only processes the incremental new message, not the entire history again.

How it works:

{
  "messages": [
    {"role": "user", "content": "First message"},
    {"role": "assistant", "content": "First response"},
    {"role": "user", "content": "Second message"},
    {"role": "assistant", "content": "Second response"},
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "Third message", "cache_control": {"type": "ephemeral"}}
      ]
    }
  ]
}

The cache marker is placed at the end of the most recent user message. Everything before it (the full conversation history) is served from cache for the model's current response generation.

When this matters most: Long agentic loops, customer support conversations that extend across multiple messages, research agents that accumulate context over many retrieval steps. In a 20-turn conversation, the savings on re-processing turns 1-19 are substantial.

Expected savings: For a workflow with 15-turn average conversations and a 500-token average per turn, caching the history saves re-processing ~7,500 tokens on the final turn. At scale (1,000 conversations/day), that adds up quickly.

6. Monitor Cache Hit Rates and Optimize Around Them

Implementing caching without measuring whether it is working is like installing solar panels without checking the meter. Anthropic's API response includes cache hit/miss metadata—use it.

What to track:

// In the API response usage object:
{
  "input_tokens": 200,
  "cache_creation_input_tokens": 15000,  // tokens written to cache (first call)
  "cache_read_input_tokens": 15000       // tokens read from cache (subsequent calls)
}

• cache_creation_input_tokens: How many tokens were written to cache (you pay slightly more for the creation call)
• cache_read_input_tokens: How many tokens were served from cache (charged at the discounted rate)

What a good cache hit rate looks like: For a high-frequency workflow with a fixed system prompt, you should see cache_read_input_tokens dominating after the first call of each cache window. If you are seeing frequent cache_creation_input_tokens across what should be identical prompts, something in the cached portion is varying unexpectedly.

Common causes of low cache hit rates:

• Timestamps or dynamic values embedded in the "static" portion of the prompt
• Whitespace or formatting inconsistencies between calls
• The cacheable portion falls below the minimum token threshold
• Cache TTL expiring between low-frequency calls

In n8n: Log the usage object from each Claude API response to a Google Sheet or database. A simple dashboard showing cache hit rate over time tells you whether your optimization is holding and flags when it breaks.

For more on calculating and tracking AI costs in production, see How to Calculate Token Costs for an AI Project and Hidden AI Automation Costs No One Warns You About.

Quick Impact Assessment: Is Your Workflow a Good Caching Candidate?

Implementing Caching in n8n

In n8n's HTTP Request node calling the Claude API, add the cache_control field to the relevant sections of your request body JSON. The node fully supports custom request bodies, so the implementation is straightforward:

1. In your HTTP Request node, switch to body type: JSON
2. Structure your system prompt array with the cache_control object on the section to be cached
3. In the response body, log body.usage.cache_read_input_tokens to verify hits
4. Compare your API invoice before and after—the savings should be visible within 24 hours for high-volume workflows

For low-code implementations in Make.com or other platforms, the same JSON structure applies via the HTTP module.

The Broader Cost Optimization Picture

Prompt caching is one lever among several. For comprehensive AI cost reduction:

• Caching: Eliminate re-processing of repeated prompt content (this post)
• Model routing: Use cheaper models for simpler tasks, save capable models for complex ones
• Output length control: Explicit instructions on response length prevent verbose outputs that burn unnecessary output tokens
• Batching: Process requests in batches during off-peak hours where providers offer lower prices
• Prompt compression: Remove redundant information from prompts without losing meaning

Combining caching with model routing typically produces the largest combined savings—the right model at the right price for each task, with repeated content served from cache.

Want a cost audit of your current AI automation stack? Book a session at evalics.com/contact to identify your highest-impact cost reduction opportunities and implement them.