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

DeepSeek's API charges different rates for the same tokens depending on the time of day in Beijing when the request is received. The peak hours in Beijing, from Monday to Friday, 09:00-12:00 and 14:00-18:00, are seven hours a day, accounting for roughly a fifth of the week. All other times, including nights, weekends, and Chinese public holidays, are considered off-peak and cost half of the peak rate.

The author discovered this pricing structure the hard way after scheduling a reindex job to run at 3 a.m. Eastern, which corresponds to 15:00 Beijing time, right in the middle of the second peak window. Consequently, the expensive peak rates were applied to the job, leading to unexpected costs.

To avoid this costly mistake, the author recommends scheduling jobs using the timezone of the vendor billing, such as "TZ = Asia/Shanghai" in the crontab. This ensures the job runs during off-peak hours, significantly reducing costs. Additionally, long-running jobs and retry queues can also fall into peak hours, so adjusting the scheduling accordingly is crucial.

The author emphasizes that caching has a much larger impact on costs compared to scheduling. An off-peak cache hit costs only ¥0.15 per million input tokens, while a peak cache miss costs ¥9. The two factors multiply, making caching 60 times more effective in reducing expenses when combined. However, if only one factor can be optimized, stabilizing the prompt prefix first and then addressing the cron scheduling is advised, especially when dealing with vendors that charge by time of day.

Most APIs, however, do not vary prices throughout the day, so it's essential to verify the pricing structure before implementing scheduling logic.