DeepSeek's API charges two different prices for the same tokens. Which one you pay depends on what time it is in Beijing when the request lands.
That is the whole bug. It took me an embarrassingly long time to find, because nothing in our code was wrong.
Beijing time, Monday through Friday, 09:00-12:00 and 14:00-18:00 are peak hours. Everything else is off-peak: nights, weekends, Chinese public holidays. Off-peak is exactly half of peak.
For V4 Pro, per million tokens, in CNY:
| Off-peak | Peak | |
|---|---|---|
| Input, cache miss | ¥4.5 | ¥9 |
| Input, cache hit | ¥0.15 | ¥0.30 |
| Output | ¥13.5 | ¥27 |
Peak is seven hours a day on weekdays, about a fifth of the week. So most of the time you are already in the cheap band by accident, which is why nobody notices the rule until they land in the other fifth.
Our reindex job ran at 3 a.m. Eastern. That felt like the safe, nobody-is-awake slot.
3 a.m. EDT is 07:00 UTC. That is 15:00 in Beijing, the dead center of the second peak window.
Converted out of Beijing time, the two peak blocks land here:
| Zone | Block 1 | Block 2 |
|---|---|---|
| Beijing (UTC+8) | 09:00-12:00 | 14:00-18:00 |
| UTC | 01:00-04:00 | 06:00-10:00 |
| US Eastern (EDT) | 21:00-24:00 prev day | 02:00-06:00 |
Read the last row again if you schedule on a US clock. The classic overnight maintenance window, roughly 2 a.m. to 6 a.m. Eastern, is peak from end to end.
Ordinary East Coast business hours, 6 a.m. through 9 p.m., are all off-peak. So the cheap slot is the middle of your working day and the expensive one is the middle of your night.
There is a day-boundary version of the same trap. Beijing Monday morning is Sunday evening Eastern, so a "start of week" full recompute kicked off Sunday night bills at peak from its first request.
One line at the top of the crontab:
TZ=Asia/Shanghai
0 12 * * 1-5 /usr/local/bin/reindex
Write the schedule in the timezone of whoever is billing you. For systemd the equivalent is an explicit timezone on the timer:
[Timer]
OnCalendar=Mon-Fri 12:00
Timezone=Asia/Shanghai
Do not hardcode the converted UTC times instead. US daylight saving shifts twice a year, so a hand-converted "02:00 UTC" quietly becomes wrong every spring and autumn. Pinning the timezone makes the conversion someone else's problem.
Two things I had to fix after the cron itself.
Long jobs straddle the boundary. A job starting at 11:00 Beijing and running two hours pays off-peak for one hour and peak for the next. Starting it an hour later puts the whole run in the cheap band.
Retry queues quietly move work into peak. Failures pile up overnight and get drained when someone comes in and restarts the consumer, which is exactly the expensive window. That cost never surfaces in a dashboard grouped by model, because the model did not change.
Moving a job out of peak saves half. Caching is the bigger multiplier: an off-peak cache hit is ¥0.15 per million input tokens against ¥9 for a peak cache miss, a spread of 60x once both axes stack.
The two multiply, so you do not have to choose. But if you only have time for one, stabilize your prompt prefix first and move the cron second.
This only applies where the vendor actually prices by time of day. Most APIs charge the same around the clock, so check before you build scheduling logic around it.
Prices here are from DeepSeek's official pricing page, checked 21 September 2026. The longer Chinese version, with the full timezone table, is on my own price-comparison site: https://www.llmabacus.com/articles/off-peak-pricing-timezone-trap
I built that site because price tables go stale without ever throwing an error.