DeepSeek Peak vs Off-Peak Pricing: A Routing Experiment

AIAPIDeepSeekCost
Read in other languages:中文

DeepSeek's list price changes twice on a normal weekday. The same model, the same tokens, and the same cache behavior can cost twice as much at 10:00 Beijing time as they do at 20:00. That is a scheduling problem before it is a model-selection problem.

Short answer: Peak hours are weekdays 09:00–12:00 and 14:00–18:00 Beijing time, excluding Chinese statutory holidays. Everything else is billed at half the peak rate. In the workload below, the same 200M input and 40M output tokens cost ¥887.36 at peak and ¥443.68 off-peak. If you would rather not build the routing layer yourself, create a Tokuse account and use one OpenAI-compatible endpoint for both DeepSeek models; the base URL is https://tokuse.com/v1.

The official schedule

DeepSeek publishes prices in CNY per million tokens. The current Flash and V4 Pro prices are:

Model Token type Peak Off-peak
deepseek-flash Cache-hit input ¥0.04 ¥0.02
deepseek-flash Cache-miss input ¥2.00 ¥1.00
deepseek-flash Output ¥8.00 ¥4.00
deepseek-v4-pro Cache-hit input ¥0.30 ¥0.15
deepseek-v4-pro Cache-miss input ¥9.00 ¥4.50
deepseek-v4-pro Output ¥27.00 ¥13.50

The peak window is Monday to Friday, 09:00–12:00 and 14:00–18:00 Beijing time. Weekends and Chinese statutory holidays are off-peak all day. The 12:00–14:00 lunch break is also off-peak.

The workload I priced

I used a modeled workload rather than measured production traffic, so the arithmetic is reproducible:

  • 200M input tokens and 40M output tokens per month.
  • 40% of input tokens hit the prompt cache.
  • 80% of input and output tokens go to Flash, 20% to V4 Pro.
  • No retries, no failed requests, and no image or audio tokens.

That splits into:

Model Cache-hit input Cache-miss input Output
deepseek-flash 64M 96M 32M
deepseek-v4-pro 16M 24M 8M

At the official list price, the monthly cost is:

Model Peak Off-peak
deepseek-flash ¥450.56 ¥225.28
deepseek-v4-pro ¥436.80 ¥218.40
Total ¥887.36 ¥443.68

The 50% difference comes from the clock, not from a cheaper model or a clever prompt. Moving the same workload outside the peak window is the largest single lever in this model.

Where the money actually goes

The output tokens dominate the off-peak bill. Flash output costs ¥128 for 32M tokens, and Pro output costs ¥108 for 8M tokens. Together they are ¥236 of the ¥443.68 off-peak total. Cache hits are cheaper, but they are not the main story: at 40% cache hits, the saving versus charging every input token at the cache-miss rate is about ¥62.72 for Flash and ¥69.60 for Pro at off-peak rates.

That matters because cache hit rates are easy to overestimate. Stable system prompts and reused RAG prefixes can reach high hit rates. Long-tail user prompts often land around 30–40%, and some workloads never hit the cache at all. If your measured hit rate is 20% instead of 40%, rerun the numbers before you promise a saving.

The routing rules that survived

I would keep four rules, and none of them require a new model.

  1. Move batch jobs outside 09:00–12:00 and 14:00–18:00 Beijing time. Overnight indexing, bulk classification, and report generation are the easiest workloads to shift.
  2. Keep interactive traffic on Flash by default. Escalate to V4 Pro only when an evaluation step fails, not because the request looks important.
  3. Keep the prompt prefix stable. Put the changing user question at the end and the fixed system prompt or retrieved document at the front. A timestamp at the top of every request destroys the cache.
  4. Do not move latency-sensitive traffic just to catch the discount. Measure p95 latency before and after the change; a cheaper request that misses a product deadline is not cheaper.

The check I use

This Python function uses only the standard library. It answers two questions: is the current time in a peak window, and what does a token mix cost at that time?

from datetime import datetime
from zoneinfo import ZoneInfo

PRICES = {
    "deepseek-flash": {
        "peak": {"cache_hit": 0.04, "input": 2.0, "output": 8.0},
        "off_peak": {"cache_hit": 0.02, "input": 1.0, "output": 4.0},
    },
    "deepseek-v4-pro": {
        "peak": {"cache_hit": 0.30, "input": 9.0, "output": 27.0},
        "off_peak": {"cache_hit": 0.15, "input": 4.5, "output": 13.5},
    },
}


def is_peak(now: datetime) -> bool:
    local = now.astimezone(ZoneInfo("Asia/Shanghai"))
    if local.weekday() >= 5:  # Saturday or Sunday
        return False
    hour = local.hour
    return 9 <= hour < 12 or 14 <= hour < 18


def cost(model: str, cache_hit: int, cache_miss: int, output: int, peak: bool) -> float:
    price = PRICES[model]["peak" if peak else "off_peak"]
    return (
        cache_hit * price["cache_hit"]
        + cache_miss * price["input"]
        + output * price["output"]
    ) / 1_000_000


if __name__ == "__main__":
    tz = ZoneInfo("Asia/Shanghai")
    print(is_peak(datetime(2026, 11, 10, 10, 0, tzinfo=tz)))  # True, Tuesday
    print(is_peak(datetime(2026, 11, 10, 13, 0, tzinfo=tz)))  # False, lunch
    print(is_peak(datetime(2026, 11, 14, 10, 0, tzinfo=tz)))  # False, Saturday
    print(cost("deepseek-flash", 64_000_000, 96_000_000, 32_000_000, False))

The last line prints 225.28, which matches the Flash off-peak figure above.

What the model does not cover

The peak check does not know about Chinese statutory holidays. A weekday holiday will be treated as peak, which overstates the cost. If that matters, add a holiday calendar and treat those dates as off-peak.

The prices are the official CNY list price at the time of writing. They can change. The cache-hit assumption is the part I would measure first; a 40% hit rate is a modeled input, not a guarantee. Model behavior also differs between Flash and Pro, so a routing rule that saves money but changes the answer quality is not a saving.

The arithmetic is easy to reproduce. Start with your real token counts, run them through the DeepSeek cost calculator, then check whether the batch portion of your workload can move outside the peak window. The integration guides for Continue, Cline, LangChain, Cursor, Dify, Open WebUI, and the OpenAI Node.js SDK all use the same base URL, so the routing change stays outside application code. Product updates are recorded in the changelog.