Prompt Caching and Free Cost Wins on Claude

1.Two kinds of cost lever

Once a workload moves from prototype to production, cost becomes a design constraint. The most capable model can be too expensive at scale, and the cheapest one may not be good enough. Anthropic's guidance on cost and intelligence starts by sorting every lever into one of two groups. Free wins lower what you pay and leave quality alone: prompt caching, token hygiene, auditing your prompt against the model you actually run, batch processing for work that can wait, and workspace spend limits as a backstop. Trade-offs give up some intelligence for lower cost: model choice, effort, output caps and task budgets, an elapsed-time clock, and multi-model architectures.

The order matters. Free wins move a workload toward the cost-to-intelligence frontier, and trade-offs only move it along that frontier. So apply every free win before you accept any quality loss.

The guidance is clear that its numbers are Anthropic-internal and directional. Use them to decide what to try first, then measure each lever on your own workload.

Sources1

2.Why caching dominates agent-loop cost

Each turn of an agentic task sends the whole conversation again: the system prompt, the tool definitions and every earlier turn. A 40-turn task sends its first turn 40 times, so the cost of a task grows roughly with the square of its turn count. Caching does not stop that resending. It makes each resend about a tenth as expensive and faster to process. The cached prefix is billed at the cache-read rate, and each turn pays the cache-write rate only for its new content.

The simplest way to turn it on is automatic caching, a single top-level cache_control field. The system puts the breakpoint on the last cacheable block and moves it forward as the conversation grows, so you never move markers by hand. If you need precise control, you can place explicit breakpoints on individual content blocks instead.

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},
    system="You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.",
    messages=[
        {
            "role": "user",
            "content": "Analyze the major themes in 'Pride and Prejudice'.",
        }
    ],
)
print(response.usage.model_dump_json())

Every model charges 1.25x the input price for a 5-minute write and 2x for a 1-hour write. Read prices vary: most models charge 0.1x, Opus 5.5 charges 0.05x, and Fable 5.1 and Mythos 5.1 charge 0.025x.

The cache lasts 5 minutes by default, and each use refreshes it at no extra cost. That lifetime starts when the request begins, not when its response ends. If a response takes 4 minutes to stream, the next request has to start within about a minute.

To check whether caching is working, measure your hit rate. Over a day of real traffic, agent loops read a median 84% of their input from the cache, and the top 10% of loops read 94% or more. If your rate is below about 80%, look for something that is breaking the cache.

Sources1

3.Choosing the cache duration from the pauses

The 5-minute default works for an agent loop whose turns arrive seconds apart. Things change when a person replies between turns. If a pause outlasts the cache, the next request misses, and a miss on either duration bills the whole prefix at the write price. The 1-hour duration avoids that miss, but every write costs 2x the input price instead of 1.25x.

To decide, count the gaps between consecutive requests in a conversation:

- Turns arrive seconds apart: keep the 5-minute default. When nothing paused, it cost about 15% less than the 1-hour setting. - More than about 1 gap in 20 falls between 5 minutes and an hour, and longer gaps are rare: use the 1-hour duration. - Gaps over an hour are common: keep the default. A gap that long expires both durations, and the 1-hour setting then pays its higher write price again.

{ "cache_control": { "type": "ephemeral", "ttl": " ? " } }

Two models break the rule because their cache reads are so cheap. Instead of buying the 1-hour duration, you can keep the 5-minute cache warm. Re-send the previous request with max_tokens set to 0 within 4 minutes of that request's start, then every 4 minutes after. The request generates nothing and is billed only as a cache read. Change nothing in the prefix, and send the same headers, including any anthropic-beta header. A max_tokens: 0 request is rejected if it uses thinking.type: "enabled", structured outputs or a forced tool choice. For those workloads, buy the 1-hour duration instead.

- Claude Fable 5.1: keeping the cache warm cost 13% to 20% less per session than the 1-hour cache whenever pauses lasted minutes. Buy the 1-hour duration only when pauses run toward an hour. - Claude Opus 5.5: keep the cache warm when only a turn or two in 20 follow a pause of up to about half an hour. Otherwise follow the general rule above.

Sources1

4.Batching and token hygiene

The Message Batches API charges 50% of standard prices for both input and output. In exchange, you give up immediate responses. Requests run asynchronously, and most batches finish in under an hour. Results become available once every request has completed or after 24 hours, whichever comes first, and batches that don't finish within 24 hours expire. A batch holds up to 100,000 requests or 256 MB. It cannot use stream: true, Fast mode (speed) or max_tokens: 0, so you can't pre-warm a cache from inside a batch. The docs suggest batching for large-scale evaluations, content moderation, data analysis and bulk content generation.

Token hygiene means not sending or generating tokens you don't need. Caching alone cut a small triage agent's bill by 83%. Trimming its input as well raised the saving to 88%. Not every hygiene technique paid off, though: in the run Anthropic measured, context editing cost more than it saved. Measure a hygiene change before you assume it helps. Workspace spend limits are the backstop, but batches can go slightly over a configured limit because they process many requests at once.

Sources21

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.The 5-minute cache lifetime counts from when the previous response finished.Why is that wrong?

   It counts from the start of the request that wrote or read the entry. Time spent generating a long response uses up part of the lifetime.

   Covered in Why caching dominates agent-loop cost

2. 2.If users ever pause for more than 5 minutes, the 1-hour cache is always the cheaper choice.Why is that wrong?

   When gaps over an hour are common, both durations expire and the 1-hour setting pays its higher write price again. On Fable 5.1, keeping the 5-minute cache warm beats it for pauses that last minutes.

   Covered in Choosing the cache duration from the pauses

3. 3.Batch processing is a pure free win with no downside.Why is that wrong?

   Quality stays the same, but you give up latency to get the discount. Results can take up to 24 hours, so batching does not suit interactive work.

   Covered in Batching and token hygiene