Stop Re-Sending the Same Big Block: Prompt Caching for Context

July 24, 2026 · Claude Certified Architect (CCA) Prep (part 46)

▶ Watch on YouTube & subscribe to The Stack Underflow

Every call to your agent starts the same way: a 4,000-token policy document, a tool catalog, a style guide — none of it changes from request to request. And every call, you pay full price to process it again, before the model has even seen what the user actually asked. Multiply that by a few thousand calls a day and the “unchanging” part of your prompt is quietly the most expensive part of your bill. There is a mechanism built specifically for this, and it is one of the more testable, concrete ideas in Domain 5 of the Claude Certified Architect exam.

The one-sentence version: If a block of your prompt is byte-for-byte identical across calls, mark it as a stable prefix with cache_control and let the model read it from cache instead of reprocessing it every time.

The question

You re-send a large, unchanging policy block on every call, and it’s costing you. What’s the fix?

• A) Shorten the policy
• B) Prompt caching (cache_control) on the stable prefix
• C) A bigger model
• D) Send it once and hope it’s remembered

Pause here and pick an answer before you scroll — this is a Domain 5 (Context Management & Reliability, 15% of the exam) question, and the value is in reasoning through the mechanism, not in seeing the letter.

The answer

B — Prompt caching (cache_control) on the stable prefix.

The policy block isn’t the problem. Re-processing it from scratch on every single call is. Prompt caching lets you mark the leading, unchanging portion of your prompt — system instructions, a policy document, a tool catalog, a large reference doc — so the model can skip reprocessing it on subsequent calls and instead read it from a cache. The first call still pays to build the cache; every call after that, as long as the prefix is unchanged, pays a fraction of the cost to read it.

CALL 1 — cache miss (cold)                CALL 2 — cache hit (same prefix)
┌────────────────────────────┐            ┌────────────────────────────┐
│ SYSTEM PROMPT               │            │ SYSTEM PROMPT               │
│ + POLICY BLOCK (stable)     │            │ + POLICY BLOCK (stable)     │
│   cache_control: ephemeral  │            │   cache_control: ephemeral  │
│   → [cache_creation]        │            │   → [cache_read]  HIT       │
├────────────────────────────┤            ├────────────────────────────┤
│ USER MESSAGE (fresh, tail)  │            │ USER MESSAGE (fresh, tail)  │
└────────────────────────────┘            └────────────────────────────┘
  full processing + write cost              stable prefix skipped,
                                             only the tail is reprocessed

The mechanism has two halves, and the exam likes to test whether you can name both:

1. Cache write (cache_creation). The first time a prefix is sent with a cache_control breakpoint, the model processes it normally and writes it into a short-lived cache. This costs a small premium over the base rate — you’re paying to set the cache up.
2. Cache read (cache_read). Every subsequent call that sends the exact same prefix, token for token, hits the cache instead of reprocessing it. This is dramatically cheaper than a fresh pass, and it’s also faster — you skip the compute, not just the cost.

Only the invariant part of the prompt goes behind the cache breakpoint. The tail — the part that actually changes call to call, like the user’s message or the latest tool result — stays uncached and fresh every time. That split is the whole idea: cache what never changes, keep what does change outside the cache.

Why the other options fail

• A) Shorten the policy. This treats the symptom, not the mechanism. A shorter policy is still reprocessed in full on every call — you’ve reduced the cost per call by some percentage, but you haven’t changed the fact that you’re paying full price for static content over and over. It’s a band-aid that also risks cutting content you actually need.
• C) A bigger model. A larger model doesn’t make redundant reprocessing free — it usually makes it more expensive, since bigger models generally cost more per token. This option confuses “the answer is wrong” with “we need more horsepower,” which is a distractor pattern worth recognizing: bigger/stronger models never fix a cost or architecture problem caused by resending the same tokens.
• D) Send it once and hope it’s remembered. This misunderstands how stateless API calls work. Unless you’re using a stateful session mechanism, the model has no memory between independent API calls — each call is a fresh context window. “Hope it’s remembered” isn’t a caching strategy, it’s a bug: the next call simply won’t have the policy at all, and behavior will silently degrade.

The concept behind it

Prompt caching is a narrow feature with a general lesson: treat your context window as a cost budget, and treat different parts of that budget differently based on how often they change.

Split any prompt into two categories:

Two structural rules make this work in practice, and both show up as their own exam-style questions elsewhere in this series:

• Order matters. The cacheable content has to come first, as a stable prefix. If you interleave stable and volatile content, or put the changing part before the static part, the cache can’t match — even one token out of order breaks the match for everything after it.
• There’s a minimum size. Caching isn’t free to set up, so providers enforce a floor below which a prefix won’t be cached at all — a short system prompt won’t get cached even if you mark it. That’s a distinct failure mode from what’s covered here (this question assumes the block is genuinely large), and it’s exactly the trap in Why Is Your Cache Never Hitting? Prompt Cache Prefix Rules — read that one if cache_read is showing zero even after you added cache_control.

The economic case is straightforward: at scale, an agent making thousands of calls a day with a large fixed system prompt is paying to re-derive the same intermediate representation of that prompt, over and over, for no benefit. Caching converts that repeated cost into a one-time setup cost plus a much cheaper read on every subsequent call. It’s also a latency win, not just a cost one — skipping reprocessing means a faster time-to-first-token, which matters for anything user-facing.

The pattern generalizes past “policy blocks.” Anything long and static is a caching candidate: a large tool catalog for an agent with 30+ tools, a set of few-shot examples that never change, a knowledge base excerpt pinned into every call of a RAG pipeline, or a long multi-turn conversation history in an agent loop where only the newest turn is actually new. In every case the question is the same: what part of this prompt is identical to what I sent last time, and can I mark it so the model doesn’t have to see it again?

FAQ

Does prompt caching change the model’s output? No. Caching is a cost and latency optimization at the infrastructure layer — it changes what the provider bills you and how fast the response starts, not what tokens the model attends to or what it generates. A cached prefix is processed identically to an uncached one from the model’s point of view.

How is prompt caching different from just shortening the prompt? Shortening reduces the size of what you send; caching reduces the cost of sending something you’ve already sent before. They’re not competing fixes — you should still avoid bloating a cached block unnecessarily, but the caching mechanism is what actually eliminates the repeated cost of an unavoidably large, unchanging prefix.

What happens if I change even one word in the cached block? The prefix no longer matches byte-for-byte, so the cache misses — the model reprocesses that prefix from scratch and writes a new cache entry. This is why volatile content has to live strictly after the cache breakpoint: putting a timestamp or a per-call ID inside the “stable” block silently defeats the entire strategy.

Is a cached prefix cached forever? No — cache entries are short-lived (commonly on the order of minutes), which is why high-traffic, repeated-prefix workloads benefit the most: the cache stays warm because calls keep arriving before it expires. A prefix you send once a day won’t see much benefit from caching.

Not affiliated with, authorized, or endorsed by Anthropic. “Claude” and “Claude Certified Architect” are trademarks of Anthropic. These are original practice questions for study, not real exam content — verify current exam details on Anthropic’s official pages.

Where this fits in the CCA series

This question sits in Domain 5 — Context Management & Reliability (15% of the exam) — alongside the other context-budget questions in this set: It Forgot Your First Instruction: Lost-in-the-Middle and Context Rot, The Task Overflowed the Window: Chunking and Decomposition, and the natural next step once caching is in place, Why Is Your Cache Never Hitting? Prompt Cache Prefix Rules. If you haven’t seen how the five domains fit together, start with the Claude Certified Architect (CCA) Exam Guide, and if the broader context-vs-retrieval question is unclear, see RAG vs Context Engineering. Browse all tutorials for the rest of the series.