Skip to main content
RJL.pub logo

RJL.pub - AI-Native Development Journey

Chapter 13: Prompt Caching Strategies

How Prompt Caching Works

Prompt caching lets providers reuse processed context across requests, cutting latency and cost dramatically for repeated context. For agentic workloads - which reuse large, stable context (CLAUDE.md, architecture docs, system prompts) across many turns - caching is one of the highest-leverage cost controls available.

Anthropic Claude Caching:

// Cache lifetimes: ~5 minutes (default) or ~1 hour (extended)
// Minimum cacheable content: ~1024 tokens
// Cache reads cost a fraction of base input tokens

{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "You are an expert TypeScript developer...",
      "cache_control": { "type": "ephemeral" }   // cached
    }
  ],
  "messages": [
    { "role": "user", "content": "Implement user authentication" }  // changes
  ]
}

Layer Your Context for Cache Hits

Layer 1 (Always cached - rarely changes):
- Project CLAUDE.md / AGENTS.md
- Architecture documentation
- Coding standards and system prompt

Layer 2 (Cached per session - changes occasionally):
- Current file contents
- Related dependencies and test files

Layer 3 (Never cached - always changes):
- Specific task instructions and intent
- User queries and temporary context
Three stacked layers ordered by how often they change: always cached, cached per session, and never cached.
Stable context at the bottom, volatile context on top: layer your prompt so the expensive part stays cached.

Cost Optimization

Scenario: 100 agent turns reusing 50K tokens of stable context

Without caching:
- Input: 100 x 50,000 = 5,000,000 tokens at full input price

With caching (95% cache hit, reads at ~10% of input price):
- Cached reads: 95 x 50,000 at ~10% price
- Fresh writes: 5 x 50,000 at full price
- Net input cost reduced roughly 80-90%

The Cache-Read Multiplier Is Not a Constant

One number in that arithmetic deserves its own attention, because it stopped being uniform across a vendor's own lineup. Cache reads have conventionally billed at roughly a tenth of the base input price, which is the assumption baked into most cost models - including the one above. Anthropic's top tier now reads cached tokens at 0.025 times base input, a quarter of the usual rate, while the rest of the line stays at the traditional tenth.

That sounds like a footnote and is not. It means the tier you would have ruled out on sticker price can be the cheaper option for exactly the workload agents generate: a long run that reuses a large, stable prefix across many turns, where cache reads dominate the bill and fresh input barely moves it. The headline per-token price is half the equation; the multiplier applied to the 95% of your tokens that are cache hits is the other half. When a vendor changes either one, re-run the arithmetic against your own context shape rather than carrying forward a rule of thumb - the ranking of "cheapest model for this job" can invert without a single headline price changing.

Caching is largely automatic in Claude Code and other agent tools when you reuse the same context. The architectural move is to keep your stable context stable - so it stays warm in the cache - and isolate the volatile, per-task intent into its own layer.