DeepSeek peak-hour pricing

With the full release of the V4 series DeepSeek both updated its prices and moved to time-of-day pricing. During peak hours every token item costs twice the standard rate. LLMTR passes this through unchanged; no margin is added to model prices.

Cutover

The new prices take effect at 2026-08-16 16:00 UTC.

• Before that instant: the current card below applies and there is no peak multiplier — every hour of the day bills the same.
• From that instant: the new card applies and the peak multiplier is in force.

The cutover happens on its own; which card a request bills against is decided by the moment the request reaches LLMTR.

Peak windows

The windows are fixed in UTC:

Window	UTC	Beijing (UTC+8)
First	01:00 - 04:00	09:00 - 12:00
Second	06:00 - 10:00	14:00 - 18:00

Windows are half-open: 04:00 UTC already bills at the standard rate, while 03:59 UTC is still peak. Neither UTC nor Beijing observes daylight saving, so these boundaries hold year round.

Prices

Per 1M tokens, USD.

New card (from 2026-08-16 16:00 UTC)

Model	Item	Standard	Peak
deepseek/deepseek-v4-flash	Input (cache miss)	0.22	0.44
deepseek/deepseek-v4-flash	Cache read	0.007	0.014
deepseek/deepseek-v4-flash	Output	0.66	1.32
deepseek/deepseek-v4-pro	Input (cache miss)	0.66	1.32
deepseek/deepseek-v4-pro	Cache read	0.022	0.044
deepseek/deepseek-v4-pro	Output	1.98	3.96

The multiplier is uniform across every item: cache reads double during peak too.

Current card (before 2026-08-16 16:00 UTC)

This card has no peak split — the same rate applies at every hour.

Model	Input (cache miss)	Cache read	Output
deepseek/deepseek-v4-flash	0.14	0.0028	0.28
deepseek/deepseek-v4-pro	0.435	0.003625	0.87

The deepseek/deepseek-chat and deepseek/deepseek-reasoner identifiers are routed to V4-Flash by DeepSeek and bill exactly like V4-Flash, peak multiplier included.

Which rate applies

The rate is chosen from the moment the request reaches LLMTR. A single instant is used per request, so the reservation and the final charge always agree. A call that starts at 09:59:59 UTC and finishes at 10:00:20 UTC is billed entirely at the peak rate rather than split across both.

Estimating cost

You can determine whether you are currently in a peak window from the UTC clock:

from datetime import datetime, timezone

PEAK_WINDOWS = [(60, 240), (360, 600)]  # UTC minutes of day

def is_peak(moment: datetime) -> bool:
    utc = moment.astimezone(timezone.utc)
    minute_of_day = utc.hour * 60 + utc.minute
    return any(start <= minute_of_day < end for start, end in PEAK_WINDOWS)

print(is_peak(datetime.now(timezone.utc)))

const PEAK_WINDOWS = [
  [60, 240],
  [360, 600]
];

function isPeak(date = new Date()) {
  const minuteOfDay = date.getUTCHours() * 60 + date.getUTCMinutes();
  return PEAK_WINDOWS.some(([start, end]) => minuteOfDay >= start && minuteOfDay < end);
}

Both examples read UTC. Using local time gives the wrong answer depending on where your server runs.

Reducing cost

• Move batch and schedule-tolerant work outside the peak windows. 17 hours of each day bill at the standard rate.
• Use prompt caching. The cache-read rate is far below the input rate and stays cheaper than standard input even during peak.
• Prefer deepseek-v4-flash for latency-tolerant work.

Usage records

Every row on the Usage page stores the unit price applied to that request. Historical records are never re-priced; whatever a request was charged is what its record keeps.