DeepSeek Peak Hours & Off-Peak Pricing: Timezone Guide

DeepSeek is the only major API provider that charges you a different price depending on what time it is. Every other frontier vendor sells discounts in exchange for turnaround — commit to a 24-hour batch window, pay half. DeepSeek sells it in exchange for the clock: run the same synchronous request at 11:00 UTC instead of 09:00 UTC and it costs half as much, with identical latency.

Most teams are not using that lever, usually because they have never worked out which of their local working hours are peak. This page is the scheduling guide: the exact windows, what they look like in eight time zones, how much of the week is actually cheap, which workloads are worth moving, and what it costs you to ignore all of it.

For the complete rate card — every model, every token type, historical pricing and how DeepSeek compares on price per million — see our DeepSeek V4-Pro pricing reference. This page assumes you know the rates and want to know when to spend them.

When are DeepSeek's peak and off-peak hours?

DeepSeek's official pricing page carries this footnote, verbatim:

Off-peak rates are half of the peak rates. Peak hours are 01:00 - 04:00 and 06:00 - 10:00 UTC, Monday through Friday (all other hours are off-peak).

Three things in that sentence do most of the work:

• There are two peak blocks, not one — a three-hour block and a four-hour block, separated by a two-hour off-peak gap at 04:00–06:00 UTC.
• Peak is weekdays only. Saturday and Sunday bill off-peak for all 48 hours, at every hour of the day.
• The discount is uniform. Off-peak is half of peak on every token type — cache-hit input, cache-miss input and output — across all three published models: deepseek-v4-pro, deepseek-v4-flash and deepseek-v4-flash-vision-exp. There is no model or token-type carve-out.

Here is the compact reference, per million tokens:

That is the last rate table on this page. Everything below is about scheduling.

What are DeepSeek's peak hours in my time zone?

This is the part that actually changes behaviour. The windows are published in UTC, which means a team in California and a team in Bengaluru are looking at completely different working days.

Offsets below are for August 2026, with northern-hemisphere daylight saving active. The final column is the share of a local 09:00–17:00 working day that falls inside a peak window.

Read the extremes and the design becomes obvious. In Beijing and Singapore, peak is the working day — 09:00 to noon and 14:00 to 18:00, with a lunch-shaped gap in the middle. DeepSeek has sized its expensive hours to its home market's load curve. In North America, the entire working day is off-peak; peak lands in the evening and the small hours.

So if you are in California, your 9am job is off-peak, and so is your 2pm job, and your 5pm job. You are getting the cheap rate by geography without doing anything. If you are in Singapore or Bengaluru, the opposite is true, and scheduling is worth real money.

Two traps in the table

The weekday boundary is a UTC boundary. "Monday through Friday" means Monday through Friday in UTC. For anyone west of Greenwich, that shifts the edges of the week. In US Pacific time, the first peak block of the week begins at 18:00 on Sunday evening (= 01:00 UTC Monday), while 18:00 on Friday evening is already off-peak (= 01:00 UTC Saturday). Sunday-evening batch runs on the US west coast are the single most commonly mis-scheduled job we see. In IST and further east there is no such skew — local Monday morning is UTC Monday, and the local weekend is the UTC weekend.

Daylight saving moves the local windows, not the UTC ones. The UTC windows never change. Your local mapping does, twice a year:

• UK and Central Europe leave summer time on 25 October 2026. Both zones lose an hour of offset, so the peak blocks move an hour earlier in local terms — UK peak becomes 01:00–04:00 and 06:00–10:00 GMT, which pushes almost all of it out of the UK working day.
• US Pacific and US Eastern leave daylight time on 1 November 2026, moving the local windows an hour earlier too: Pacific peak becomes 17:00–20:00 and 22:00–02:00 PST.
• India, Singapore and Beijing do not observe daylight saving at all, so those three rows are correct year-round.

The practical takeaway: write your schedulers in UTC. Anything that computes peak windows from local time will silently drift by an hour twice a year.

How much of the week is actually off-peak?

Do the arithmetic and the picture is much less alarming than "prices double at peak" suggests.

Just under 80% of the week bills at the cheap rate. Peak is seven hours on five days — 35 hours out of 168. And the largest single off-peak stretch is enormous: from 10:00 UTC on any weekday straight through to 01:00 UTC the following day is 15 unbroken hours of off-peak. There is also a smaller two-hour gap at 04:00–06:00 UTC between the blocks.

If your workload is spread uniformly across the week and you do nothing at all, roughly 21% of it lands in peak — a blended premium of about 21% over the pure off-peak rate. That is the real number to beat, not 2×.

Which workloads should you move off-peak, and which shouldn't you?

The decision rule is one sentence: if no human is blocked on the response and a delay of a few hours costs you nothing, move it; otherwise leave it alone.

Worth moving: batch document processing (bulk summarisation, extraction, classification, PDF ingestion); nightly evaluation and regression suites, which are the perfect candidate because they carry large token volume, zero urgency, and are already scheduled; synthetic data generation, frequently the largest single line on a research team's bill; embedding and index backfills, and re-summarisation after a prompt change; non-blocking CI checks that post review comments asynchronously rather than gating a merge; and scheduled report generation whose deadline is "by tomorrow morning" rather than "now".

Not worth moving: interactive chat and support deflection — deferring a user-facing response to save money is a product decision disguised as a cost decision, and almost always the wrong one; IDE agents with an engineer sitting there waiting; anything under an SLA, real-time voice, or on-call triage; and merge-blocking CI, because holding a pull request for four hours to save a few dollars of tokens is not a trade any team should take.

Sanity-check the magnitude before you engineer anything. The off-peak saving on a million V4-Pro output tokens is $1.98. At a loaded engineering cost of around $80/hour, that is about 90 seconds of a developer's time. Scheduling pays when volume is large and the work is already automated. It does not pay when a person is waiting.

How do you actually shift work to off-peak hours?

Two patterns cover almost everything.

1. Schedule it in UTC

The 15-hour block from 10:00 UTC to 01:00 UTC is the obvious home for nightly jobs. Pin your scheduler to UTC explicitly rather than relying on the host's local zone — this is exactly the drift that daylight saving introduces.

# crontab — note the explicit CRON_TZ, and a buffer away from the boundaries
CRON_TZ=UTC

# Nightly evals: starts 11:00 UTC, one hour clear of the 10:00 boundary
0 11 * * 1-5   /usr/local/bin/run-eval-suite

# Weekend queue drain: every hour, Sat + Sun are entirely off-peak
0 *  * * 6,0   /usr/local/bin/drain-batch-queue

2. Defer-and-retry inside the worker

For queue-driven work, tag jobs as deferrable and have the worker requeue them when it wakes up inside a peak window. This handles the case where a job is enqueued by a user action at an awkward time.

from datetime import datetime, timedelta, timezone

# 01:00-04:00 UTC -> hours 1,2,3 ; 06:00-10:00 UTC -> hours 6,7,8,9
PEAK_HOURS = set(range(1, 4)) | set(range(6, 10))

def is_peak(t=None):
    t = t or datetime.now(timezone.utc)
    if t.weekday() >= 5:          # Sat=5, Sun=6 -> always off-peak
        return False
    return t.hour in PEAK_HOURS

def next_offpeak(t=None):
    t = t or datetime.now(timezone.utc)
    t = t.replace(minute=0, second=0, microsecond=0) + timedelta(hours=1)
    while is_peak(t):
        t += timedelta(hours=1)
    return t

def handle(job):
    if job.deferrable and is_peak():
        return job.requeue_at(next_offpeak())
    return job.run()

One honest caveat: DeepSeek's documentation does not state whether a request is priced by its start time or its completion time, and it says nothing about how a request straddling a boundary is treated. We could not verify either, so do not schedule to the minute. Leave a buffer of 30–60 minutes on both sides of a peak block, and do not kick off a long-running batch at 00:45 UTC hoping it finishes before 01:00.

A second lever stacks on top of this one and costs nothing to enable. DeepSeek's context caching on disk is, in its own words, "enabled by default for all users, allowing them to benefit without needing to modify their code." A cache hit on V4-Pro costs $0.022 versus $0.66 for a cache miss — roughly 3% of the miss price. Keeping the stable part of your prompt byte-identical at the front of every request is worth considerably more than moving the request two hours later. Cache lifetime is not guaranteed; the docs say an unused cache "will be automatically cleared, usually within a few hours to a few days." For the request mechanics, see our DeepSeek V4 API developer guide.

What does ignoring the clock actually cost?

Take a mid-sized production workload on V4-Pro: 500M cache-hit input, 100M cache-miss input and 100M output tokens per month. At pure off-peak rates that is $11.00 + $66.00 + $198.00 = $275/month.

The spread between the realistic scenarios is the useful signal. A team whose traffic is scattered across the week is overpaying by about a fifth — worth fixing, not worth a project. A team in Singapore, Shanghai or Bengaluru running everything inside local business hours is paying 75% more than necessary, and moving just the batch half of that workload into the 15-hour off-peak block recovers most of the difference.

Scale the ratios to your own volume; they hold at any size, because the discount is a flat 50% on every token type.

How does DeepSeek's off-peak discount compare to other providers?

Every major provider offers a way to pay less. DeepSeek is the only one that sells it against the clock rather than against turnaround.

Sources: Anthropic pricing docs, OpenAI pricing docs, Gemini Batch API docs.

Two structural differences matter. First, DeepSeek's discount is available to synchronous traffic. A batch API forces you to surrender turnaround to get the 50%; the clock discount does not, so a real-time request that happens to land at 12:00 UTC gets the cheap rate with no latency penalty. For anything interactive but timezone-flexible, that is strictly better than a batch API. Second, DeepSeek has no documented batch API — the clock and automatic caching are the only two levers, with no third "wait 24 hours, pay half" option to stack on top. The discount is easier to obtain but caps at 50%, whereas an Anthropic or OpenAI workload can stack batch and caching.

Choosing between the models rather than the hours is a separate question — the V4-Pro benchmark and capability breakdown covers where Pro earns its 3× premium over Flash, and the DeepSeek V4 complete guide covers the family end to end.

So what should you actually change?

In order of return on effort:

1. Find out where your traffic already sits. Bucket a week of request timestamps into the two UTC peak blocks. If you are a North American team, you will likely discover you are near-fully off-peak already and can stop here.
2. Move the obviously movable. Evals, synthetic data, backfills and nightly batch jobs into the 10:00–01:00 UTC block or onto the weekend. Pin the scheduler to UTC.
3. Check your prompt prefixes before you check the clock. Cache hits are worth roughly 30× more than the off-peak discount on input tokens. Fix caching first.
4. Leave interactive traffic alone. The saving is about 90 seconds of engineering time per million output tokens. It does not justify degrading a product experience.

If your team is APAC-based and running production volume, this is a real line item and worth an afternoon. If you are in the Americas, the clock is already working in your favour and caching is the lever that matters.

FAQ

When are DeepSeek's off-peak hours?

Off-peak is every hour that is not 01:00–04:00 or 06:00–10:00 UTC on a weekday. In practice that means 10:00–01:00 UTC and 04:00–06:00 UTC Monday to Friday, plus the whole of Saturday and Sunday. That works out at 133 of the 168 hours in a week, or 79.2%. The largest unbroken off-peak stretch is the 15 hours from 10:00 UTC to 01:00 UTC.

Is DeepSeek cheaper on weekends?

Yes. DeepSeek's pricing footnote states that peak hours apply "Monday through Friday" only, so every hour of Saturday and Sunday bills at the off-peak rate — 50% below peak. The weekend alone accounts for 48 of the week's 133 off-peak hours, which makes it the single easiest place to park large, non-urgent batch jobs.

How much do you save off-peak?

Exactly 50%. DeepSeek's documentation states that "off-peak rates are half of the peak rates," and the discount is uniform across cache-hit input, cache-miss input and output. On V4-Pro, output drops from $3.96 to $1.98 per million tokens and cache-miss input from $1.32 to $0.66. There is no additional volume or batch discount stacked on top.

Does off-peak pricing apply to cached input?

Yes. The 50% discount covers all three billed token types, including cache hits. V4-Pro cache-hit input is $0.044 per million at peak and $0.022 off-peak. Note that caching is by far the bigger lever regardless of the hour: a cache hit costs about 3% of a cache miss, so fixing your prompt prefixes matters more than moving the request.

Does off-peak pricing apply to DeepSeek V4-Flash?

Yes, and to deepseek-v4-flash-vision-exp as well. All three published models use the same peak/off-peak structure with the same 50% differential. V4-Flash output is $1.32 per million at peak and $0.66 off-peak; cache-miss input is $0.44 and $0.22. There are no model-level carve-outs in the published pricing.

What time zone are DeepSeek's peak hours in?

UTC, and they never shift for daylight saving. Your local mapping does: in August 2026, peak is 18:00–21:00 and 23:00–03:00 US Pacific, 07:00–11:00 and 02:00–05:00 in the UK, 11:30–15:30 and 06:30–09:30 in India, and 09:00–12:00 and 14:00–18:00 in Singapore and Beijing. Write schedulers in UTC to avoid twice-yearly drift.

Is my 9am job peak or off-peak?

It depends entirely on where you are. In US Pacific and US Eastern time, none of a 09:00–17:00 working day falls in a peak window — the whole American business day is off-peak. In the UK about 25% of it is peak, in Central Europe 38%, in India 56%, and in Singapore or Beijing 75%. APAC teams have the most to gain from scheduling.

Does DeepSeek offer a batch API like OpenAI and Anthropic?

Not in the published documentation. DeepSeek's two cost levers are the off-peak clock discount and automatic context caching. The upside is that the clock discount applies to synchronous requests, so you get 50% off without surrendering latency — unlike a batch API, which requires accepting up to 24 hours of turnaround for the same headline discount.