Run the writeup's own example all the way to the end. A 10,000-token prefix, written once at 1.25x, costs 12,500 token-equivalents. The 999 matching reads at 0.1x cost 999,000. Total 1,011,500 against a no-cache baseline of 10,000,000 [7][8]. That is 89.9 percent off the prefix, not 70 to 80 [8]. The published band is discounting something the article does not name, and the obvious candidate is the miss rate.
So solve for it. If a hit costs 0.1 and a miss costs 1.25 because the miss also writes, expected per-call cost is 1.25 - 1.15h, which puts a 70 percent saving at a hit rate near 0.83 and an 80 percent saving near 0.91 [10]. That is a quantity you can measure rather than assume. The sample code prints usage.cache_read_input_tokens beside usage.input_tokens, which is the ratio to put on a dashboard before you promise finance a percentage [19].
The write premium itself is close to a rounding error. Caching beats not caching once 1.25 + 0.1(n-1) < n, which resolves at n above roughly 1.28 requests [9]. Two calls on the same prefix inside one cache lifetime and you are ahead. What the article never gives you is that lifetime. The only durability signal anywhere in it is the cache_control type "ephemeral" [20]. Break-even in requests is easy; break-even in requests per TTL is not derivable from this text.
The real adoption cost sits in the exact-match rule. One changed character in the cached portion invalidates the prefix, which forces stable content to the top and dynamic content to the bottom [5][6]. The kill-list opens with injecting a timestamp into the system prompt, which remains the cheapest known way to convert a cache into a bill [11]. The prescribed fix is to refactor a dynamically constructed system prompt into a fixed static string and pass per-user data as a user turn [12]. That is real work on prompt assembly, and it sits badly beside the claim that this "requires almost no refactoring" [13]. Attaching a marker to a history turn also means rewriting plain string content into a list of text blocks, so message plumbing changes too [17].
The multi-turn pattern deserves a closer read. Two markers: one on the system prompt, one at a fixed depth into history, default 10 [14]. The code places it at index history_len - history_cache_depth, and only when history is at least that long [15]. Because the marker is defined relative to the end of the list, its absolute index advances by one with every appended turn [16]. The article describes the marker as telling the provider to compute and store KV state up to that point, and says the next request reuses that state if its prefix matches exactly [21]. It does not say whether a longer request still hits the shorter prefix stored last turn. That behaviour is the whole question for the second marker, and you will have to test it against your provider.
One more transfer condition. The 70 to 80 percent figure is quoted on the prefix, not on the bill [7]. Total saving scales with the prefix's share of priced tokens, so a workload where the cacheable prefix is half the priced tokens sees about 45 percent, not 75 [22]. The article says both major providers expose this, one through a cache_control block in the request body and the other through cache_read_input_tokens in billing data, and that the mechanics differ slightly [18]. Slightly is doing some load-bearing work in that sentence.
