A cache key is the bytes of your prompt up to a breakpoint. Not a summary, not a semantic fingerprint — the bytes. So this page builds the mechanism instead of describing it: a byte-prefix matcher over an ordered block list, a TTL clock, the published price schedule and the four published minimum-prefix tiers, run forward over deterministic traces. Nothing is sampled, which is why a rate of 0.00% here means zero rather than "none seen".
bill = read * 0.10 + written * m + uncached * 1.00; // m = 1.25 (5m) or 2.00 (1h)
Three declared constants, and every hit rate and ratio downstream of them is arithmetic: https://dev48.infy.uk/prompt/day71-prompt-caching.html
The centrepiece has no parameters in it at all
Take one 14-token Current date: … line — 0.22% of a 6,324-token prompt — and move it through the eight slots of that prompt. Same prompt, same breakpoint, same trace. The bill takes two values, not eight: slots 0–5 are bit-identical at 1.245× on a 0.00% hit rate, slots 6–7 are bit-identical at 0.157×. Swap the 14-token line for a 400-token one and you get the same two-valued step at the same slot, because what you lose is never the changed thing — it is everything behind it.
Note the direction of the first number. 1.245 is above 1.000, so caching a badly-ordered prompt costs more than not caching it.
The claim I built the page to make died
Four breakpoints spread through the prompt "to be safe" do not tie two well-placed ones. They lose to one:
| scheme, shared-prefix workload | hit rate | bill vs no caching |
|---|---|---|
| no caching | 0.00% | 1.000× |
| top-level auto | 0.00% | 1.250× |
| one breakpoint, well placed | 94.83% | 0.155× |
| two | 94.83% | 0.160× |
| four, spread "to be safe" | 77.67% | 0.357× |
A breakpoint short of the shared-prefix end caches less of the prefix and rewrites the remainder at the write multiplier on every single call. Spreading them is not insurance, it is a fee.
The real null result is next door. On the other workload — one conversation, growing — 1, 2 and 4 breakpoints all bill exactly 0.194×. The dial you agonise over does nothing there, and the dial that decides everything on the first workload is the ordering, which is a text edit and costs zero tokens.
What the measurement contradicted
Top-level automatic caching is the one-line version of the feature, and it is simultaneously the worst and the best thing on the page. Point it at a large shared preamble with a different question stapled to the end — every classifier, every extraction job, every fan-out — and the breakpoint lands after the question, the key is unique on every call, and it bills 1.250× at a 0.00% hit rate: you pay the surcharge and the benefit both. Point the identical line of code at a growing conversation and it is the cheapest scheme measured, at 0.194×.
Nothing in the call tells you which one you have. The request succeeds either way, and the only symptom is a field in usage nobody reads.
Two silent zeros are worth separating. Below the minimum prefix nothing is cached, so the bill is exactly 1.000× — a no-op. Past the TTL the entry is written every call and read on none, so the bill is 1.245× forever. cache_read_input_tokens === 0 in both.
Part of a from-scratch series — one prompting technique a day, measured rather than described. One file, inline CSS, no external asset: https://dev48.infy.uk/promptfromzero.php
