DeepSeek Cache Hit Pricing: The $0.003 Token Math Explained

Most pricing pages describe what things cost. DeepSeek's page is unusual because it lets you compute what things cost: it publishes the full matrix — peak versus off-peak, cache hit versus cache miss, input versus output — instead of a single headline number. The interesting cell is not the famous $0.15 per 1M input. It is $0.003 per 1M cached input tokens on deepseek-flash, a row most people read past.

That $0.003 is 98% below the same model's off-peak cache-miss input price, and it is the cheapest repeated-input pricing in our directory. The rest of this article is the arithmetic of when that number stops being a footnote and becomes your entire business case — plus the prompt structures, scheduling windows, and honest limits that decide whether you actually get it.

Why a pricing page you can compute from is rare

A pricing page is computable when it publishes the dimensions that multiply, not just the totals. DeepSeek publishes three:

1. A temporal dimension — a peak window and an off-peak window with different rates.
2. A cache dimension — a separate rate for input that the provider recognises as a repeat of a previously seen prefix.
3. A direction dimension — input and output priced separately, because a cached prefix has no effect on generation.

When all three dimensions are published, you can model a workload before you run it. When only a headline rate is published, you can only estimate after the bill arrives. This is the difference between budgeting and guessing, and it is why the entry in our DeepSeek directory listing carries the whole matrix rather than a summary line.

The published matrix, row by row

The rates below come from the official DeepSeek pricing documentation↗, read on 2026-09-17. Peak pricing applies Monday–Friday in two UTC windows, 01:00–04:00 and 06:00–10:00.

Read the table as two independent multipliers over a base rate, and it becomes much easier to reason about.

Three facts that drive every decision

First: peak is exactly 2× off-peak, on every single row. The schedule is a clean multiplier, not a different price list. That matters because it means off-peak scheduling does not change the shape of your cost curve — it scales the whole curve down by half and leaves your architectural choices intact. You never have to re-tune prompt design when the clock changes.

Second: a cache hit is roughly 4% of a cache miss on the same model. On flash, $0.003 against $0.15 is a 2% rate, and the base article's framing of "~4%" holds for the ratio across the peak rows ($0.006 against $0.30). Either way, the reusable part of your prompt becomes almost free while the fresh part keeps its full price. There is no other lever in the matrix with a 25×–50× range.

Third: output is never discounted by caching. Only input is. This is the single most misread column. A workload that sends a 20K-token context and generates 200 tokens is a context workload and caching transforms its cost. A workload that sends 200 tokens and generates 4,000 is a generation workload and caching barely touches it. Know which one you are running before you celebrate.

Worked example: an 8K prefix, 100 requests a day

Take a realistic shape: an application with an 8K-token stable preamble — system prompt, tool schemas, a few-shot block, and a fixed policy document — reused on 100 requests per day, all scheduled off-peak.

Without caching, every request pays cache-miss input on the whole prefix:

• 100 requests × 8,000 tokens = 800,000 input tokens
• 800,000 ÷ 1,000,000 × $0.15 = $0.12 per day just for the repeated prefix

With caching, the first request pays full price and 99 pay the hit rate:

• First request: 8,000 ÷ 1,000,000 × $0.15 = $0.0012
• Remaining 99: 792,000 ÷ 1,000,000 × $0.003 = $0.002376
• Total: ≈ $0.0036 per day

Same workload, same model, same tokens on the wire — a 33× reduction on the input side. On a daily basis the absolute numbers look small because the workload is small. Scale it and the ratio is what compounds: at 10,000 requests a day the prefix costs roughly $12 without caching and roughly $0.25 with it, and at 1,000,000 requests a day it is roughly $1,200 versus roughly $24. The percentage saving is identical at every scale; only the number of zeros changes.

That is the whole argument for caching in one line: you are not optimising the price, you are removing 96% of the billable units.

The break-even is the second identical request

Caching has a write side and a read side. The write happens when the provider stores a prefix it has not seen before; the reads happen on every subsequent request that reuses it. The obvious question is how many repeats you need before the reads outweigh the write.

On this matrix the answer is: two. Because the read rate is a small fraction of the miss rate, request one at full price plus request two at the hit rate already costs less than two full-price requests. There is no meaningful volume threshold to cross, no minimum batch size to accumulate, and no tier to unlock. The only precondition is stability: the prefix has to be byte-identical, on the same model, within the cache's lifetime.

That is a very unusual property. Many caching systems only pay off at scale, which means you have to forecast traffic before you can justify the engineering. Here, the engineering decision is closer to free: if your workload repeats any prefix at all, caching is already correct.

Which workloads actually earn the discount

Caching rewards repetition, so rank your workload by how much of its input is stable across calls. From best to worst:

1. Agent loops. The system prompt, the tool schemas, and the growing conversation history are re-sent on every round-trip of every task. The prefix is large and highly stable within a task. This is the maximum-benefit case, and it is why caching is the highest-leverage optimisation for agent workloads — we break down the per-turn arithmetic in Why your token budget is actually a request budget.
2. Retrieval over a fixed corpus. When the same documents are retrieved for many queries, the retrieved block repeats. High benefit, though a re-ranking step that shuffles document order can destroy the hit.
3. Few-shot classification. The examples block is identical on every call; only the final input changes. High benefit on the expensive part of the prompt.
4. One-shot generation with novel input. Nothing repeats. No benefit at all — and paying the write side is pointless.

The rule of thumb we apply when modelling a workload: if your input tokens repeat across requests, you are leaving roughly 96% of the input bill on the table without caching. If they do not repeat, caching is a no-op and your only lever is off-peak scheduling.

Prompt structure that maximises cache hits

Cache reuse is prefix-based. That single sentence generates most of the practical advice:

• Put stable content first, variable content last. System prompt, then tool schemas, then few-shot examples, then conversation history, then the user's new message. If a variable value sits near the top, nothing below it can ever be reused.

[object Object]

• Never interpolate a timestamp, request ID, or random ordering key into the preamble. A timestamp at the top of the system prompt is the most common accidental cache killer we see. If you need the time, put it in the final user message.
• Serialise JSON deterministically. Two identical objects with different key order are two different byte strings. Sort keys, pin separators, and never let a library emit indent=2 on one request and compact JSON on the next.
• Keep tool schemas stable. Adding, removing, or reordering a tool rewrites the prefix. Group infrequently used tools into a second, separate call rather than editing the schema set on every run.
• Keep the cache warm within a task, not across days. Within an agent task the prefix grows and repeats every turn — that is where the win is. Across days the cache may or may not survive, so never build a business case that depends on a hit you cannot observe.
• Watch your hit rate as a first-class metric. If you are not logging cached versus uncached input tokens per request, you cannot tell whether any of the above worked.

Off-peak scheduling compounds the discount

Peak is a 2× multiplier on every row, including the cache-hit rows ($0.003 becomes $0.006 off-peak to peak). So a cached, off-peak workload gets the full stack: the cheapest base rate multiplied by the cache rate.

The marginal decision is what matters for a production system. A cached request off-peak costs $0.003 per 1M; the same request at peak costs $0.006. On a high-volume cached workload, moving traffic into the off-peak window is worth exactly as much as the caching optimisation itself — you can serve double the traffic for the same input budget. The practical patterns:

• Batch and backfill. Put anything that does not need to be interactive into a queue that drains outside the two peak windows: nightly re-indexing, evaluation runs, dataset labelling, report generation.
• Keep an interactive tier small and honest. User-facing requests will land at peak sometimes; price them at peak rates rather than at your optimistic blended average.
• Track the boundary, not just the total. A job that runs from 00:30 to 01:30 UTC straddles the peak boundary and pays two rates inside one hour. Chunk long jobs on the boundary.

What caching never discounts

Two honest limits, both of which have sunk real budgets:

• Output is full price. Caching input does not discount generation. If your workload is 10K input and 8K output, input falls by roughly 96% while output sits at $0.60–$1.20 per 1M — often the majority of the bill on a verbose task. If output dominates your spend, the correct optimisation is shorter outputs: tight schemas, explicit token ceilings, and stopping conditions, not caching.
• Cache scope is per-prefix and per-model. A prefix cached for flash does not help a V4-Pro request; a changed system prompt invalidates the reusable region. The discount rewards stability, so chatty, ever-changing prompts earn less. If your product's value depends on maximal prompt variety, caching will under-deliver and you should plan around off-peak scheduling instead.

Scaling the model up

Here is the same 8K prefix at four volume levels, off-peak, cached versus uncached. These are arithmetic projections from the published rates, not observed bills, and they exclude output tokens:

The ratio settles near 50× once the one-time full-price prefix is amortised away, which is the asymptotic value of the hit rate. Treat the table as a model you can re-run with your own prefix size — the arithmetic is one multiplication against each row of the pricing matrix.

How we verified this

Every rate in this article comes from DeepSeek's own pricing documentation, read on 2026-09-17, and the peak windows are quoted from the same page. We re-read the page rather than copying a figure that had drifted across third-party summaries, because model-tier names and per-model rates on this provider have moved more than once this year. The worked examples are arithmetic on the published numbers, executed off the page — they are not benchmark results, and we do not present them as measurements. Where a figure in this article is derived rather than printed, we say so.

FAQ

Does the cache survive between separate requests to the same account? Yes, that is the entire mechanism, but you should treat survival time as an implementation detail rather than a guarantee. Design your caching argument so it holds even if hits only occur within a short window — for example, within one agent task or one batch run — and treat longer-lived hits as upside.

Is the discount worth it if my prompts change frequently? Only partially. Changing a system prompt rewrites the reusable prefix, so the next call is billed as a miss. If prompt variety is core to your product, estimate your realistic hit rate first and model the saving as a fraction of 96% rather than the full amount.

Should I choose flash or V4-Pro for a cached workload? Flash has the lower absolute cache-hit rate ($0.003 versus $0.022 per 1M off-peak) and also the lower output rate, so a cached, high-volume workload lands cheapest on flash. Choose the higher tier only when the quality difference in your own evaluation justifies the roughly 7× cache-hit rate — and model the output cost too, which scales by a similar factor.

Do I need a special parameter to enable caching? DeepSeek surfaces cache usage through the usage fields in API responses rather than asking you to opt in request by request, which is why the practical discipline is prompt ordering rather than a flag. Read the usage object on your first few calls and confirm cached input tokens are actually non-zero before you bank the saving.

The math in one line

On DeepSeek, stable input is nearly free at $0.003 per 1M cached tokens off-peak, and fresh output is the product at $0.60–$1.20 per 1M. Structure your prompts so the expensive part is what you generate and the cheap part is what you repeat, schedule the repeats off-peak, and you are paying the floor of the entire matrix. The number that matters was never the $0.15 headline — it is the $0.003 three rows down.