DeepSeek V4 split API pricing into 7 peak hours on 16 August 2026

Summary. At 16:00 UTC on 16 August 2026, DeepSeek moved its V4 API onto a two-tier clock. Peak hours are 01:00 to 04:00 and 06:00 to 10:00 UTC, 7 hours a day; every other hour is off-peak and bills at exactly half. On deepseek-v4-pro that is $1.32 per 1M cache-miss input tokens at peak against $0.66 off-peak, and $3.96 per 1M output tokens at peak against $1.98. deepseek-v4-flash is one third of Pro on every line: $0.44 and $1.32 at peak, $0.22 and $0.66 off-peak. Account concurrency is capped at 500 for Pro and 2500 for Flash. The change was announced in the DeepSeek-V4-Pro GA post dated 13 August 2026.

The headline is easy to read as a discount. It is not one. It is a clock, and the clock was drawn in UTC.

What actually changed

Three things shipped together on 13 August 2026, per the DeepSeek API change log:

The deepseek-v4-pro model reached general availability as DeepSeek-V4-Pro-0813, joining DeepSeek-V4-Flash-0731. Model names in the API did not change, so an existing integration picked up the new weights without a deploy. Context length is 1M tokens and maximum output is 384K on both models, per the Models and Pricing page.

The API gained native OpenAI Responses API support, aimed at Codex.

And the rate card was rebuilt around peak and off-peak windows. DeepSeek's own wording is that off-peak rates are "50% lower than peak, enabling more flexible workload scheduling". The pricing page carries the schedule in a footnote: "Peak hours are 01:00 - 04:00 and 06:00 - 10:00 UTC (all other hours are off-peak)."

The rate card, in one table

All figures are per 1M tokens, taken from the Models and Pricing page as published on 21 August 2026.

Two ratios matter more than the absolute numbers. Pro is exactly 3x Flash on every line, so the model choice is a clean multiplier. And a cache hit costs 1/30th of a cache miss on both models, at both times of day: $0.044 against $1.32 on Pro at peak. Cache behaviour is worth thirty times more to your bill than the time of day is.

Who the clock is actually for

Seventeen of the twenty-four hours are off-peak. That sounds generous until you convert the peak blocks into the working day of whoever is running the traffic.

For a team in Gurugram or Bengaluru, the second peak block sits from 11:30 to 15:30 IST, which is the middle of the working day. Interactive traffic, internal copilots, support deflection, anything a human is waiting on, all of it lands at peak. The first block, 06:30 to 09:30 IST, is quieter for most Indian offices.

For a US East Coast team the pattern inverts: both peak blocks fall between 21:00 and 06:00 EDT, so ordinary daytime usage is off-peak and it is the overnight batch jobs that get charged double. European teams get the worst of the second block, 08:00 to 12:00 CEST.

The practical read: the clock rewards batch work and punishes synchronous work, and which of those you have depends on where your users are. A nightly evaluation run, a document backfill, a re-embedding job or an offline agent sweep can be moved. A chat endpoint cannot.

The reasoning-effort trap

Here the documents disagree with each other, and the disagreement is billable.

The GA announcement and the change log both describe three effort levels. The change log says the thinking modes of V4-Pro and V4-Flash "now support three thinking effort levels: low / high / max", with advice to use low for simple tasks, high for daily agent tasks and max for complex ones.

The Thinking Mode guide publishes a different table. It accepts five requested values and maps them down:

So medium and xhigh are both accepted and both silently become high. A team that ships reasoning_effort: "xhigh" believing it bought more reasoning than high gets high, and pays for the reasoning tokens high produces. A team that ships medium expecting something cheaper than high also gets high. Neither call errors.

The same guide records a second default that costs money on its own: thinking mode is enabled by default, and the default effort is high. Chain-of-thought comes back in reasoning_content and is billed as output. At $3.96 per 1M output tokens on Pro at peak, an integration that never set an effort parameter has been buying high-effort reasoning on every call.

What this does to an agent loop

Agent workloads are where the two halves of this pricing meet badly.

The Responses API guide states the API is stateless: previous_response_id, conversation and store are all unsupported, and responses always carry store: false. Every turn re-sends the whole history as input. The same page lists prompt_cache_key and prompt_cache_retention as unsupported, so you cannot pin or extend a cache entry, and service_tier as unsupported, so there is no cheaper queue to ask for. Unsupported parameters are "silently ignored" rather than rejected, which means a client tuned against OpenAI will appear to work while doing none of what it was configured to do.

Caching is automatic, and the Context Caching guide explains the rule that decides your bill: because of sliding window attention, a request only hits the cache if it fully matches a persisted cache prefix unit. A prompt that mutates near the front, a system message carrying a timestamp, a rotating tool list, a per-request session identifier, drops the whole prefix from $0.044 to $1.32 per 1M on Pro. DeepSeek describes the cache as "best-effort" with no guaranteed hit rate, and says entries are cleared once unused, "usually within a few hours to a few days".

Tool-calling adds one more line to the invoice. The Thinking Mode guide is explicit that for requests carrying tools, reasoning_content must be passed back in full on every subsequent request, and a client that omits it gets a 400. Chain-of-thought that was billed as output on turn one is billed again as input on turns two, three and four.

Stack those together and a long agent run re-pays for its own reasoning every turn, at whichever rate the clock happens to be on when the loop starts. This is the same arithmetic that governs AI agent unit economics, and the peak split makes the start time of a run a cost variable rather than a scheduling detail.

Concurrency is the other cap

The Rate Limit and Isolation page sets account concurrency at 500 for deepseek-v4-pro and 2500 for deepseek-v4-flash. A request counts as one concurrent connection from send until the response completes, limits are counted per account rather than per API key, and exceeding them returns HTTP 429.

Expansion is free. DeepSeek publishes a capacity request form and states there is "no additional cost for capacity expansion". The catch arrives with the grant: for accounts with raised quotas, the per-user_id limit is also enforced at 500 for Pro and 2500 for Flash, with an empty identifier treated as its own user_id. A multi-tenant product that never sets user_id therefore funnels every tenant into a single bucket.

The obvious way to exploit the off-peak window, pushing deferred work into a burst at 10:00 UTC, runs straight into that ceiling. Off-peak capacity is half price, not unlimited. DeepSeek's error-code documentation is candid about the fallback it expects on a 429: "We also advise users to temporarily switch to the APIs of alternative LLM service providers, like OpenAI."

What to do this week

Instrument before you schedule. The Responses API returns input_tokens_details.cached_tokens and output_tokens_details.reasoning_tokens in usage; the Chat Completions path returns prompt_cache_hit_tokens and prompt_cache_miss_tokens. Log all four with a UTC timestamp on every call. Without that you cannot tell a peak-hour problem from a cache-miss problem, and they have very different fixes.

Set reasoning_effort explicitly on every code path. Do not ship medium or xhigh under the impression that they are distinct settings.

Freeze the front of your prompts. Move timestamps, session identifiers and rotating tool definitions to the end of the input so the stable prefix keeps matching a cache prefix unit.

Move what can be moved. Evaluation runs, backfills and re-embedding jobs belong outside 01:00 to 04:00 and 06:00 to 10:00 UTC. Interactive endpoints stay where your users are, and you price them at peak.

Set user_id per tenant now, before you request a concurrency increase, because the per-identifier limit only starts to bite after the grant.

What is still unknown

DeepSeek does not preserve its previous rate card on the pricing page, so the size of the increase against the pre-16-August prices cannot be verified from primary documentation. Treat any published comparison figure with suspicion unless it cites a snapshot.

The pricing page also warns that "Product prices may vary and DeepSeek reserves the right to adjust them", and the peak window itself is a footnote on that page rather than a contractual commitment. Nothing in the documentation says how much notice a change to the window would carry. If your scheduler hard-codes 01:00 to 04:00 and 06:00 to 10:00 UTC, it will keep running happily against a window that has moved.

Related reading: the DeepSeek V4 self-host against API break-even, the V4-Flash-0731 coding-agent and Codex path, and the wider open-weight self-host decision.

FAQ

How eCorpIT can help

eCorpIT builds and instruments LLM cost controls for teams running agent workloads in production, including token-level telemetry, cache-prefix design and scheduler changes that move deferrable work out of peak windows. Our senior engineering teams work as a CMMI Level 5 and ISO 27001:2022 certified organisation from Gurugram. Talk to us through /contact-us/ if your DeepSeek or multi-vendor inference bill has stopped matching your forecast.

References

1. DeepSeek API change log - entry dated 13 August 2026, V4-Pro GA and the pricing adjustment.

1. DeepSeek-V4-Pro GA release post, 13 August 2026 - peak and off-peak announcement, effective 16:00 UTC on 16 August 2026.

1. DeepSeek Models and Pricing - full peak and off-peak rate card, peak-hour footnote, context and output limits.

1. DeepSeek Rate Limit and Isolation - concurrency limits, user_id isolation, capacity expansion.

1. DeepSeek Thinking Mode guide - effort mapping table, default effort, reasoning_content handling with tools.

1. DeepSeek Context Caching guide - cache prefix units, full-match rule, persistence behaviour.

1. DeepSeek Responses API guide - parameter support matrix and usage fields.

1. DeepSeek Error Codes - HTTP 429 guidance.

1. DeepSeek Token and Token Usage - billing unit definition and offline tokenizer.

1. DeepSeek API quick start - base URLs and current model version strings.

Last updated: 21 August 2026.