DeepSeek now charges its hosted V4 API by time window. Peak rates apply Monday through Friday from 01:00–04:00 UTC and 06:00–10:00 UTC. Every other hour, including weekends, is off peak. Each off-peak token rate is half of its peak counterpart.
The simple part is the 50% discount. The useful part is deciding whether your workload can move. A nightly evaluation run may be an obvious candidate; an interactive coding agent is not. Before changing a scheduler, calculate the token mix, translate the UTC rule correctly, and put a deadline on every delayed job.
The rates below were checked against DeepSeek's official pricing page on September 3, 2026. DeepSeek says prices can change, so treat the page—not a copied calculator—as the current authority.
The price depends on more than the model
DeepSeek bills three categories per million tokens: input that hits cache, input that misses cache, and output. A budget based only on “input price” will be wrong whenever those two input buckets differ materially.
| Hosted model | Window | Cache-hit input | Cache-miss input | Output |
|---|---|---|---|---|
deepseek-v4-flash | Off peak | $0.007 | $0.22 | $0.66 |
deepseek-v4-flash | Peak | $0.014 | $0.44 | $1.32 |
deepseek-v4-pro | Off peak | $0.022 | $0.66 | $1.98 |
deepseek-v4-pro | Peak | $0.044 | $1.32 | $3.96 |
These are official USD-facing hosted API rates. They do not establish what a gateway, cloud marketplace, or self-hosted deployment will charge. Web and app access are also separate from API billing.
Flash is the lower-cost default for broad, measurable work. Pro deserves the higher rate only when it improves the completed task: fewer failed tool calls, less review, better acceptance results, or some other gain your own workload records. Moving an unsuitable job off peak does not make the model choice suitable.
A budget example with cache included
Use this formula for one model and one price window:
textcost = cache_hit_input / 1,000,000 × cache_hit_rate + cache_miss_input / 1,000,000 × cache_miss_rate + output / 1,000,000 × output_rate
Suppose a batch consumes 8 million input tokens, with 75% hitting cache, and produces 1 million output tokens. That gives 6 million cache-hit input tokens, 2 million cache misses, and 1 million output tokens.
On V4 Flash, the batch costs:
- off peak:
6 × $0.007 + 2 × $0.22 + 1 × $0.66 = $1.142; - peak:
6 × $0.014 + 2 × $0.44 + 1 × $1.32 = $2.284.
On V4 Pro, the same token mix costs:
- off peak:
6 × $0.022 + 2 × $0.66 + 1 × $1.98 = $3.432; - peak:
6 × $0.044 + 2 × $1.32 + 1 × $3.96 = $6.864.
Time-shifting halves the provider's token charge for this fixed workload. Increasing cache reuse is a different lever: it replaces expensive cache-miss input with much cheaper cache-hit input. The two savings can stack, but neither includes retries, gateway markup, taxes, quality regressions, latency, or human review.
That last boundary is easy to miss. If moving the batch causes a deadline breach and an engineer reruns it manually, the task may cost more even though the API line item is lower.
UTC is the schedule; US clock time is a view
Do not encode “9 PM Eastern” as the source of truth. The official rule is expressed in UTC, while US offsets change with daylight saving time and local calendar dates can differ from the UTC weekday.
On the September 3, 2026 check date, Eastern Daylight Time was UTC−4. The two peak windows appeared locally as 9:00 PM–midnight on the preceding calendar date and 2:00–6:00 AM. Pacific Daylight Time was UTC−7, making them 6:00–9:00 PM on the preceding date and 11:00 PM–3:00 AM across midnight. When standard time returns, each local clock interval moves one hour earlier.
That is why a timezone-aware scheduler should evaluate the two UTC intervals directly. If your platform supports an IANA zone but not a stable UTC cron, test the spring and fall transitions explicitly. A label such as “weekday evening” is not precise enough: the weekday belongs to the UTC rule, not necessarily to the local start date.
Log the request timestamp with offset, model ID, cache-hit input, cache-miss input, output, retries, final status, and calculated cost. A balance delta by itself cannot show whether a change came from price window, caching, output growth, or duplicate work.
A job earns the discount only if it can wait
A good off-peak candidate normally has all of these properties:
- its input is durable and can be replayed;
- processing is idempotent or guarded by a stable job key;
- it has a deadline later than the next off-peak window;
- success can be checked automatically;
- a bounded retry or dead-letter path already exists.
Offline classification, index enrichment, regression evaluations, non-urgent repository scans, and regenerable preprocessing often qualify. User-facing chat, incident response, payments, safety decisions, interactive agent turns, and tight-SLO automations usually do not.
For the middle ground, attach not_before and deadline_at to each job. Let the scheduler wait for off peak only while the deadline has enough slack. Once the slack is consumed, run immediately. This turns price into one scheduling signal instead of allowing it to override product behavior.
Idempotency matters because a delayed queue can redeliver. Record the provider request separately from the business-side commit, and deduplicate writes or notifications with a stable business key. Saving $1.142 on model tokens is irrelevant if a retry produces a duplicate customer action.
Price windows do not promise spare capacity
Off peak is a billing category, not an SLA. DeepSeek's rate-limit documentation currently lists account-level concurrency of 2,500 for Flash and 500 for Pro, with HTTP 429 when a limit is exceeded. Some accounts can request more capacity, but the public numbers do not guarantee latency or availability in either window.
Keep exponential backoff, a retry ceiling, queue age alerts, and a dead-letter path. Compare peak and off-peak runs over a full workweek using task success, p95 latency, retries, output length, and review minutes. Expand the schedule only when cost per accepted task improves—not merely cost per million tokens.
Choose model first, then execution time
A practical policy separates quality from timing. Send low-risk, automatically checked work to Flash first. Escalate only failed or genuinely difficult cases to Pro. Within each lane, delay the jobs that pass the deferrability test and keep urgent work immediate.
This produces four honest operating choices: Flash now, Flash later, Pro now, and Pro later. It is easier to reason about than a blanket “run DeepSeek at night” rule, and it lets logs reveal whether savings came from the model, the cache, or the clock.
If the next decision is provider selection rather than DeepSeek scheduling, compare the same workload and acceptance policy in the current LLM API price guide. Different providers can define caching, batches, retries, and billable output differently; sticker prices are not automatically comparable.
DeepSeek introduced the peak/off-peak schedule with the V4 pricing update that took effect at 16:00 UTC on August 16, 2026, according to its V4 Pro GA announcement. That date explains why older fixed-price guides disagree with today's table. It is also a reminder to keep rates in a reviewed configuration, not frozen forever in application code.
