One query in this harness costs $0.00144 at the rates the author assumes: 800 input tokens at $0.80 per million, 200 output tokens at $4.00 per million [7][8][1]. Output is 55.6% of that total [2]. Prompt caching does not reduce output token cost at all. It discounts the repeated prefix only, which here is the 400-token system prompt [8].
Run the multipliers and prompt caching stops being a decision. A read on the marked prefix bills at 0.1x the input rate, a saving of $0.000288, or 20% of the query [1][3]. A write bills at 1.25x, a premium of $0.00008 on that prefix [1][d4a]. Premium divided by saving is 0.28, so the first read inside the window pays for the write and then some [5]. The whole intervention is one field: `cache_control` set to `ephemeral` on the system block, with `cache_read_input_tokens` and `cache_creation_input_tokens` returned in `usage` so you can price it yourself [10].
That leaves the expiry window as the only real variable, and it is a traffic-shape question rather than a token question [13]. What you want before switching it on is the distribution of gaps between requests that share a prefix.
Semantic caching is a different bargain because the call disappears. A hit returns the stored answer and the entire $0.00144 goes with it, output included, which is five times what a prompt-cache read recovers on the same query [4][6]. The price of that leverage is a single float. The harness pins cosine similarity at 0.92 and treats it as the parameter to sweep [9], because that number is what adjudicates the paraphrase and typo-variant buckets: at one setting they are hits, at another they are wrong answers that register as hits [6].
The table that matters most is missing from the supplied text, which breaks off inside the definition of the evaluation function that would score cached answers against ground truth [17]. What is present is the harness and the cost model, and the author's stated requirement is that both run locally on an API key with no customer secrets [15]. The embedding side is a local all-MiniLM-L6-v2 model, so a lookup costs CPU rather than tokens [16]. It also costs a scan: the published code walks every `qa:*` key in Redis and computes the cosine in Python for each stored item [c11a]. At a few hundred keys that is invisible. Semantic-cache latency therefore grows with cache size, which runs opposite to prompt caching, where the provider-side hit is reported to improve latency as well as cost [c3b].
For a measured break-even to transfer to your traffic, three things have to hold. Your repeat share has to resemble that synthetic mix rather than being mostly novel questions [6]. Your stored answers have to stay correct for as long as they sit in Redis, because the lookup compares query vectors and never re-checks the answer it is about to serve [c11a]. And someone has to own the false-positive rate at whatever threshold you ship, which means owning it as a product decision, not a cache configuration [4].
