Research-backed calculator guide

DeepSeek Peak vs Off-Peak Scheduler: Shift Workloads Without Breaking Freshness

Use DeepSeek's UTC pricing windows, token mix, cache behavior, deadlines, and freshness limits to decide which workloads can move off-peak without missing delivery requirements.

DeepSeek peak hours pricing: the rule a scheduler must encode

DeepSeek’s official pricing page publishes rates per 1 million tokens. The current table names deepseek-flash (DeepSeek-V4.1-Flash-1017) and deepseek-v4-pro. For Flash, the listed rates are $0.003 per 1M cache-hit input tokens, $0.15 per 1M cache-miss input tokens, and $0.60 per 1M output tokens off-peak. The matching peak rates are $0.006, $0.30, and $1.20. Pro is listed at $0.022, $0.66, and $1.98 off-peak, versus $0.044, $1.32, and $3.96 at peak. These are USD per 1M tokens, not per request. ^[1]

The schedule is expressed in UTC, so a scheduler should store UTC timestamps as its source of truth. A local-time display can help an operator, but it must account for daylight-saving changes. For example, the local time corresponding to a fixed UTC window can move by an hour when a region changes its offset. Hard-coding “cheap hours” in the team’s local timezone is an avoidable source of pricing errors.

The rate multiplier is simple: for the same token mix, an all-peak estimate is twice an all-off-peak estimate. A mixed schedule can be represented with a peak exposure ratio. If 30% of the workload’s billable tokens are processed at peak and 70% off-peak, the estimate is approximately the all-off-peak total multiplied by 1.30, provided the token mix is otherwise the same. This shortcut works because DeepSeek lists the same 2x relationship across the three model-usage categories. It is still an estimate; actual usage and provider billing records remain authoritative.

The schedule does not mean every request should wait. Interactive traffic has a latency requirement, and postponing it can damage a user experience. The practical target is the deferrable portion: backfills, offline summaries, evaluation runs, synthetic-data generation, report assembly, and other jobs with a completion deadline rather than an immediate response obligation.

A scheduler model: price window versus freshness window

Treat each job as a small record with these fields:

• Workload type: interactive, queueable batch, evaluation, backfill, or another declared class.
• Token mix: expected cache-hit input, cache-miss input, and output tokens per job or batch.
• Earliest start: the first time a job may begin, stored with a timezone and converted to UTC.
• Hard deadline: the latest acceptable completion time. This is not the same as a preferred start time.
• Freshness limit: the maximum age of the data, prompt, or source material when processing begins. A report may be due at 08:00 but still require data no older than 30 minutes.
• Estimated processing duration: a planning estimate for the complete batch, including expected provider waits and application overhead where known.
• Boundary and retry buffer: time held back so a retry or a request that crosses a pricing boundary does not invalidate the plan.
• Splitability: whether the workload can be divided into smaller units that run in more than one window.

The scheduler should first reject impossible jobs. If earliest start plus estimated duration plus the boundary buffer is after the hard deadline, no timing trick fixes the job. If freshness requires newly collected input, a long wait may be invalid even when the final deadline has room. If the work is interactive, the scheduler should normally mark it “run now” and leave cost optimization to model choice, caching, or prompt reduction.

For a feasible job, generate candidate intervals. A candidate is valid only if it starts after the earliest start, finishes before the deadline, stays within the freshness limit, and leaves the safety buffer. Label each candidate as peak or off-peak by checking every part of the planned processing window against the UTC schedule. For a conservative budget, if a request can cross a boundary and the application cannot attribute usage precisely, price the affected portion at the higher rate or add a separate boundary-risk line.

A splitable batch can use multiple off-peak intervals. A non-splitable job needs one contiguous interval long enough for completion. This distinction matters on weekdays because the 04:00–06:00 UTC gap between the two peak periods is off-peak, but it may be too short for a large batch. A scheduler that only checks the start timestamp can recommend an interval that becomes peak-priced before completion. The unit of analysis should match the provider’s billing behavior and the application’s usage records.

Worked cost example: a deadline-aware DeepSeek Flash batch

Assume a weekly report batch uses DeepSeek Flash and has the following estimated token mix per run:

• 20M cache-miss input tokens
• 5M cache-hit input tokens
• 2M output tokens
• USD billing per 1M tokens
• One run completes in 40 minutes
• A 10-minute boundary and retry buffer is required

Using the rates above, the estimated all-off-peak cost is:

(20 × $0.15) + (5 × $0.003) + (2 × $0.60) = $4.215 per run

The all-peak estimate is double that amount, or $8.430 per run. The difference is $4.215 for one run before any infrastructure, queueing, engineering, or delay cost. If the same batch runs 14 times in a planning period, the all-off-peak estimate is $59.01, while an all-peak estimate is $118.02. These are planning figures based on stated token volumes, not a vendor quote or an invoice prediction.

The following original table makes the scheduling decision inspectable. It assumes the run duration and buffer above, and it uses UTC for eligibility. The displayed local labels are deliberately omitted because the pricing rule is UTC-based and local daylight-saving conversions vary.

The flexible example has room after the second weekday peak window ends at 10:00 UTC, so it can be placed later in the off-peak period if its freshness limit allows. The tight-deadline example cannot be made cheaper merely by labeling it “batch.” It needs a deadline change, a shorter job, splitting, a different model, or an explicit peak-cost budget.

The split example illustrates a useful budgeting shortcut. If each unit has the same token mix and 40 of 100 units are processed at peak, the total is the all-off-peak total multiplied by 1.40. If peak and off-peak units have different token distributions, calculate them separately rather than applying one blended ratio.

For a broader token decomposition, compare the AI token cost calculator with the LLM cost calculator. Those internal tools help isolate input and output assumptions; this scheduler method adds deadline feasibility and peak exposure.

Cache hits change the economics, not the schedule

DeepSeek says context caching is enabled by default. A later request can receive a cache hit when it fully reuses a persisted cache-prefix unit; the API exposes prompt_cache_hit_tokens and prompt_cache_miss_tokens in usage. The cache is best effort, and the documentation does not guarantee a 100% hit rate. ^[2]

That makes the cache ratio an input to the cost model, not a promise. Stable system instructions and reusable reference material may produce hits, but changing the prefix can produce misses. A scheduler should measure cache-hit and cache-miss counts from representative usage, then apply the corresponding rates. Do not multiply every input token by the cheaper cache-hit price just because a prompt looks similar.

Timing and caching are independent levers. Moving an uncached batch off-peak can halve the model-token rate. Improving reuse can reduce the input portion in either pricing period. A reliable plan shows both effects separately so a team can see whether a proposed change saves money because it waits, because it reuses context, or because it reduces tokens.

Concurrency, retries, and freshness limits

A cheap window is not useful if a queue cannot drain before the deadline. DeepSeek’s rate-limit documentation lists account-level concurrency limits of 2,500 for deepseek-flash and 500 for deepseek-v4-pro; exceeding the applicable limit can produce HTTP 429 responses. ^[3] A scheduler should therefore distinguish “off-peak time available” from “off-peak capacity available.”

When estimating a batch, include expected retry behavior and the boundary buffer. A retry may consume additional tokens and may run in a different pricing period. The safest ledger records each attempt’s timestamp, model, token usage, cache-hit and cache-miss counts, and final status. If your system retries automatically, use an idempotency or deduplication key at the application layer so a pricing optimization does not create duplicate business outputs.

Freshness is another hard constraint. A source-refresh job can be shifted only until its input becomes stale. For example, an evaluation tied to a daily dataset can run during the next off-peak window; a fraud-review feature whose inputs change every few minutes may not. The scheduler should return “peak required” when freshness and deadline constraints eliminate every cheaper candidate. That is a useful decision, not a failure.

If your workflow uses DeepSeek Search or Fetch, keep those meters separate from model-token estimates. DeepSeek documents Search and Fetch as standalone APIs billed per 1,000 successful requests at $0.75 each, and notes that server-side tool calls through certain integrations have a billing start date of November 1, 2026. ^[1] The Search and Fetch guide also says the charge is per successful request, not per returned result or token, and lists separate QPS limits. ^[4] Add those requests to the workload ledger; do not hide them inside an input-token assumption.

A practical operating policy

Use three scheduling classes. Run now covers interactive or freshness-critical work. Schedule if feasible covers jobs with a deadline and enough slack to move to off-peak. Split and drain covers large queueable workloads that can be divided while preserving ordering, deduplication, and output quality. Re-evaluate the class when the prompt, model, traffic profile, or deadline changes.

Measure the result after each cycle. Compare planned peak exposure with actual request timestamps and usage fields. Record the expected and realized cache-hit ratio. Reconcile the estimate with provider usage rather than treating the calculator as an invoice. If the observed peak share is higher than planned, check timezone conversion, daylight-saving transitions, queue backlog, retries, and jobs that crossed a boundary.

Finally, compare timing against alternatives. A job that cannot be delayed may still be cheaper on another model or provider, but that is a separate quality and latency decision. Use Model pricing comparison to compare equivalent token mixes, and keep model changes separate from the off-peak experiment so the savings source is measurable.

FAQ

What are DeepSeek’s peak hours?

The official pricing page lists 01:00–04:00 and 06:00–10:00 UTC, Monday through Friday, excluding Chinese public holidays. Other hours are off-peak, including weekends and Chinese public holidays in full. ^[1] Convert these UTC windows for display, but keep UTC as the scheduling authority.

How much cheaper is DeepSeek off-peak?

The listed off-peak rate is half the matching peak rate for cache-hit input, cache-miss input, and output tokens. An identical token mix that costs $4.215 entirely off-peak would cost an estimated $8.430 entirely at peak in the worked Flash example. The difference excludes infrastructure and delay costs.

Should every batch job wait for off-peak?

No. Wait only when the job’s freshness limit, hard deadline, processing duration, capacity, and retry policy leave a feasible candidate window. A deadline that falls before the next off-peak interval should be priced at peak or redesigned. Interactive requests should generally run when the user needs them.

Does a cache hit make a peak request off-peak?

No. Cache status and time-of-day pricing are separate dimensions. A cache-hit input token still uses the cache-hit rate for the current peak or off-peak period. DeepSeek describes caching as best effort and exposes hit and miss counts in usage, so use observed counts when available. ^[2]

How should I handle a job that crosses 04:00 or 10:00 UTC?

Do not assume the whole job receives the cheaper rate from its start timestamp. Split the work into requests where possible, record request and usage timestamps, and use a boundary buffer when planning. If your billing attribution cannot resolve the boundary, use the higher-rate assumption for the uncertain portion and mark the result as conservative.

What if the off-peak window is available but the queue is full?

Treat capacity as a feasibility constraint. DeepSeek documents account-level concurrency limits and possible HTTP 429 responses when the limit is exceeded. ^[3] Reduce parallelism, spread the queue across a longer off-peak interval, split the batch, or budget for another feasible window. A lower token rate does not remove a throughput bottleneck.

Limitations and assumptions

This guide uses the official rates and schedule read on November 2, 2026. Provider pricing, model names, billing rules, limits, and integration treatment can change; re-check the official documentation before committing a production budget. The examples assume the stated token volumes, a 40-minute run, a 10-minute safety buffer, USD per 1M tokens, and successful completion. They do not include application compute, storage, queue infrastructure, engineering time, opportunity cost of delay, quality regressions, failed attempts, or taxes.

The scheduler method is a planning framework, not a guarantee that a request will be admitted, complete in the estimated duration, or produce a cache hit. Actual usage records and the provider invoice are the final reconciliation sources. Search volume, keyword difficulty, CPC, traffic, rankings, and revenue outcomes are not estimated here.