DeepSeek Context Caching: We Measured a 98% Hit

DeepSeek context caching is automatic prefix caching: on 2026-07-28 our repeat call reused 3,328 of 3,403 prompt tokens (98%), cutting computed input cost 88% and latency from 1.43s to 0.90s, with no opt-in flag.

The number that surprised us came from the control arm of the same run: the identical DeepSeek family called through a routing marketplace returned zero cached tokens twice and paid full price both times. On this run, the access path decided whether we got the discount at all.

DeepSeek context caching (verified 2026-07)

Context caching is a server-side optimization that stores the already-processed leading prefix of a prompt so that a later request beginning with the same bytes skips recomputation and bills at a reduced input rate. DeepSeek applies it by default. There is no cache marker to insert, no beta header, no second endpoint.

According to DeepSeek API Docs, cache-hit input tokens are priced at $0.014 per million against $0.14 per million for a cache miss, and the discount is applied automatically on repeated prefixes rather than requested by the caller. DeepSeek also exposes the outcome directly: every response object carries prompt_cache_hit_tokens and prompt_cache_miss_tokens, so the hit rate is observable per call instead of being inferred from a monthly invoice.

That split field is rarer than it sounds. Most endpoints report a single cached_tokens integer or nothing at all, which turns hit rate into guesswork.

First-hand: three identical-prefix calls on api.deepseek.com

We sent the same fixed ~1800-token prefix (a fictional API changelog) to deepseek-chat three times on 2026-07-28, two seconds apart, changing only a one-line question at the end, at temperature 0 with a 40-token output budget. The served model reported back as deepseek-v4-flash. Cache behaviour was read from DeepSeek's own usage fields, not estimated.

Call A was a total miss, exactly as expected for a cold prefix. Call B hit 3,328 of 3,403 tokens, which is 98% of the prompt, leaving only the 75 tokens of the changed question to bill at the miss rate. Call C, with a different question again, hit the same 3,328 tokens. The cached region is the stable prefix, and the tail that varies per request is the only part that pays full price.

The cost line needs one honest qualifier. DeepSeek's native API does not return a per-call cost field, so those input figures are computed from the measured hit and miss token counts at the official published rates, not billed amounts we read off a statement. The token counts are measured; the dollars are arithmetic on top of them. Latency, by contrast, was measured wall-clock: 1.43s cold against 0.90s warm, a 37% drop on the repeat.

The routed contrast: same model family, zero cached tokens

Here is the finding that changes how you should read every caching benchmark, including ours. In the same run we called the DeepSeek chat model through a routing marketplace instead of api.deepseek.com. Both calls reported cached_tokens: 0, and the billed cost moved from $0.000698 to $0.000696, which is measurement noise rather than a discount.

On that native-versus-routed pair, the native repeat call cost roughly one twelfth of the routed repeat call. State it as a snapshot of this run and this route rather than a permanent property of routers, because the very next rows contradict the blanket version of the claim.

Z.ai's GLM-5 and MiniMax-M2.5 both returned large cached-token counts through the same router, with the discount visible in the billed cost rather than computed. So "routers lose caching" is false as a general rule. What actually varies is the provider integration behind each model on the route, which is why we treat cache survival as something to verify per model, per path, per run rather than assume.

The Qwen3-235B row is deliberately not counted as cache evidence. Its billed cost fell from $0.000726 to $0.000331, but call B matches Qwen's list price (about $0.00032 computed) while call A billed roughly twice list, so the delta tracks provider-price variance on the routed marketplace rather than a cache hit. Reported cached tokens stayed at zero.

Why some absences mean nothing about capability

Our design triggers implicit caching only. It repeats a prefix and reads what the API reports back. Providers whose caching requires an explicit marker are expected to show zero here, and that is a finding about default behaviour, never a capability gap.

According to Anthropic's prompt caching documentation, Claude caching is activated by explicit cache_control breakpoints, with cache writes priced above standard input and cache reads well below it. Our test never sends those breakpoints, so the zero we recorded for Claude Sonnet 4.6 is the design working correctly, not a limitation of the model. The same caveat covers Kimi K2, whose vendor documents a managed context cache on its own platform, and Qwen, whose implicit context cache is documented for the native DashScope endpoint.

According to OpenAI's prompt caching guide, OpenAI applies automatic caching on its own API for prompts at or above 1,024 tokens with a discounted cached-input rate. We did not test OpenAI natively, and the routed GPT-4o path showed no cached tokens, so treat that row as a statement about the route rather than about OpenAI. MiniMax and Z.ai publish their own caching behaviour at platform.minimax.io and z.ai, and their routed results above are our first-hand anchor for both.

When the cache is worth designing around

The economics follow the prefix, not the model. Workloads with a long stable head and a short variable tail (a fixed system prompt, a few-shot block, a retrieved document reused across turns) put most of every request into the cacheable region. One-shot classification, where each prompt is unique, will rarely hit anything and should be budgeted at the full miss rate.

Two consequences fall out of our run. First, cache benefit follows the access path, so the same model on two routes can carry different effective input costs. Second, because DeepSeek reports hit and miss counts per call, hit rate is a metric you can monitor rather than a hope. If you want the rate card behind these calculations, we keep it on the DeepSeek cache discount page; for the latency side of native versus routed access, see our routing latency comparison.

Disclosure: DeepSeek native figures came from api.deepseek.com; every other endpoint in the table was measured through a routing marketplace on 2026-07-28. Single-region snapshot, one run, and the non-native rows need native re-verification before anyone treats them as vendor-level facts.

FAQ

Do I need to enable DeepSeek context caching? No. According to DeepSeek API Docs, the prefix cache applies automatically on repeated input prefixes with no flag or separate endpoint. Our 2026-07-28 run confirmed it fired on the second call without any configuration change.

How much of my prompt actually gets cached? On our test, 3,328 of 3,403 prompt tokens hit on the repeat call, or 98%. The uncached remainder was the 75-token question that changed between calls. Your ratio tracks how much of the prompt stays byte-identical across requests.

Does caching make the model's answers better? No. Caching affects input cost and latency only. In our run the effect showed up as an 88% cut in computed input cost and a drop from 1.43s to 0.90s on the repeat call, with no claim made about output quality.

Will I still get the cache through an API router? Not automatically. On 2026-07-28 the routed DeepSeek path reported zero cached tokens and full price on both calls, while routed GLM-5 and MiniMax-M2.5 kept their discounts. Verify per model and per route rather than assuming either outcome.

What is the difference between implicit and explicit caching? Implicit caching is applied by the provider whenever it detects a repeated prefix, while explicit caching requires the caller to mark cacheable segments in the request. DeepSeek is implicit; Anthropic's documented mechanism is explicit.

For the full cross-vendor picture, including which providers kept their caches through routing and which did not, read the cluster overview on LLM prompt caching.

Author: Kevin Fan, Customer Success Manager, china-llm.com