DeepSeek Context Caching: The 50x Hit/Miss Spread, Explained Properly

Posted on Oct 30 • Originally published at ai-info.fastget.link

Disclosure: I run ai-info.fastget.link, an independent reference site for AI API pricing and comparisons. No affiliate links in this post. All figures below were checked on the date noted — treat it as a snapshot, not gospel. This post is a mirror; the canonical version lives on my site.

Written 19 Sep 2026 · prices verified 19 Sep 2026 19 Sep 2026

Most people's mental model of prompt caching is "if I send something similar again, it's cheaper." DeepSeek's actual implementation is stricter than that, and the gap between the mental model and the real rule is where the money leaks. Here's how the disk cache actually decides what counts as a hit — and how to tell whether you're getting the 50× rate or silently paying full price.

DeepSeek calls the feature Context Caching on Disk. Every request you send triggers the construction of a hard-disk cache of the input prefix. When a later request shares that prefix, the overlapping part is fetched from disk instead of being recomputed, and those tokens are billed at the cache-hit price.

Two consequences follow from the disk-based design. First, it's account-scoped and automatic — the docs are explicit that it "is enabled by default for all users, allowing them to benefit without needing to modify their code." Second, it's prefix-only: the cache matches the front of your input. Change one token near the top of a long prompt and everything after it is recomputed and billed as a miss, even if the rest is byte-identical.

Because DeepSeek-V4 models use Sliding Window Attention, the cache isn't one continuous blob you can join mid-way. Each cached prefix is an independent, complete unit, and a request only counts as a hit when it fully matches one of those units. The docs' own example is worth internalizing:

Say your first request is A + B (a long document A, then question B). Your second request is A + C — same document, different question. The second request does not hit, because A + C doesn't fully match the stored unit A + B. A partial overlap isn't enough.

But here's the part most write-ups miss: after seeing A + B and A + C, the system detects the common prefix A and persists it as its own cache unit. When your third request A + D arrives, it fully matches A — and hits. So in a same-document workflow, you typically pay full price on the first one or two calls, then the hit rate snaps up on everything after.

Cache units get written to disk at three kinds of moments, per the official guide:

The multi-turn case is the easy win: request two of a conversation contains request one's input plus the assistant's reply, so it fully matches the unit ending at the model output — conversation history rides the hit price. The stateless case (fresh request per call, same big prefix) takes one or two calls to warm up, as above.

The response usage object carries two fields that settle the question:

If you're doing anything nontrivial with the API, watch these numbers on your first few real calls. The miss pattern tells you exactly what's breaking the prefix: hit = 0 on every call means something at the very front of your prompt is changing each time — a timestamp in the system prompt is the classic culprit. A hit rate that collapses partway through a long conversation usually means the change sits mid-history.

Current official pricing, per 1M tokens, with the hit and miss rates side by side:

Peak hours are 01:00–04:00 and 06:00–10:00 UTC, Monday through Friday — everything else is off-peak, and off-peak is a flat 50% of peak across the board. The caching discount stacks on top of that: hit tokens are 1/50th of the miss price on flash ($0.003 vs $0.15) and 1/30th on pro ($0.022 vs $0.66).

Run the numbers on a realistic job: a 500K-token document, 50 independent questions against it, no conversation state — each call re-sends the document. The first two calls miss (and the second one is what triggers the common-prefix persist). Calls 3 through 50 hit. Ignoring the small per-question tokens:

That's roughly 94% off the input bill, from a feature you never configured. Output tokens are billed the same either way. If you want to model this for your own workload, the cost calculator does the arithmetic.

The failure modes all reduce to one idea: the front of your prompt is not as stable as you think it is.

Where caching pays off most: coding agents and other harness-driven workloads. A fixed system prompt plus a growing but append-only conversation is exactly the shape the prefix rule rewards, which is one reason agent backends are a good fit for the API — see DeepSeek as a coding agent backend.

The two discounts are independent and compound multiplicatively. Off-peak hours alone halve every rate; caching then divides the input price by another 50. A flash-model input token that lands in an off-peak cache hit costs $0.003 per 1M — for practical purposes the floor of what DeepSeek input costs. Conversely, a peak-hour miss on v4-pro pays $1.32 per 1M, 440× the floor rate for the same token. If your workload is schedulable, shifting it into the off-peak window is the cheapest optimization available; the window rules are covered in DeepSeek off-peak pricing explained.

One more number worth knowing as context: V4.1-Flash and V4 Pro both take up to a 1M-token context. The larger the context you actually use, the more the hit/miss spread dominates your bill — at 1M tokens of prefix, the difference between a hit and a miss is $0.003 versus $0.15 per call before you've generated a single output token.

Prices and hit rules checked against DeepSeek's official documentation on 2026-09-19. DeepSeek revises pricing periodically — verify against the official pages before committing a budget.

Sources: DeepSeek API Docs — Context Caching, DeepSeek API Docs — Models & Pricing

Originally published on ai-info.fastget.link — more DeepSeek pricing and comparison pieces there.