Verification Checklist

  • ✓Can your own batch data processing, fine-tuning, or offline reporting jobs — ones that don't need an instant response — be scheduled to run during Beijing off-peak hours (overnight)
  • ✓Does your scheduling script check the correct Beijing time (UTC+8) rather than your server's local timezone or raw UTC when deciding whether a call falls in the peak window
  • ✓If a job straddles the peak/off-peak boundary, is billing based on when the request was submitted or when it was actually processed — and have you built in a safety margin instead of submitting right at the cutoff
  • ✓Before applying for a higher concurrency/rate-limit tier, have you already gathered your business license and corporate bank account details, rather than assuming a bigger top-up automatically raises your concurrency
  • ✓Does the tier shown on your actual bill for this call match what the provider's current official pricing page states, rather than what you remember from an older price list

1. The phenomenon: the same model, two different prices

If you've called DeepSeek's or a similar Chinese provider's API recently, you may have noticed two distinct rates showing up on your bill: calling the same model during Beijing weekday daytime hours (say, 9am–noon or 2pm–6pm) now costs noticeably more than calling it late at night or during other off-peak windows. This isn't a glitch or a limited-time promotion — it's a formal shift to "peak/off-peak pricing," where the same endpoint and the same model automatically switch price tiers depending on the clock.

2. The underlying logic: daytime compute is genuinely scarce, and price is the routing lever

The logic isn't complicated: the GPU capacity behind model inference is a finite resource. Daytime is when enterprise and developer traffic is densest, so the compute pool is most likely to hit its ceiling; overnight through early morning, call volume drops sharply and a large chunk of capacity sits idle. Rather than let that idle capacity go to waste, providers use a lower price to attract the workloads that "aren't in a rush" to move over voluntarily — this is fundamentally traffic routing via price, not a simple discount. That's also why peak pricing isn't just "no discount" — under many of the newer pricing schemes, peak-hour rates themselves have gone up at the same time, and the off-peak discount is the part of the new scheme that's actually a good deal.

3. The specifics: DeepSeek's time windows and the actual price gap

Take DeepSeek's officially published pricing as an example: peak hours are Beijing time, Monday through Friday, 9:00–12:00 and 14:00–18:00; every other hour, including all of the weekend, counts as off-peak, and off-peak rates are fixed at half the peak rate. On specific numbers, for one of its model tiers, cache-miss input pricing runs roughly ¥1.5 per million tokens off-peak versus roughly ¥3 at peak, and output pricing runs roughly ¥4.5 per million tokens off-peak versus roughly ¥9 at peak. Exact figures vary by model tier and change over time on the provider's side — check the official pricing page before you rely on any specific number, including the ones in this article.

4. How this compares to overseas batch-API discounts: the trigger condition is what differs

A related article on this site, "Why Your AI API Bill Costs More Than the Per-Token Math," covers how OpenAI, Anthropic and other overseas providers offer a similar "trade flexibility for a lower price" mechanism through their batch APIs — bundling non-real-time work into a batch submission typically earns a meaningfully lower rate than a synchronous call. Both mechanisms share the same underlying economics: providers give a discount in exchange for more scheduling flexibility over their compute. But the trigger condition is completely different. An overseas batch-API discount depends on which endpoint you call — a batch submission versus a synchronous request — regardless of what time it is, and the job itself has to tolerate a delayed response. A Chinese off-peak discount depends on what time your call happens; the endpoint is still an ordinary synchronous call, and the price simply switches on the clock. In short: one is about picking the right endpoint, the other is about picking the right time, and you can't apply the same optimization playbook to both.

5. Enterprise verification is a separate matter from off-peak pricing

Here's a point that trips up a lot of developers: it's easy to assume that once an account is verified or has topped up enough credit, higher concurrency or rate limits kick in automatically — and from there, to assume off-peak pricing and account tier are bundled into one system. They aren't. Off-peak pricing depends purely on when you call the API; it has nothing to do with whether your account has completed enterprise verification or what concurrency tier it's on. Getting a higher concurrency allowance or a higher rate-limit tier typically requires going through a separate enterprise qualification review — and that, in turn, is not the same thing as the phone-number verification covered in a separate article on this site about getting started with domestic Chinese AI tools. Phone verification is the baseline requirement to open an account at all; enterprise qualification review is the advanced step for requesting higher concurrency. These are three separate tiers of requirements, and completing one doesn't mean the other two are automatically settled.

6. Which tasks are worth moving to off-peak hours, and how to schedule them in code

Tasks worth migrating to off-peak hours share one trait: they don't need a response within seconds or even minutes. Typical examples include batch cleaning and structuring of historical data (bulk-tagging old support tickets, say), model fine-tuning or continued-training runs, scheduled daily/weekly/monthly report generation, bulk document summarization or translation, and offline corpus labeling or quality evaluation. These jobs usually run for minutes to hours regardless, and nobody's watching the clock for exactly when they start — which makes them a natural fit for the overnight window. In practice, the simplest approach is to use your platform's built-in scheduler (cron on Linux, Task Scheduler on Windows, or a library like APScheduler in Python) to kick jobs off within the Beijing 0:00–8:00 window, while also having your code independently verify the current time against Beijing time (UTC+8) rather than the server's own local timezone. If a job looks likely to run past the peak-hour cutoff, build in a 30–60 minute buffer rather than submitting requests right up against the boundary, so a straggling request doesn't get billed at the peak rate.

7. What enterprise verification paperwork typically involves before requesting higher concurrency

If your usage has grown to the point where you need a higher concurrency or rate-limit tier, most Chinese model providers' enterprise verification process asks for: a scan or photo of your business license (the unified social credit code certificate), corporate bank account details (some platforms require a small verification deposit to a corporate account), identification for the person handling the application plus a letter of authorization where required, and sometimes a written description of your intended use case. These are usually submitted through a dedicated "enterprise verification" or "tier upgrade" entry point in the platform's developer console, and review can take anywhere from a few business days to about two weeks depending on the provider — start the paperwork well before your usage actually hits the existing concurrency ceiling, rather than scrambling once production traffic is already blocked.

8. Summary

The "cheaper at night, pricier by day" pattern in Chinese model APIs comes down to providers using price as a lever to route non-real-time workloads toward idle overnight GPU capacity — economically similar to overseas batch-API discounts, but triggered by time of day rather than by which endpoint you call, so the two optimization strategies aren't interchangeable. Enterprise verification and concurrency tier upgrades are a separate compliance and quota system that has nothing directly to do with off-peak pricing. Moving batch-style workloads to off-peak hours and getting your enterprise paperwork ready ahead of time are two concrete, separately actionable steps.