DeepSeek's new off-peak rate costs more than what you pay today

DeepSeek took its flagship out of preview on August 13. The deepseek-v4-pro endpoint now points at DeepSeek-V4-Pro-0813 under an MIT license, with a 1-million-token context window, three reasoning effort levels, and native OpenAI Responses API compatibility. The model names in the API did not change, so most people running it swapped flagship versions without touching a line of code.

The same day, DeepSeek announced that the entire API price list moves to peak and off-peak billing at 16:00 UTC on August 16. The official framing is that off-peak rates sit at half the peak rates. That phrasing invites a specific wrong conclusion, and it is worth doing the arithmetic before Sunday rather than after your next invoice.

Every rate goes up, including the cheap one

Here is what DeepSeek charges now against what both new tiers charge, per million tokens.

V4-Pro

	Today	New off-peak	New peak
Input, cache hit	$0.003625	$0.022 (6.1x)	$0.044 (12.1x)
Input, cache miss	$0.435	$0.66 (1.5x)	$1.32 (3.0x)
Output	$0.87	$1.98 (2.3x)	$3.96 (4.6x)

V4-Flash

	Today	New off-peak	New peak
Input, cache hit	$0.0028	$0.007 (2.5x)	$0.014 (5.0x)
Input, cache miss	$0.14	$0.22 (1.6x)	$0.44 (3.1x)
Output	$0.28	$0.66 (2.4x)	$1.32 (4.7x)

Off-peak is not a discount against what you pay today. It is the new floor, and the floor sits above the current ceiling in all six categories. If you schedule every request into off-peak hours and change nothing else, your bill still rises somewhere between 1.5x and 6.1x depending on what your traffic is made of.

That last clause is the part worth planning around, because the multiplier is not uniform. A single blended estimate of "roughly three times more" will be wrong for almost everyone. Output-heavy work on V4-Pro goes up 2.3x at best. Cache-hit input goes up 6.1x at best and 12.1x at worst, which is the roughly 1,100% figure that showed up in the coverage.

The best-optimized workload takes the biggest increase

Cache-hit input rising 12.1x is counterintuitive enough to sit with for a second. Cache hits are what you get when you have done the work properly: a long stable system prompt, an agent loop that re-reads the same context every turn, a retrieval pipeline that pins the same documents across a session. On DeepSeek's old rate card that traffic was close to free, at $0.003625 per million tokens. It is about to become a visible line item.

Caching still pays. On V4-Pro a cache hit was 120x cheaper than a cache miss before; afterwards it is 30x cheaper. That is a large margin by any standard and nobody should tear out prompt caching over this. But if your unit economics were resting on cache hits being effectively free, the assumption underneath them is being repriced by a factor of six at the cheapest tier, and a spreadsheet built on the old number will understate the new bill by more than the headline output-price change does.

The practical move is to pull your actual token mix rather than reasoning about it. Every provider dashboard breaks usage into cache-hit input, cache-miss input, and output. Take last month's real numbers, multiply each of the three by its own factor from the table above, and compare that against what you paid. That is a five-minute calculation and it is the only one that reflects your workload rather than an average of everyone's.

The peak window is somebody else's working day

Peak hours are 01:00–04:00 and 06:00–10:00 UTC. That is seven hours out of twenty-four, so seventeen hours a day are off-peak. The shape looks arbitrary until you convert it: in China Standard Time it is 09:00–12:00 and 14:00–18:00. The peak window is the Chinese working day with the lunch break cut out of the middle. DeepSeek is pricing around its domestic load, which is the sensible thing for DeepSeek to do and an easy thing for everyone else to misread.

Where that lands for you depends entirely on your timezone, and the results are less intuitive than they first appear:

• US Eastern (UTC-4): peak is 21:00–00:00 and 02:00–06:00 local. Your interactive daytime traffic is entirely off-peak. Your nightly batch job at 2am is squarely in peak.
• US Pacific (UTC-7): peak is 18:00–21:00 and 23:00–03:00 local. Evening usage and overnight jobs are the expensive ones.
• Central European (UTC+2): peak is 03:00–06:00 and 08:00–12:00 local. Your entire working morning is peak.
• India (UTC+5:30): peak is 06:30–09:30 and 11:30–15:30 local, covering most of the working day.

The pattern worth extracting: teams in the Americas mostly get their interactive traffic priced at off-peak by accident, and then pay peak rates for the scheduled work they deliberately moved to the middle of the night to be cheap. Teams in Europe get the inverse problem, with the working morning inside the expensive window and nothing they can do about human working hours.

What to change before Sunday

Scheduled work is the lever, because it is the only part of your traffic that does not care what time it runs. Evaluation suites, embedding backfills, index rebuilds, nightly summarization, document ingestion, regression runs against a prompt library: none of these need to happen at any particular hour. Moving them is a cron change, not an architectural one.

If you run a nightly job at 02:00 US Eastern, that is 06:00 UTC, which is the first hour of the second peak block. Shifting it to 22:00 Eastern puts it at 02:00 UTC, which is still peak. Shifting it to 18:00 Eastern puts it at 22:00 UTC, comfortably off-peak. The point is that "later at night" is not a reliable heuristic here, because the peak window is defined in a timezone that is not yours. Convert your cron schedules to UTC and check them against 01:00–04:00 and 06:00–10:00 explicitly.

For interactive traffic you cannot move, the remaining questions are the ordinary ones. Whether the new price still clears your bar against alternatives is worth checking on measured numbers rather than rate cards, the same way the Sonnet 5 tokenizer change made a headline rate misleading. If you route through OpenRouter or a similar gateway, you already have the switching mechanism in place and the exercise is a comparison rather than a migration. If you call DeepSeek directly and it is your only provider, this is a reasonable moment to find out how much work moving would be, before you need the answer urgently. Our Claude and DeepSeek comparison covers the capability side of that question.

One thing not to do is rewrite your caching strategy in response to the 12.1x number. The relative economics still favor caching by 30x, and the increase looks dramatic mainly because the starting point was so close to zero.

The transferable part

Underneath the specifics there is a reading habit worth keeping. When a provider announces tiered pricing, the tier they anchor on is rarely the number that determines your bill. "Off-peak at half the peak rate" is a true statement about the relationship between two new numbers, and it says nothing at all about the relationship between either of them and what you currently pay. The comparison that matters is always against your existing invoice, broken out by token category, because providers change the categories at different rates and the blended average hides it.

Two habits follow from that. Find the provider's home timezone before you interpret a time-based rate, because peak windows are drawn around the domestic customer base and will look random until you convert them. And keep the parts of your workload that can move on a schedule you can actually edit, because a cron file is the cheapest hedge available against a pricing change announced three days out. The same discipline that keeps token overhead visible in a coding agent applies to a rate card: measure the thing you are actually billed for, not the thing that got announced.

DeepSeek's stated reason for the change is to allocate capacity more sensibly by pushing flexible work away from congested hours. That is a coherent goal and the incentive works as intended. It is simply worth being clear that the mechanism is a price increase across the board, with a discount available relative to a number that did not exist last week.

Prices and the effective time in this post were read from DeepSeek's own API pricing documentation on August 14, 2026. The benchmark improvements DeepSeek published alongside the GA release are self-reported and have not been independently verified.