A cacheable prompt, uncached
Reading a cached prefix costs a fraction of sending it again. This prompt qualifies.
Prompt caching is the largest single lever in LLM cost control, and it is a configuration change rather than a rewrite. On most current models a cache read is billed at a tenth of the base input rate or less; a few older models charge a quarter or a half.
The arithmetic is worth internalising. With a typical write at 1.25x the base rate for a short time-to-live and reads at 0.1x, one write plus one read costs 1.35x against 2x for sending it twice — caching pays for itself on the second request. Cheaper reads only bring that forward. With a longer time-to-live the write costs 2x and you need two reads to break even.
That means the only workloads caching hurts are ones where the prefix is genuinely used once and thrown away. Everything else — any repeated system prompt, any multi-turn conversation, any agent loop — should be caching.
The prerequisites are a prefix above the provider minimum (about a thousand tokens) that is byte-identical between requests. If yours is not identical, that is usually the ordering problem rather than a caching problem.
6,000-token system prompt sent at full price on all 40,000 daily requests.Same prompt behind a cache breakpoint: writes on misses, reads at a fraction of the price on hits.Check your own prompt
The analyser checks this pattern along with the other 25, prices each finding against your request volume, and hands back a rewritten prompt. It runs in your browser — nothing is uploaded.
Run the analyserMore on caching
- Per-request values above your static contentA cache prefix ends at the first byte that changes. Anything after it pays full price forever.
- A one-hour cache for a five-minute workloadLonger cache lifetimes cost more to write. They only pay back if you actually reuse them.