On this page
TLDR
Prompt caching reduces cost (~90%) on repeated context like long system prompts and tool definitions. Cache breakpoints, TTL, and cache_control field placement are exam patterns.
What you are deciding
Prompt caching reuses an identical prompt prefix across requests: you mark where the stable part ends with a cache breakpoint, the first request writes the cache, and later matching requests read it at a lower price. Place the breakpoint after the content that does not change.
Where does the stable prefix end, and will repeat requests actually hit the cache?
What it is
Prompt caching is a cost optimization that lets you reuse expensive prompt tokens across multiple API calls. Mark a section with cache_control: {type: "ephemeral"}, and Claude caches those tokens for 5 minutes. Every subsequent API call within the TTL with the same cached section pays ~90% less for those tokens. The cache is a memory optimization for the model's KV cache.
The cached section persists across turns in agentic loops, so it's ideal for content that doesn't change: system prompts, tool definitions, large reference docs, fact blocks. A single FIXED manual breakpoint won't track a growing message list (the content past that point keeps changing). But automatic caching handles this differently: its cache breakpoint moves forward on every request, so the growing conversation history itself IS cached turn-over-turn as a stable, advancing prefix — you don't re-mark it each time.
The cache has a 5-minute TTL by default, extendable to 1 hour. After 5 minutes of no access, the cache expires and the next call re-reads at full token cost. Intentional design: caching is for bursty workloads (a customer support loop running for 5 minutes), not permanent storage.
Production failures cluster around two gaps: caching content that changes (placing a FIXED manual breakpoint on content that mutates every call — genuinely a miss, though automatic caching's moving breakpoint avoids this for the message history specifically) and underscoping what's cacheable (not caching the system prompt when it's the biggest savings). A 1000-token system prompt called 10 times costs 10,000 fresh; with caching, ~1100 (89% savings).
How each certification frames it
CCD-F: How CCD-F tests caching and cost management
CCDVF-D5-O4Cost and Token Management: token budgeting and cost management techniques for Claude applications, including token usage tracking, cost modeling, and caching techniques (prompt caching, cache check-pointing) for cost optimizationCCDVF-D2-O3Claude API Mechanics: Claude API behavior and mechanics, including messages, tools, streaming, vision, thinking, caching, invoking Claude through third-party vendors, Messages API data access patterns, batch API use, and tradeoffs between realtime and batch API selection
Two Developer objectives meet here: cost and token management, including prompt caching and cache check-pointing (PDF page 7, Domain 5), and Claude API mechanics, which lists caching among the API behaviors (PDF page 6, Domain 2).
This page answers the tagged decisions on breakpoint placement, cache checkpointing, the basics of how caching works, and read and write pricing.
CCA-P: How CCA-P frames prompt reuse
CCARP-D2-O5Implement prompt reuse strategies (caching, modular prompts, Skills)
The Professional objective is to implement prompt reuse strategies: caching, modular prompts and Skills (PDF page 4, Domain 2). The architect decides whether a workload has a stable prefix worth caching and compares it with the alternatives, not the exact request fields.
How it works
Caching is enabled by adding cache_control: {type: "ephemeral"} to a section. Both system and messages arrays support this. On the first call, Claude reads and caches. On the second (within 5 min) with identical content, Claude skips re-reading and uses the cached KV state, paying only the lookup cost (~10% of original).
The cache key is the exact content. Send the system prompt with a typo on turn 1, fix on turn 2 → cache miss. The content changed, turn 2 caches a new version, starts a new 5-minute window. Why immutable content is crucial for a manual, fixed breakpoint: refund policy (never changes), tool definitions (stable), customer facts (extracted once) are cacheable that way. The growing message list needs a DIFFERENT mechanism — automatic caching's moving breakpoint — rather than a fixed manual one.
The TTL is 5 minutes by default. Within 5 min, cache survives; after 5 min of no access, expires. Extend to 1 hour via cache_control: {type: "ephemeral", ttl: "1h"} (the ttl field, not max_tokens — 1-hour writes cost 2x base input price vs 1.25x for 5-minute writes). Longer loops re-cache automatically (cache expires, next call caches again).
Caching is isolated per workspace within an organization (per-organization on Bedrock and Google Cloud), not globally and not strictly per-conversation. Two different conversations — or two different subagents — CAN share the same cache if they send byte-identical content within the same workspace; the cache key is the content, not the conversation. Different workspaces never share a cache. A FIXED manual breakpoint won't track a growing conversation, but automatic caching's moving breakpoint does cache the growing history itself, turn over turn, as the stable prefix advances.
Worked example: a stable policy prefix and a changing question
Authored teaching example, not a bank question.
A support assistant sends the same tool definitions, system prompt and a long policy document with every request. Only the customer's question changes.
| Request | Prefix | Expected usage fields |
|---|---|---|
| 1 | Tools, system, policy document, question A | cache_creation_input_tokens above zero |
| 2 (within five minutes) | Same tools, system, policy document, question B | cache_read_input_tokens above zero; input_tokens covers only the new question |
| 3 (system text edited) | Changed tools, system or policy document, then question C | Miss: the changed prefix writes a new entry, so cache_creation_input_tokens is positive and cache_read_input_tokens is zero |
| 4 (after the lifetime passed, no reuse) | Same prefix | The entry may have expired, so expect a new write |
| 5 (prompt below the model's minimum length) | Prefix too short to cache | Not cached: both cache fields are zero and no error is returned |
Repeat requests pay the lower read price for the policy prefix. Check afterwards by logging the usage fields per request and confirming reads on the second and later calls within the lifetime.
How this decision goes wrong
Changing the cached prefix
Looks right: A timestamp or request id at the top of the system prompt helps debugging.
Why it fails: Cache hits need identical prompt segments up to the breakpoint. Anything that changes earlier invalidates that level and every level after it.
Instead: Keep volatile values after the breakpoint, and keep tool definitions and system text stable.
Assuming every request hits the cache
Looks right: The marker is in the code, so every call is cheaper.
Why it fails: A changed prefix is a miss that writes a new entry. A prompt below the model's minimum length is not cached at all and no error is returned. Entries also expire after their lifetime.
Instead: Check cache_creation_input_tokens and cache_read_input_tokens in the usage of real responses: positive reads are hits, positive creation after a change is a miss and write, and two zeros mean not cached.
Ignoring cache write cost
Looks right: Caching always saves money.
Why it fails: A write costs more than normal input. A prefix used only once pays the write premium and never earns a read discount.
Instead: Cache prefixes that repeat within the lifetime; use the longer one-hour lifetime only when reuse is spaced out and justifies its higher write price.
Where you'll see it
Customer support loop with cached system prompt
15-turn refund conversation. System prompt (1000 tokens) cached on turn 1. Turns 2-15 reuse, paying ~100 tokens each instead of 1000. Total savings: 8100 tokens, ~30% off the conversation cost.
Parallel subagents with shared tool definitions
Coordinator spawns 4 subagents to analyze 4 repos. Each gets the same 5-tool definition (400 tokens). With caching, first subagent caches (400 tokens), 2-4 reuse (~40 each). 1200 tokens saved, 75% off tool-definition cost.
Show 2 more examples
Long-context loop with immutable fact block
Invoice extraction loop, 50 invoices. System prompt + a 200-token customer-facts block both cached. All 50 extractions reuse both. ~60,000 tokens saved over 50 calls, 95% on fixed content.
Batch-job polling with consistent system rules
Overnight batch processing 1000 documents. System prompt cached once, 1000 calls reuse. Cache expires after 5 min of no access (end of first batch). Next batch starts fresh window. 90% savings on system-prompt overhead.
Code examples
from anthropic import Anthropic
client = Anthropic()
SYSTEM_PROMPT = """You are a customer support agent enforcing a $500 lifetime refund limit. Always verify customer first."""
TOOLS = [
{"name": "verify_customer", "description": "Verify identity, retrieve refund history. Call first.", "input_schema": {...}},
{"name": "lookup_order", "description": "Look up order by customer + order ID.", "input_schema": {...}},
{"name": "process_refund", "description": "Process refund. Call only after verify + lookup.", "input_schema": {...}},
]
def run_support(customer_id: str, request: str):
messages = [{"role": "user", "content": request}]
for i in range(10):
resp = client.messages.create(
model="claude-opus-4-5",
max_tokens=1024,
# Cache the system prompt (90% savings on turns 2+)
system=[{
"type": "text",
"text": SYSTEM_PROMPT,
"cache_control": {"type": "ephemeral"},
}],
# Tools also cached in the SDK by default
tools=TOOLS,
messages=messages,
)
if resp.stop_reason == "end_turn":
return resp.content[0].text
messages.append({"role": "assistant", "content": resp.content})
# ... handle tool_use, append tool_result ...
return "max_iterations"
# Turn 1: full cost (~1500 tokens for system + tools)
# Turns 2-10: cached (~150 tokens each = 90% savings)Looks right, isn't
Each row pairs a plausible-looking pattern with the failure it actually creates. These are the shapes exam distractors are built from.
A single fixed manual cache_control marker on the message list will keep it cached as the conversation grows.
A FIXED marker won't — the list grows every turn, so a one-time breakpoint misses everything added since.
Use automatic caching instead, which moves its breakpoint forward each request and does correctly cache the growing history as a stable, advancing prefix.
Use ephemeral caching for frequently-updated content like daily news.
Ephemeral caching is for content that doesn't change within 5 minutes.
Daily-updated content causes cache misses on every change. Cache only immutable content.
Enable caching on the longest document in the prompt.
Enable on immutable content, not just long.
A 10,000-token policy doc that never changes is perfect. A 500-token fact block updated every turn is not. Cache what's constant.
Caching is global; once enabled, applies to all conversations.
Not fully global, but not strictly per-conversation either: caching is isolated per workspace (per-organization on Bedrock/GCP).
Identical content sent from different conversations, or different subagents, in the *same* workspace CAN share a cache hit — the cache key is the content, not the conversation.
After 5 minutes the cache extends automatically.
After 5 minutes of no access, the cache expires completely.
Next call re-reads at full cost, then starts a new 5-minute window. Plan for cache expiry in long-running loops.
Side-by-side
| Aspect | Cached (5min) | Cached (1hr+) | Not cached | Batch API (50%) |
|---|---|---|---|---|
| Content type | Immutable system, tools | Recurring reference docs | Content that changes every call, or misses a fixed manual breakpoint | Non-urgent bulk |
| TTL | 5 min default | 1 hr configurable | None | Up to 24 hr |
| Savings | 90% per reuse | 90% per reuse | 0% | 50% flat |
| Use when | Repeated calls same prompt | Recurring queries | First call or content changes | Can wait for results |
| Cost first call (cache write) | 125% (1.25x) | 200% (2x) | 100% | 100% of the batch rate |
| Cost 2nd-10th call | 10% each | 10% each | 100% each | 50% each |
Decision tree
Running an agentic loop (5+ turns) with the same system prompt?
Is the content constant within 5 minutes?
Large reference doc reused across calls?
Loop longer than 5 minutes?
Caching or Batch API?
The exam trap
Assuming a cache_control marker makes every request cheaper. A change anywhere before the breakpoint is a miss that writes a new entry, a prompt below the model's minimum length is not cached and returns no error, and a prefix used only once pays the write premium without ever earning a read. Check cache_creation_input_tokens and cache_read_input_tokens on real responses.
Question patterns
CCD-F practice questions
3 approved CCD-F questions for this topic. Tap an answer to check it, then read the rationale for every option.
A coding agent is midway through a multi-day repository migration, tracking dozens of completed and pending steps across many turns. Per Anthropic's context-engineering guidance, which of the three context-window management techniques is best suited to this specific scenario, and why?
CCA-F practice questions
3 approved CCA-F questions for this topic. Tap an answer to check it, then read the rationale for every option.
Your project root CLAUDE.md is 1,500 lines and Claude's responses are getting slower. Why, and what is the fix?
CCA-P practice questions
No approved public CCA-P sample question is published for this topic yet. The worked example above is an authored teaching example.
Frequently asked
Showing 13 of 13 questions
cache_control: { type: "ephemeral", ttl: "1h" } (the ttl field — not max_tokens, which is unrelated). A 1-hour write costs 2x base input price vs 1.25x for the default 5-minute write.Sources and next steps
- Claude Certified Developer - Foundations Exam Guide v1.0 (July 2026), PDF page 7, section: Domain 5: Model Selection and Optimization (Model Selection and Tradeoffs, Cost and Token Management). Checked 2026-10-16.
- Claude Certified Developer - Foundations Exam Guide v1.0 (July 2026), PDF page 6, section: Domain 2: Applications and Integration (Claude API Mechanics, Claude Application Design). Checked 2026-10-16.
- Claude Certified Architect - Professional Exam Guide v1.0 (July 2026), PDF page 4, section: Domain 2: Claude Models, Prompting & Context Engineering, detailed objectives. Checked 2026-10-16.
- Prompt caching (Claude API docs), section: Cache breakpoints, prefix order, pricing, minimum length, invalidation, usage fields. Checked 2026-10-16.
CCD-F exam guide: Domain 5, Model Selection and Optimization