Prompt caching cuts cost and latency by reusing the cached prefix of your prompt. Roll it out onto an existing app in this order.
1. Measure the repeatable prefix first. Find the part of your requests that is identical across calls: system instructions, few-shot examples, retrieved documents. If nothing repeats, caching buys you nothing, stop here.
2. Choose automatic or explicit. Automatic caching: add a single cache_control field at the top level of the request and the system caches the last cacheable block, moving the breakpoint forward as the conversation grows. Best for multi-turn chats with growing history. Explicit breakpoints: place cache_control directly on individual content blocks for fine-grained control. Start with automatic; switch to explicit only if you need to cache a middle section and not the tail.
3. Reorder so stable content comes first. Put the unchanging blocks (system instructions, tool definitions, documents) at the front of the request and the variable content (the latest user message) last. Any change to an early block invalidates everything after it, so one dynamic block placed first kills the whole cache.
4. Pick the TTL that matches your rhythm. cache_control supports a 5-minute or 1-hour TTL. Multi-turn chats inside an hour-long session want the 1-hour TTL; bursty background jobs want 5 minutes. Check the minimum cacheable length in the docs: short prefixes below it will not cache at all.
5. Verify with cache usage fields. On the response, read the usage object: cache_creation_input_tokens and cache_read_input_tokens tell you whether the cache actually hit. If read tokens stay zero, your prefix is not stable, go back to step 3 and diff two requests byte by byte.
6. Roll out per endpoint, not all at once. Enable caching on one call site, confirm the hit rate, then move to the next. Cache behavior interacts with temperature and tool definitions, so re-run your evals after enabling it.