Measured 15 August 2026 · 650 requests
DeepSeek cache pricing
DeepSeek meters input tokens twice. Tokens it can serve from a previous request cost $0.022 per million; tokens it has to read fresh cost $0.66 — 30× more for the identical token. Your bill is therefore decided by a number that appears neither on the pricing page nor on your invoice: the share of your input that hits the cache.
This page is built on that number as measured, not assumed. The figures below come from 155.9M of real agent traffic on one machine, read out of the session logs DeepSeek Harness writes to disk. The script that produced them is published, so you can run the same audit on your own logs.
Measured result
Measured hit rate
98.09%
613 requests on DeepSeek V4-Pro, reasoning effort high
Prompt tokens audited
155.9M
152.9M served from cache, the other 1.91% billed in full
What the cache removed
$97.56
$104.39 → $6.82 on the new off-peak card
One developer, one machine, agent workloads over a stable codebase — a large sample of requests but a sample of one usage pattern. Chat and RAG traffic cache far worse; see what moves the number below.
Checked against the invoice
Anyone can add up numbers in a log file. The question is whether they are the numbers being charged for — so the same day was pulled from the DeepSeek console and compared.
| From the logs | DeepSeek console | Gap | |
|---|---|---|---|
| Cost, priced on the CNY card | ¥17.45 | ¥17.73 | −2% |
| Tokens | 157.7M | 160.2M | −2% |
| Requests | 650 | 684 | −5% |
The cost gap and the token gap are the same number. Per-token arithmetic agrees with the invoice; the local logs are simply short by 34 requests — sessions deleted before the audit, and requests that failed or were retried without ever writing a completed message. Every measured figure on this page is therefore a floor, not an estimate.
Priced on DeepSeek's published CNY card, not converted from the USD one: a Chinese account is billed in CNY, and the USD card is a rounded conversion of it — converting would inject an error unrelated to the tokens. Console figures are for 14 August 2026, before the new rates take effect.
The increase hits heavy cache users hardest
Coverage of the 16 August 2026 change has focused on output, which rises 2.3×. But the three meters did not move together, and the one that moved most is the cheap one.
Input, cache hit
$0.003625 $0.022
6.1×
Input, cache miss
$0.435 $0.66
1.5×
Output
$0.87 $1.98
2.3×
DeepSeek V4-Pro, old flat card against the new off-peak card — the cheaper of the two new rates, so this is the favourable comparison.
The better you cache, the worse this change is for you. Repricing the measured 98.09% workload on the new off-peak card multiplies its bill by 2.7×. The identical tokens from a workload that caches nothing would go up only 1.5×. Efficient prompt design was rewarded most under the old card, so it had the most to lose.
| Rate card | As billed | If nothing cached | Cache saved |
|---|---|---|---|
| Before the change | $2.51 | $68.47 | $65.97 |
| New card, off-peak | $6.82 | $104.39 | $97.56 |
| New card, peak | $13.65 | $208.77 | $195.13 |
None of which argues against caching. In absolute terms it is worth more than it was — a percentage off a larger number — and it remains the single largest lever on a DeepSeek bill. It just no longer bends the curve as steeply as it did.
How the cache decides which rate you pay
Caching is on by default, needs no API parameter, and costs nothing to write to. DeepSeek stores prefixes on disk and reuses them when a later request starts with exactly the same bytes.
Matching is by prefix, and exact
A hit requires the beginning of the prompt to match a stored prefix byte for byte. Partial or fuzzy overlap earns nothing. Everything after the first difference is a miss, which is why one changed character near the top can cost you the whole prompt.
Cache units form at boundaries
DeepSeek creates reusable units at request boundaries, at prefixes it detects as common across requests, and at fixed token intervals inside long inputs. Community testing suggests those intervals land on multiples of 128 tokens — useful intuition, not a documented guarantee, and not something to design around.
Best-effort, and it expires
DeepSeek guarantees no hit rate. Unused entries are cleared after a few hours to a few days, so a warm-up run does not buy a standing discount. Each account’s cache is isolated from others.
No write premium
Nothing is charged for populating the cache — the first request pays the miss rate it would have paid anyway. Worth noting when comparing with providers that bill a separate cache-write rate you must earn back through later reads.
Mechanics per DeepSeek’s official context-caching documentation; the 128-token observation is from third-party testing and is flagged as such by its authors.
What moves the number
A session starts with nothing to hit. The measured run shows how fast that stops being true: by the second request most of the context is already cached, and it climbs from there as the stable prefix grows.
Cache hit rate by request number within a session
- #1 16.8%
- #2 92.1%
- #3 87.1%
- #4–5 88.9%
- #6–10 92.3%
- #11+ 98.3%
The first request of each session averaged 16.8% — that is the price of a cold start, and it is unavoidable. Everything after it is design: the climb to 98.3% happens only because the prompt prefix stayed byte-identical between turns.
What takes it to zero
- A timestamp, request ID or trace ID at the top of the prompt
- Reordering tool definitions between calls, or regenerating them non-deterministically
- Putting the user’s variable question before the stable instructions
- Rewriting the system prompt per request rather than per deployment
What keeps it high
- Stable content first: system prompt, tool schemas, long reference documents
- Appending to conversation history rather than rebuilding or re-summarising it
- Batching requests that share a prefix so they run while it is still warm
- Keeping one long session rather than many short ones — each new session pays the cold start
The meter caching cannot touch
Caching discounts input. Output has no cache and no discount, and on a reasoning model most of your output is not the answer.
73.6%
of generated tokens in the measured run were thinking tokens
Invisible in the response, billed in full at $1.98 per million off-peak — 90× the cached input rate. That run used reasoning effort high. Lowering it is the one lever that acts directly on the most expensive meter, and unlike prompt restructuring it takes a single config change. For contrast, the DeepSeek V4-Flash requests in the same logs came in at 57.2% — though on different tasks, so read it as a second data point rather than a comparison.
Compare the two models on costBoth levers at once
Cache state and time of day are independent, and they multiply. Between the cheapest and most expensive way to send the same input token there is a factor of 60×.
Cached, off-peak
$0.022/M
Uncached, peak
$1.32/M
DeepSeek V4-Pro input, per million tokens, on the new card. Whether your traffic can move into the discounted window depends on where you are — the windows in your timezone are on their own page.
Measure your own, don’t inherit ours
Every figure on this page describes one workload. Yours will differ, and DeepSeek already tells you by how much — every API response carries the breakdown.
From any API response
The usage object contains two disjoint counters that sum to your prompt size. Log them and the guesswork ends.
hit_rate = prompt_cache_hit_tokens / (
prompt_cache_hit_tokens + prompt_cache_miss_tokens
)From DeepSeek Harness, with no instrumentation at all
dsh already records a token breakdown for every request it makes, in ~/.dsh/sessions. This is the script that produced every measurement on this page — it reads those logs and prints your real hit rate, your bill on all three rate cards, the counterfactual without caching, and your own warm-up curve.
curl -O https://deepseekprice.com/dsh-cache-audit.py
python3 dsh-cache-audit.pyOne file, no dependencies, no network access, and it never opens your credentials file. Read it before you run it — the source is right here.
Cache pricing questions
How much cheaper is the DeepSeek off-peak rate?
Off-peak rates are 50% lower than peak, applied to input and output alike. On DeepSeek V4-Pro that is $1.98 per million output tokens instead of $3.96.
It is worth being clear about what the discount is measured against: it is half of the new peak rate, not a return to the old one. Off-peak output still costs 2.3× what the same tokens cost under the previous flat card.
The rate is decided by when the request reaches DeepSeek, not when your job was queued locally. Batch work that can tolerate delay is the clearest way to capture it.
How does cache-hit pricing work?
Input tokens are billed at two different rates. Tokens DeepSeek can serve from its prompt cache cost $0.044 per million at peak; tokens it has to process fresh cost $1.32 per million — a gap of 30×.
Caching keys on identical prefixes, so it rewards keeping the stable part of a prompt — system instructions, tool definitions, a file you are iterating on — byte-identical at the front, with the varying part at the end. Reordering that prefix between calls throws the cache away.
Coding assistants and long agent loops re-send the same context repeatedly and commonly sit above 90% cache hits. That is why the calculator on this site defaults to 80% rather than assuming every token is billed at full price.
What cache hit rate should I actually expect?
It depends entirely on prompt shape, and the spread is enormous. A measured run of 613 requests from a coding agent — 155.9M of prompt tokens — came in at 98.1%, because an agent re-sends a long, stable context on every turn.
That is close to the ceiling, not the average. The first request of a session in the same run hit only 16.8% — there is nothing to hit yet — and workloads that put anything variable at the front of the prompt, such as a timestamp or a request ID, measure near zero however long they run.
Do not budget on someone else’s number, including this one. Both figures needed to compute your own are returned on every API response.
Does the price increase make caching less valuable?
Relatively yes, absolutely no — and the relative move is the surprising one. The cache-hit meter rose 6.1× against the old card, more than the cache-miss meter at 1.5× or output at 2.3×. The cheapest meter went up the most.
The consequence is counterintuitive: the better you cache, the harder this change lands. Repricing the measured 98.1% workload on the new off-peak card multiplies its bill by 2.7×. The identical tokens with no caching at all would have gone up only 1.5×.
In absolute terms caching is still worth more than it was, because it is a percentage off a bigger number. On that same run it removed $97.56 from a bill that would otherwise have been $104.39.
How do I measure my own cache hit rate?
Every API response carries the two counters in its `usage` object: `prompt_cache_hit_tokens` and `prompt_cache_miss_tokens`. They are disjoint and sum to the prompt size, so your hit rate is the first divided by the total. Log them and the guesswork ends.
If you use DeepSeek Harness, they are already on disk — it records a token breakdown for every request in `~/.dsh/sessions`. The audit script this site publishes at /dsh-cache-audit.py reads those logs and prints your real hit rate and bill. It has no dependencies and sends nothing anywhere.
Does DeepSeek charge extra to write to the cache?
No. Caching is automatic and there is no separate write charge — you are billed at the hit rate or the miss rate, and nothing else.
This is a real difference from some competitors rather than a technicality. Anthropic bills a premium for writing to its prompt cache, which has to be earned back through reads before caching pays for itself. On DeepSeek the first request simply costs the miss rate, as it would have anyway.
The trade-off is that you get no guarantee in return. DeepSeek describes its caching as best-effort, and unused entries are cleared after a few hours to a few days.
Is DeepSeek still cheaper than Claude, OpenAI and Gemini after the increase?
For most workloads, yes — but by a smaller margin than before, and the gap narrows further against the cheaper tiers of each provider once you account for cache hits.
The right comparison depends on your own mix of input, output and cache rate, which is what the calculator is for: it applies your volumes to every rate card at once instead of comparing headline numbers that assume a workload you may not have.
Rates are compiled from DeepSeek's published pricing page and may lag behind changes. Measurements were taken on 15 August 2026 from DeepSeek Harness session logs (~/.dsh/sessions) and describe one developer's workload — they are evidence about what is achievable, not a forecast of your bill. Verify rates against the official source before committing spend.