Every time you send a message to Claude, the model processes your entire input from scratch, token by token. That is fast for short prompts, but expensive and slow when you repeat the same large context (a system prompt, a long document, a big codebase) across many calls. Prompt caching solves this by storing the processed representation of repeated content so it does not have to be recomputed.

The underlying mechanism is the KV cache (key-value cache). During inference (the act of generating a response), the model builds a table of intermediate values for every input token. Normally that table is thrown away after each call. With prompt caching enabled, Anthropic keeps the table alive on its servers for a short window, so the next call that sends the same prefix can skip the recomputation entirely.

Key facts about how the cache behaves:

The cache window is 5 minutes. If your next API call arrives within 5 minutes and starts with the same prefix, you pay the lower cache-read price (roughly 10 percent of the normal input price for Opus claude-opus-4-8 and Sonnet claude-sonnet-4-6).
The first call that fills the cache pays the normal input price plus a small cache-write surcharge (about 25 percent extra), because the server has to store the result.
The cached prefix must be identical down to the byte. Even one changed character invalidates the cache for that position and everything after it.
You mark cacheable blocks explicitly in the API using a cache_control field with "type": "ephemeral". Claude Code and the Claude SDKs handle this automatically for system prompts when you use the --cache flag or the SDK default.

The practical effect: latency drops because the model skips processing thousands of tokens, and cost drops because cached tokens are billed at the read rate. For a workflow that sends the same 20,000-token document to Claude 50 times in a session, caching can cut the input cost by over 80 percent.