Cache Prefix Analyser
Paste two prompts and find the exact character where they stop being identical — the boundary that decides a cache hit.
348 identical characters, ending at line 6, column 28 — that is 75.8% of prompt 1. Below the 1,024-token minimum you entered, so nothing would be cached.
- Prompt 1
- 452 chars · ~109 tokens
- Prompt 2
- 449 chars · ~108 tokens
- Identical prefix
- 348 chars · ~82 tokens
- Divergence at
- character 349 · line 6, column 28
- Prefix share of prompt 1
- 75.8%
- Prefix share of prompt 2
- 76.4%
- Identical suffix after the divergence
- 2 chars · ~1 tokens
- Saving per call on the prefix
- $0.00022
- At 200,000 calls/month
- $44.53 per month, if every call hits
usage object on an actual API response: that is what you are billed on, and it includes chat-template wrapping this model cannot see. The prefix is compared character by character, and a cache is matched on tokens — so the token figure above is an upper bound in two directions at once: a boundary can land mid-token, and most implementations only match at block boundaries rather than at an arbitrary token. The saving assumes every call after the first hits a live cache entry, which nothing guarantees: entries expire, and a request that arrives after the window has closed pays the full rate again and may pay a write premium on top. Treat the monthly figure as the ceiling on what caching could return here, not a forecast.The last 160 characters of the shared prefix
ems may be exchanged, not refunded. Damaged items are replaced at our cost whenever they are reported, if a photograph is attached. Session started 2026-08-03T
Prompt 1 diverges into
09:14:22Z·for·customer·41903.↵ Customer·question:·my·order·arrived·with·a·cracked·spine,·what·can·you·do?
Prompt 2 diverges into
11:52:07Z·for·customer·88214.↵ Customer·question:·can·I·still·return·something·I·bought·six·weeks·ago?
Spaces are shown as · and tabs as → in the two divergence panes, because the difference is a whitespace character more often than anyone expects.
The boundary that decides whether you get a cache hit
Prompt caching is a prefix match. The provider keeps the computed state of the first N tokens of your prompt and reuses it when the next request begins with exactly those tokens; the moment one character differs, everything from there on has to be computed again. So there is a single point in your prompt that decides how much of it is cacheable, and it is not a property of your prompt — it is a property of the pair of prompts. This tool finds it and tells you where it is.
The result is nearly always one of three shapes. A long prefix followed by a short variable tail is the good case and needs nothing done to it. A prefix of almost nothing means something is varying at the very top: a timestamp, a request id, a randomly ordered set of retrieved chunks, a JSON object serialised with unordered keys. And a short prefix together with a long shared suffix is the same problem diagnosed precisely — the stable material is below the variable line, so it can never be reused. Both fixes are the same move: everything that never changes goes first, everything that changes every call goes last.
A note on the arithmetic. The saving shown is the ceiling: full input rate minus your cached-read rate, across the whole prefix, on every call. Real hit rates are below 100% because entries expire between calls, and some providers charge a premium to write an entry, so a workload with low reuse can pay more with caching on than off. The break-even is roughly the write premium divided by the read discount, in hits. Check the effect against usage on a real response, where cached tokens are reported as their own line, before you conclude that it worked.