If you're calling the DeepSeek API and your bill looked different this morning, you're not misreading it. As of 00:00 Beijing time today (August 17), DeepSeek's new peak/off-peak pricing is live.
Here's the short version, then the actual numbers, then what I changed in my own setup.
What changed
DeepSeek announced the update on August 13. The mechanism is simple: peak hours are 9:00–12:00 and 14:00–18:00 Beijing time, off-peak is everything else, and off-peak pricing is set at half the peak rate.
That sounds like a discount structure. It mostly is — relative to peak. But peak pricing itself is meaningfully higher than the price DeepSeek was charging just five days earlier, when the official V4 Pro model launched with aggressive introductory rates. So the honest way to describe this is: DeepSeek didn't get cheaper at off-peak hours, it got more expensive at peak hours, and off-peak is the smaller price to pay.
Here's the official pricing, straight from DeepSeek's own pricing page, for both V4 Flash and V4 Pro:
Two things jump out once you see the real numbers side by side. First, peak is exactly 2x off-peak across every single tier for both models — the "half price off-peak" framing is literally accurate, not marketing rounding. Second, and more relevant if you're building anything serious: v4-pro's concurrency limit is 500, five times lower than v4-flash's 2500. If you're getting throttled during peak hours, that limit — not just the price — might be the bigger constraint on your architecture.
Compared to V4 Pro's introductory pricing when it launched on August 12 (cache-hit input was priced at a small fraction of a cent), even off-peak cache-hit input today is roughly 6x higher, and peak is over 10x higher. Cache-miss and output pricing moved up too, just less dramatically. If your app leans on cache hits (repeated system prompts, shared context, RAG pipelines reusing chunks), that's the number to watch — not the headline "price change" itself.
Why "just move workloads off-peak" isn't a full fix
The advice you'll see everywhere — including from DeepSeek's own docs — is to schedule non-real-time jobs during off-peak hours. That's genuinely good advice for batch jobs, evals, and anything async.
It's less useful if your product serves live traffic. Peak hours are 9–12 and 14–18 Beijing time specifically because that's when Chinese business-hour demand spikes — but if your users are in other timezones, or your app is interactive, "wait until after 6 PM Beijing time" isn't an option you can hand to a user waiting on a response.
So for anything latency-sensitive, off-peak scheduling helps your batch/background work, but it doesn't solve the problem for your live traffic.
What I actually changed
Two things, neither of which is "leave DeepSeek."
I split workloads by urgency. Anything that can tolerate a delay (nightly summarization, embedding refreshes, eval runs) now explicitly targets off-peak windows. That's a scheduling change, not a code change — just a cron adjustment.
I stopped hardcoding a single provider's base URL. This is the part that actually mattered. My integration used to call DeepSeek directly:
client = OpenAI(
base_url="https://api.deepseek.com/v1",
api_key=DEEPSEEK_KEY,
)
Since DeepSeek's API is OpenAI-compatible, swapping providers is mostly a base_url and api_key change — if you've abstracted that config out instead of hardcoding it, which I hadn't. I fixed that first, independent of any specific provider:
client = OpenAI(
base_url=os.environ["AI_GATEWAY_BASE_URL"],
api_key=os.environ["AI_GATEWAY_API_KEY"],
)
Once that was config-driven, I could route different request types to whichever model/provider combination made sense, without a redeploy every time a pricing page changes.
For the gateway piece specifically, I've been testing RouteAI — it's an OpenAI-compatible proxy in front of DeepSeek, Qwen, Kimi, GLM, and a few others. I'm not going to claim it's the cheapest option out there — I haven't benchmarked every gateway or reseller, and pricing across this space changes often enough that any "cheapest" claim would probably be outdated by the time you read this. What it did solve for me: I'm no longer locked into rewriting integration code every time a single provider adjusts pricing with five days' notice. Worth evaluating yourself against your own traffic pattern rather than taking my word for it.
If you only do one thing today
Pull your last week of DeepSeek usage logs and check what percentage of your token volume falls inside the 9–12 / 14–18 Beijing-time windows. That number tells you whether this pricing change is a rounding error or a real line-item for you — before you make any architecture decisions based on it.
TL;DR: DeepSeek's peak/off-peak API pricing went live Aug 17 (Beijing time) — peak is 9–12 and 14–18, exactly 2x off-peak across every tier, but even off-peak is higher than the Aug 12 launch price, especially for cached input tokens (~6x off-peak, ~10x+ at peak). V4 Pro's concurrency limit (500) is also 5x lower than V4 Flash's (2500) — worth checking if you're hitting throttling. Batch/async work can shift to off-peak; live traffic mostly can't. Abstracting your base_url/api_key behind config (optionally through an OpenAI-compatible gateway like RouteAI) makes future pricing changes a config edit instead of a rewrite.
More on how I set this up: www.fastrouteai.com
Top comments (0)