Original AI-assisted concept illustration for SPKE. The branches represent reuse and expiry, not measured performance.
Start with the workload
An application asks ten questions about the same document. Its developer sees a low cached-input price and expects a similarly large reduction in the bill. That expectation skips the important questions: was the reusable prefix actually written, did each request match it, and did reuse happen before expiry?
Our conclusion is to compare the cost of an accepted task under realistic request timing, not the largest advertised cache discount. This is an analysis of official documentation checked on October 22, 2026, with an explicitly hypothetical calculation. SPKE did not run a provider benchmark. These are undated, continuously updated documentation pages; the check date is not an announcement or effective date.
A useful China–US comparison
The US providers OpenAI and Anthropic and the Chinese provider DeepSeek offer different controls. Their country of origin does not predict the right configuration for an application. Compare the exact model, API, lifetime and workload.
OpenAI’s current guide separates GPT-5.6 and later from earlier models: newer models have premium cache-write rates and eligible lookup boundaries. The old blanket assumption that OpenAI cache writes carry no extra charge is unsafe. OpenAI guide
Anthropic lists different write rates for five-minute and one-hour cache lifetimes, while read rates vary by model. A single provider-wide discount is therefore insufficient for budgeting. Anthropic pricing
DeepSeek’s example shows A+B followed by A+C missing before a persisted shared A can serve A+D. Repeated text alone is insufficient. DeepSeek caching
These differences suggest a procurement question more useful than “which country has cheaper AI?”: which implementation reuses our actual requests reliably, at the quality we need? This is an engineering comparison, not a national capability ranking.
A discount is not a bill reduction
Here is our simplified calculation, not a price quote. Consider only one identical eligible prefix. Let n be the total number of requests, including the first write; w the write-price multiplier; and r the read-price multiplier relative to ordinary input. Assume one write and n−1 successful full reads, with no expiry or rewriting.
Uncached cost, in normalized units: n. Cached cost: w + (n−1) × r. For 0 ≤ r < 1, caching is cheaper when n > (w−r)/(1−r).
With hypothetical w = 1.25 and r = 0.1, ten requests cost 2.15 units rather than 10. The prefix saving is 78.5%, although each read is 90% cheaper. With w = 2 and r = 0.1, at least three total requests are needed to save; with w = 1.25, two suffice.
This is an ideal prefix-only threshold. Dynamic input, generated output, tools, retries and repeated writes can change the task-level result. A configuration that reduces the prefix bill but requires extra repair work may lose overall. Replace the hypothetical multipliers with the exact model’s current rates before making a budget.
Three shapes of reuse
First, a serial conversation appends to retained history. Second, independent questions branch from a shared document. Third, a cold parallel batch launches before any reusable cache is ready. Equal repeated-token volume does not make these equivalent workloads.
For Anthropic, cache availability begins after the first response starts, and the five-minute window starts at request initiation. Launch timing and long answers therefore matter. Anthropic caching
Our design recommendation is to separate stable reference material from changing questions, keep boundaries consistent, and test the actual request sequence. Do not insert timestamps or request IDs ahead of stable content without checking the effect. Do not blindly add warm-up calls: they consume resources, and users may never make the later request.
An acceptance plan before rollout
Use the same quality-qualified task set for four conditions: cold start, warmed reuse, realistic pauses, and concurrent traffic. This is a proposed test plan, not an experiment we performed.
- Record model/version, API, request structure, cache settings and service tier. Keep the content and quality criteria comparable.
- Normalize the provider’s usage fields into ordinary input, cache writes and cache reads. Check what each field includes before summing; avoid double counting. For a provider exposing only hit/miss input, do not invent a separate write charge.
- Count total cost per accepted task, including failed attempts, output and tools. Also report rejected tasks, so cheaper failures cannot improve the headline.
- Measure first-token and end-to-end latency, including the slow tail such as p95. Report cold and warm results separately.
- Change one factor at a time: prefix boundary, pause or concurrency. Preserve a baseline and document the reason for misses.
What to buy, and what not to infer
Select a configuration that meets quality and latency requirements at the lowest measured task cost. High hit rates alone are not a success criterion: an oversized repeated prompt can improve that rate while making every task unnecessarily expensive.
For teams comparing Chinese and US APIs, the transferable asset is a reproducible workload and a normalized cost ledger. Neither low cached-token pricing nor a cache hit proves better answers. This article establishes a decision method; it does not establish a winning provider.