Our 3 a.m. batch job was running at Beijing's afternoon peak rate

A developer documented how DeepSeek's time-of-day API pricing caused a nightly reindex job scheduled for 3 a.m. US Eastern to run during Beijing peak hours, where token rates are double the off-peak price. The writeup maps DeepSeek's peak windows (09:00-12:00 and 14:00-18:00 Beijing time on weekdays) onto UTC and US Eastern clocks, showing the classic 2-6 a.m. Eastern maintenance window falls entirely in peak, and recommends pinning the crontab or systemd timer to Asia/Shanghai rather than hardcoding converted UTC times. The developer also notes that long jobs straddling the boundary and retry queues drained during business hours can silently push work back into the expensive band.

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 https://www.llmabacus.com/articles/off-peak-pricing-timezone-trap I built that site because price tables go stale without ever throwing an error.