Prompt caching makes repeated requests faster and cheaper by reusing work the model has already done on a shared prefix.
How It Works
When you send a request, the provider hashes the start of your prompt and stores the model's intermediate state. If a later request begins with the same prefix, that state is reused instead of recomputed. You get the response back faster, and the cached portion is billed at a fraction of the normal input rate — savings are applied automatically when a cache hit occurs.
Caches are short-lived (typically a few minutes) and are keyed on an exact match of the prefix tokens. A single different character at the start of your prompt is enough to miss the cache entirely.
Maximising Cache Hits
To get the most out of caching, keep as much of the prefix identical across requests as possible.
- Put stable content first. System prompts, instructions, tool definitions, and reference material should appear at the start of the messages array. Put the variable parts (the user's latest question, dynamic context) at the end.
- Append, don't rewrite. In a multi-turn conversation, send the full prior history unchanged and append the new message. Editing earlier messages invalidates the cache from that point onwards.
- Stick to one model. Caches are per-model, so follow-up requests should use the same
modelas the original request. - Avoid per-request noise in the prefix. Don't inject timestamps, request IDs, or user IDs into the system prompt — they'll prevent any cache hit.
- Send follow-ups promptly. Caches expire after a few minutes of inactivity.
Viewing Your Savings
Cache hits reduce the credits consumed by a request automatically — there's nothing to enable. You can see your usage broken down by model on the Usage page, and read more here.