DeepSeek API pricing, in your timezone

DeepSeek published the new rate card on 2026-08-13. Peak output on DeepSeek V4-Pro goes from $0.87 to $3.96 per million tokens — 4.6× the old rate.

The company has not published a cost breakdown, so any explanation beyond the announcement itself is speculation. What the numbers show is a move away from the aggressive undercutting that defined DeepSeek’s earlier pricing, toward rates closer to the rest of the market.

The new rates apply from 16 August 2026, 16:00 UTC. Requests billed before that instant use the old card; requests after it use the new one.

Because billing runs on UTC rather than your local clock, the switch lands mid-working-day in some regions. The countdown at the top of this site tracks it in your own timezone.

DeepSeek defines its windows on the UTC clock. Peak hours run 01:00–04:00 UTC and 06:00–10:00 UTC; every other minute of the day is off-peak, which works out to 17h of discounted time per day.

Where you are decides how convenient that is. In the mainland United States the windows fall overnight and in the evening, leaving a continuous off-peak run of at least 15 hours that covers the whole 9-to-5 working day in every US timezone, year round.

The table on this site converts the windows to whatever timezone your browser reports.

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.

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.

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.

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.

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.

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.

Both carry a 1M token context window and the same maximum output length. They differ on price and on how many requests you may run at once: DeepSeek V4-Pro allows 500 concurrent requests, DeepSeek V4-Flash allows 2,500.

DeepSeek V4-Flash output costs $1.32 per million at peak against $3.96 for DeepSeek V4-Pro. Both models moved to the new card on the same date and share the same peak windows.

The rate card says 3.0× on output. Your bill may not agree, because price per token is only half of what you pay — the other half is how many tokens the model spends reaching an answer, and the smaller model does not always spend fewer. One published hands-on comparison ran both across three real coding tasks and found the cheaper model produced better work while consuming enough extra tokens to make the two bills roughly equal.

A second factor is usually larger than the model choice: reasoning effort. In the measured run on this site, 73.6% of all generated tokens were thinking tokens — invisible in the response, billed in full at the output rate, which is the most expensive meter on the card.

So the honest answer is that neither the headline discount nor a benchmark table settles it. Run your own workload on both, compare the total token counts rather than the rates, and check what reasoning effort you left it on.

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.

The rate card covers API usage, billed per token against your API account balance.

Consumer access through the DeepSeek app and website is a separate product on separate terms, and is not what the prices on this site describe.

Balance is held in currency, not in tokens. Credit already on your account stays valid, but from the change-over each request draws down that balance at the new per-token rates, so a given balance buys proportionally fewer tokens than it did before.

Check the official pricing page for the terms that actually govern your account: https://api-docs.deepseek.com/quick_start/pricing/