DeepSeek Peak Pricing Calculator

The DeepSeek Peak Pricing Calculator turns token estimates into a practical cost. Choose V4 Flash or V4 Pro, enter input and output tokens, and set an estimated cache hit ratio. For a single request, it applies the rate in effect at your selected time and shows the same workload at both peak and off-peak prices.

Monthly mode uses average tokens, requests per day, billing days, and the share of traffic expected during peak hours. It calculates the two contributions separately, then compares the result with an all-off-peak schedule. Estimates use US dollars per 1 million tokens. They are planning figures, not a replacement for API usage records or a DeepSeek bill.

DeepSeek lists two daily peak windows: 01:00–04:00 UTC and 06:00–10:00 UTC. The other 17 hours are off-peak. At the boundaries, 01:00 and 06:00 are peak; 04:00 and 10:00 begin off-peak pricing. The underlying schedule always stays in UTC.

Peak and off-peak billing takes effect at 16:00 UTC on August 16, 2026. The live status classifies time in UTC, then presents the current time and next switch in your selected IANA timezone. This accounts for daylight saving time where it applies. If detection fails, the calculator uses UTC and tells you.

The official table covers deepseek-v4-flash (DeepSeek-V4-Flash-0731) and deepseek-v4-pro (DeepSeek-V4-Pro-0813). Each has separate cache-hit input, cache-miss input, and output rates. Under the new schedule, every off-peak rate is half of its matching peak rate. V4 Flash costs less across all three categories, but quality, latency, and workload needs still belong in a production decision.

These figures apply to calls billed directly by DeepSeek. A cloud marketplace, gateway, reseller, or aggregator may set a different markup, currency, discount, or schedule. Use that provider's documentation for third-party traffic.

DeepSeek's context caching is enabled by default. A later request can receive a cache hit when it fully reuses a persisted prefix; other input is billed as a cache miss. Output tokens have their own price and are not affected by the input cache ratio.

The calculator splits input using the ratio you enter. A 60% ratio treats 60% as cache hits and 40% as misses. This is an estimate, not an API switch. Stable prefixes and multi-turn conversations may improve reuse, while frequently changing content may not. For a tighter forecast, use representative cache hit and miss counts from real API traffic.

Start with a normal request: average input, average output, and the cache behavior you see in practice. Apply daily volume and billing days, then choose a peak traffic share. If calls are evenly spread across the day, 7 of 24 hours are peak, so 29.2% is a useful default—not a universal assumption.

Interactive products may follow their audience's working day, while global systems can be flatter. Measure your distribution with broad, non-identifying time buckets. Test expected volume, a growth case, and a cache-miss-heavy case to understand the range your budget may need to absorb.

Moving work from peak to off-peak cuts the published token rate by 50%. The savings card compares your selected mix with the same volume entirely off-peak. It does not count engineering time, queueing infrastructure, or the cost of delay.

Treat the result as an upper bound for the traffic represented by your inputs. Customer-facing and time-sensitive work may need to run immediately. Better candidates have a completion deadline but no need to start at once.

Batch evaluation, test generation, offline summarization, search indexing, report drafting, classification, and nightly code analysis are often queue-friendly. A scheduler can hold jobs for an off-peak window and retry safely. Keep user-visible work on the path that meets its latency target, then optimize the flexible remainder.

Before moving a job, record its deadline, token profile, and failure policy. Schedule against UTC because DeepSeek defines the windows there. Recalculate after a model change, prompt redesign, or shift in cache performance. Reducing tokens on every request can matter as much as rescheduling a limited batch.