Prompt caching

If your requests share a large stable prefix — a long system prompt, a document, tool definitions, a conversation history — prompt caching stops you paying full price to reprocess it every time.

The multipliers, and when each pays off

Operation	Multiplier on base input	Valid for
5-minute cache write	1.25x	5 minutes
1-hour cache write	2x	1 hour
Cache read (hit)	0.1x	Same duration as the write

A hit costs 10% of standard input. The break-even follows directly:

• 5-minute cache: pays off after one read (1.25x write, then 0.1x instead of 1x).
• 1-hour cache: pays off after two reads.

For Opus 5 that is $5/MTok standard input against $0.50/MTok on a hit.

Two ways to enable it

Automatic — a single cache_control field at the top level of the request. The system manages breakpoints as the conversation grows. Start here.

Explicit breakpoints — cache_control on individual content blocks, for fine-grained control.

Where it matters most

Agentic workloads, by a wide margin. An agent re-sends its instructions, its tool definitions and its accumulated history on every turn. Tool definitions alone can be ~6,600 input tokens for a browser-use agent, on every request, before anything is called. Claude Code uses prompt caching for exactly this reason and documents how.

It stacks

Caching multipliers combine with the Batch API 50% discount and with the inference_geo data-residency multiplier. Batch plus a cache hit on Haiku 4.5 lands at $0.05 per million input tokens.

What it does not do

• It does not cache output. Input only.
• It does not persist indefinitely. Five minutes or one hour, refreshed by use.
• It does not help unstable prefixes. If the front of your prompt changes every request, there is nothing to hit.