Prompt Caching Claude: Cut Costs and Latency in Production

Prompt caching claude is one of the highest-leverage techniques available to architects building production agents. By marking stable portions of a prompt as cacheable, you instruct the API to store those tokens server-side and reuse them across subsequent requests, cutting both latency and cost for every call that hits the cache. This post explains the mechanics, the tradeoffs, and how the concept maps to Domain 5: Context Management & Reliability on the CCAR-F exam.

What is prompt caching and how does it work in Claude?

Prompt caching lets you designate a prefix of your prompt as a cache breakpoint. When the API receives a subsequent request whose prefix matches a cached breakpoint exactly, it skips reprocessing those tokens and returns results faster. The cached prefix can include your system prompt, large reference documents, tool definitions, or any other stable content that repeats across calls.

The key constraint is exact prefix matching. The cached content must appear at the start of the prompt, and every byte up to the breakpoint must be identical to the previously cached version. A single character difference invalidates the cache hit.

Anthropic documents the feature in its prompt caching guide, which covers supported models, TTL behaviour, and pricing adjustments.

Which Claude models support prompt caching?

Per Anthropic's documentation, prompt caching is supported on Claude 3.5 Sonnet, Claude 3.5 Haiku, Claude 3 Opus, and Claude 3 Haiku. The feature is not available on all model versions, so architects should verify model compatibility before designing a caching strategy into a production pipeline.

Always confirm current support in the Anthropic model documentation before committing to a design, as availability can change with new releases.

How do you implement a cache breakpoint in the API?

You add a cache_control object with type: "ephemeral" to the content block you want cached. The breakpoint sits at the end of that block; everything before it is eligible for caching.

{
  "model": "claude-3-5-sonnet-20241022",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "You are a senior code reviewer. Apply the following style guide verbatim:\n\n[...5000 tokens of style guide content...]",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [
    {
      "role": "user",
      "content": "Review this pull request for style violations."
    }
  ]
}

In this pattern, the style guide is cached after the first request. Every subsequent review call that sends the identical system block pays only for the shorter user turn, not for re-ingesting the full guide.

For multi-turn conversations, you can place a second breakpoint at the end of the conversation history, caching both the system prompt and the accumulated turns:

{
  "model": "claude-3-5-sonnet-20241022",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "[...stable system prompt...]",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [
    {"role": "user", "content": "Turn 1 content"},
    {"role": "assistant", "content": "Turn 1 response"},
    {
      "role": "user",
      "content": [
        {
          "type": "text",
          "text": "Turn 2 content",
          "cache_control": {"type": "ephemeral"}
        }
      ]
    }
  ]
}

The second breakpoint caches the conversation history up to that point, so the next turn only processes the new message.

What is the cache TTL and what happens on a miss?

Anthropic sets the cache time-to-live (TTL) at five minutes. If no request hits the cache within that window, the cached content is evicted and the next call incurs a full cache-write cost. Architects designing infrequently-called agents should account for this: a pipeline that fires once every ten minutes will almost never benefit from caching and may actually pay a small premium for the write.

The five-minute TTL means caching is best suited to:

• High-frequency pipelines (multiple calls per minute)
• Batch jobs that process many items against the same system prompt in a single run
• Interactive agents where a user sends several messages in a session

When does prompt caching hurt rather than help?

Caching is not universally beneficial. Several patterns undermine its value or actively increase costs.

Volatile prefixes. If your system prompt includes a timestamp, a request ID, or any per-call variable, the prefix changes on every request and the cache never hits. Move dynamic content to the user turn or to a separate content block placed after the breakpoint.

Low call frequency. As noted above, a five-minute TTL means a pipeline that calls the API once every six minutes will pay cache-write costs on every request with zero cache hits.

Short stable prefixes. Anthropic sets a minimum cacheable token count (currently 1024 tokens for most models). Attempting to cache a 200-token system prompt produces no benefit; the API simply ignores the breakpoint.

Misplaced breakpoints. The breakpoint must sit at the boundary between stable and dynamic content. A breakpoint placed mid-way through a section that changes per request forces a cache miss on every call.

This maps directly to the CCAR-F exam's preference for deterministic, proportionate solutions. The exam consistently rewards architects who apply caching where it genuinely reduces cost and latency, not as a reflexive pattern applied to every prompt.

How does prompt caching relate to context window management?

Prompt caching and context window management are complementary but distinct. Context window management (Domain 5 of CCAR-F, weighted at 15%) concerns how you structure, compress, and prioritise the information that fits within a single request. Prompt caching concerns how you avoid reprocessing stable portions of that information across multiple requests.

The attention dilution problem is a related concern: as context grows, the model's attention spreads thinner and performance on items buried in the middle degrades. Prompt caching does not solve attention dilution; it reduces the cost of sending large contexts repeatedly. Architects must address both problems independently.

A practical architecture for a long-running agent might combine:

1. Prompt caching for the stable system prompt and tool definitions
2. Summary injection for fresh sessions to compress accumulated conversation history
3. Semantic retrieval to pull only the relevant chunks of a large knowledge base into each request

This layered approach keeps individual requests focused while amortising the cost of stable content across many calls.

How does prompt caching affect the CCAR-F exam?

The CCAR-F exam (60 items, 120-minute time limit, passing score 720 on a 100-to-1000 scale) tests practical judgment in scenario-based questions. Prompt caching appears most directly in Domain 5 (Context Management & Reliability, 15%) and Domain 4 (Prompt Engineering & Structured Output, 20%), but it also surfaces in Domain 1 (Agentic Architecture & Orchestration, 27%) when questions involve multi-agent pipelines with shared system prompts.

Exam scenarios typically present a production system with a cost or latency problem and ask which change produces the most improvement. The correct answer almost always involves identifying the stable, high-token content (system prompt, reference documents, tool schemas) and placing a cache breakpoint at its boundary, rather than restructuring the entire pipeline.

The exam also tests the inverse: recognising when caching is the wrong tool. A scenario describing a low-frequency batch job or a system prompt that changes per user should lead you away from caching and toward other cost controls such as model tier selection or context management strategy selection.

What are the pricing implications of prompt caching?

Anthropic prices cache writes at a premium over standard input tokens and cache reads at a significant discount. The exact multipliers are published in the Anthropic pricing page and vary by model. The general structure is:

• Cache write: slightly more expensive than a standard input token (you pay to store it)
• Cache read: substantially cheaper than a standard input token (you save on reprocessing)
• Break-even point: depends on how many times the cache is hit within the TTL window

For a system prompt of 10,000 tokens sent 50 times in a five-minute window, the savings on cache reads far outweigh the single cache-write cost. For the same prompt sent twice in an hour, the cache-write premium produces a net cost increase.

This pricing structure makes the break-even calculation straightforward: if you expect more than roughly two cache reads per write within the TTL window, caching saves money. Below that threshold, it costs more.

How should architects structure prompts to maximise cache hits?

The single most important design rule is stability before variability. Structure every prompt so that content ordered by decreasing stability:

1. System prompt (most stable, cache here first)
2. Tool definitions and schemas (stable per deployment)
3. Reference documents or knowledge base excerpts (stable per task type)
4. Conversation history (changes per turn, cache at the latest stable turn)
5. Current user message (always dynamic, never cached)

This ordering maximises the length of the cacheable prefix and therefore the token savings per cache hit. It also aligns with the structured context passing patterns that the CCAR-F exam rewards in multi-agent scenarios.

For agents that use parallel subagent spawning, a shared system prompt cached once and reused across all subagent calls can produce substantial savings at scale, since each subagent call independently benefits from the same cache hit.

What should I practise to master this topic?

Our concept library at /concepts covers 174 atomic concepts mapped to all five CCAR-F domains. For prompt caching specifically, the most relevant adjacent concepts are context management strategy selection, attention dilution, and prompt engineering fundamentals. Working through scenario-based practice questions that present cost and latency problems is the most direct preparation, since the exam tests judgment about when to apply the technique rather than recall of its syntax.

AI Skill Certs is an independent prep platform and is not affiliated with or endorsed by Anthropic.