Small correction to the DeepSeek comment in packages/shared-python/shared/services/ai/token_costing.py:
# DeepSeek official (peak/off-peak since 2026-08-16 16:00 UTC).
# Defaults use OFF-PEAK; peak rates are 2x (01:00-04:00 & 06:00-10:00 UTC).
Those windows only apply on weekdays:
Peak hours are 01:00 - 04:00 and 06:00 - 10:00 UTC, Monday through Friday (all other hours are off-peak).
The Chinese version of the same footnote pins the timezone rather than the hours: 「高峰时段为北京时间周一至周五 9:00 - 12:00、14:00 - 18:00」, which is why the weekday clause is easy to lose when reading only the English page.
So peak is 35 hours a week, not 49. The numbers here are right and the off-peak default is the good call — it just gets better: the documented undercount now covers 21% of the week instead of 29%.
# DeepSeek official (peak/off-peak since 2026-08-16 16:00 UTC).
# Defaults use OFF-PEAK; peak rates are 2x and run 01:00-04:00 & 06:00-10:00 UTC,
# Monday through Friday only — the whole weekend is off-peak.
If peak_input_per_1m ever gets wired to a clock, the weekday belongs on DeepSeek's calendar rather than UTC. Reading it in UTC is correct today only because both windows end before 16:00 UTC, which is exactly where a UTC date and a Beijing date begin to disagree — so both readings price identically at all 168 hours, and no test against the published windows can tell them apart until a window moves past 16:00 UTC.
Dated vectors including the two instants that do separate them, CC0: https://github.com/xyzs996/deepseek-peak-offpeak-vectors
Small correction to the DeepSeek comment in
packages/shared-python/shared/services/ai/token_costing.py:Those windows only apply on weekdays:
The Chinese version of the same footnote pins the timezone rather than the hours: 「高峰时段为北京时间周一至周五 9:00 - 12:00、14:00 - 18:00」, which is why the weekday clause is easy to lose when reading only the English page.
So peak is 35 hours a week, not 49. The numbers here are right and the off-peak default is the good call — it just gets better: the documented undercount now covers 21% of the week instead of 29%.
If
peak_input_per_1mever gets wired to a clock, the weekday belongs on DeepSeek's calendar rather than UTC. Reading it in UTC is correct today only because both windows end before 16:00 UTC, which is exactly where a UTC date and a Beijing date begin to disagree — so both readings price identically at all 168 hours, and no test against the published windows can tell them apart until a window moves past 16:00 UTC.Dated vectors including the two instants that do separate them, CC0: https://github.com/xyzs996/deepseek-peak-offpeak-vectors