Prompt caching strategy for architects

What you’ll be able to do

• Decide which layers of a multi-agent system should cache and which shouldn’t
• Choose between the 5-minute and 1-hour TTL based on traffic pattern
• Design pruning so it doesn’t quietly invalidate a cache the system depends on
• Verify caching is engaged across a system, not just at one call site

What you need to know

Caching one call is placement; caching a system is strategy

At the level of a single request, prompt caching is a placement problem: stable content first, a checkpoint, volatile content last. At the level of a system with several agents calling Claude — a manager, two or three subagents, maybe a shared tool-execution layer — it becomes a strategy problem, because each agent has its own stable prefix, its own call frequency, and its own tolerance for the write premium.

The manager agent in an orchestration pattern is usually called on every user turn — high frequency, strong case for caching its system prompt and tool definitions. A subagent invoked once per session for a narrow task may never call often enough within a TTL window to make the 1.25× write premium worth paying. Applying one caching decision to both is treating them as the same problem when they aren't.

TTL is a traffic-pattern decision, not a default

The 5-minute default TTL suits a single high-frequency endpoint where calls are seconds apart — reads keep resetting the TTL, so the write premium is paid once at warm-up and rarely again. The 1-hour TTL suits exactly the multi-agent picture above: several agents sharing one stable prefix, called at less predictable intervals, where a 5-minute window would expire between calls and force a fresh 1.25× write on nearly every one.

Picking the 1-hour TTL by default "to be safe" isn't free either — it costs 2.0× on the write instead of 1.25×. The right choice is read from the actual call-interval distribution for that layer, not assumed.

Pruning and caching can fight each other

A pruning strategy that rewrites or reorders history to save context budget can silently invalidate a cache if it touches anything before the checkpoint. This is a genuinely easy mistake in a system where caching and context management were designed by different people, or at different times: the pruning step doesn't know a checkpoint exists, and the caching setup doesn't know pruning runs.

The fix is architectural, not a code review checklist: pruning logic should only ever touch content after the cache checkpoint. If the checkpoint sits after the stable system prompt and tools, and pruning only ever compresses conversation history that comes after it, the two can't collide by construction.

Key concept

Caching a single call is placement. Caching a system is strategy: which layers cache, which TTL matches their traffic, and a pruning boundary that never crosses the checkpoint.

When a scenario describes caching that "used to work" and stopped, or that helps one part of a system but not another, look for a second process — usually pruning or summarization — touching content before the checkpoint, or a TTL mismatched to that layer's actual call frequency.

Practice scenario

Build exercise — Design a caching strategy across a multi-agent system

Advanced · 30 min

What you’ll learn

• Assigning a caching decision per agent layer instead of system-wide
• Matching TTL choice to actual call-interval data
• Verifying a checkpoint survives a pruning or summarization pass

1. For each agent in a multi-agent design, estimate its call frequency and decide whether caching its stable prefix is worth the write premium.

   • Why: A rarely-called subagent may never earn back the 1.25× or 2.0× write cost within a TTL window.
   • You should see: Not every agent in the system should necessarily cache — that’s a legitimate outcome, not an oversight.

2. For each layer that does cache, pick 5-minute or 1-hour TTL based on the actual gap between calls, not a system-wide default.

   • Why: A TTL shorter than the typical call gap forces a fresh write on nearly every call; a TTL longer than needed costs more per write than necessary.
   • You should see: Different layers in the same system legitimately landing on different TTLs.

3. Trace where pruning or summarization logic runs relative to each layer’s cache checkpoint, and confirm it never rewrites content before the checkpoint.

   • Why: This collision is silent — no error, just a cache that mysteriously stops engaging.
   • You should see: Either confirmation the boundary holds, or a pruning step you just found that reaches earlier than it should.

Exam traps

Applying one caching decision uniformly across every agent in a system

Different agents have different call frequencies; a decision right for the manager can be wrong for a rarely-called subagent.

Defaulting to the longer TTL everywhere without checking the cost tradeoff

The 1-hour TTL costs 2.0× on write versus 1.25×. It’s the right choice for some layers, not a safe default for all of them.

Letting a pruning step rewrite content that sits before the cache checkpoint

Invalidates the cache silently, with no error — the classic failure mode, now at system scale instead of one call.

Assuming a shared prefix across agents will get cached without a shared checkpoint

Each call site needs its own correctly placed cache_control checkpoint; a shared prefix in the prompt text doesn’t cache itself.

Treating cache verification as a one-time check instead of ongoing monitoring

A traffic-pattern shift (like the overnight example) can silently change hit rate after the initial check passed.

Optimizing cache hit rate for a low-traffic path while ignoring the high-traffic one

The write premium and read discount both scale with call volume — the high-frequency layer is where the strategy matters most.

Sources

• Claude Developer Platform Docs