Claude Prompt Caching
Prompt caching can reduce repeated processing of a long, unchanged prefix. It is most useful when many requests share the same instructions, tool definitions or reference documents.
#Keep the reusable prefix stable
Put stable material before the changing user question. A cache breakpoint marks reusable content; it does not make arbitrary semantically similar prompts equivalent.
This is an illustrative system-field fragment, not a complete request:
json[{"type": "text", "text": "LONG_STABLE_REFERENCE_DOCUMENT", "cache_control": {"type": "ephemeral"}}]
A short placeholder will not necessarily meet the minimum cacheable length. Consult the current model-specific minimum, supported TTL and breakpoint limits instead of copying a historic token threshold.
#Measure hits and costs
Inspect usage fields such as cache creation and cache read input tokens. Compare an initial write, a repeated identical prefix and a changed prefix. Record time to first output and total usage. Cache writes and reads can have different prices; a cache hit is not automatically a free request.
Caching is less useful for one-off short prompts or when timestamps, random identifiers or changing tool definitions invalidate the prefix. Organize content deliberately instead of caching every message.
#Operational considerations
Keep tenant boundaries, data-retention requirements and access policy intact. A cached reference must not become a way to reuse another user's private material. Version the document so a changed policy does not silently reuse stale application content.
For an application benchmark, use non-sensitive fixed test documents and report actual hit fields. Do not claim a speedup from a single latency observation.
