DeepSeek pricing is pre-2026-08-16 (deepseek-reasoner output is 7-14x low), and the rate is now a time-of-day band

[xyzs996]

pricing/deepseek.json is on pre-2026-08-16 rates. On deepseek-reasoner the output rate is 7.1× low against what DeepSeek charges off-peak and 14.1× low against peak, so cost attribution for anything reasoning-heavy on DeepSeek is off by close to an order of magnitude.

Two separate problems: the numbers are stale, and one of them is a band, not a number — which is the interesting one for this repo, since the README already names hidden dimensions as the thing it exists to solve.

Units

Everything below is USD per 1M tokens. This repo stores per-1M ÷ 10⁴ — checked against gpt-4o (request_token: 0.00025 ↔ $2.50/M) and gpt-4o-mini (1.5e-05 ↔ $0.15/M).

What's stored vs. what DeepSeek charges

Vendor page, fetched 2026-08-22:

key		stored	official off-peak	official peak
deepseek-chat	in / out	0.14 / 0.28	0.22 / 0.66	0.44 / 1.32
	cache read	0.0028	0.007	0.014
deepseek-v4-flash	in / out	0.14 / 0.28	0.22 / 0.66	0.44 / 1.32
	cache read	0.0028	0.007	0.014
deepseek-reasoner	in / out	0.14 / 0.28	0.66 / 1.98	1.32 / 3.96
	cache read	0.0028	0.022	0.044
deepseek-v4-pro	in / out	0.435 / 0.87	0.66 / 1.98	1.32 / 3.96
	cache read	0.003625	0.022	0.044

deepseek-reasoner is the one to look at first — it currently carries the flash rates, not the pro rates it aliases, and that was wrong before the price change too. deepseek-v4-flash-vision-exp (released 2026-08-21, flash rates) has no entry at all.

One structural giveaway that these are two different price lists: the stored rows have output at exactly 2× input. DeepSeek charges 3×, on every model, in both bands.

The part that isn't a stale number

Since 2026-08-16 16:00 UTC DeepSeek bills two rates for the same model:

Peak hours are 01:00 - 04:00 and 06:00 - 10:00 UTC (all other hours are off-peak).

Off-peak is exactly half of peak. And since 2026-08-22 16:00 UTC — 00:00 Beijing time on Sunday 2026-08-23, so this is live now, not upcoming — whole weekends bill off-peak, peak hours included.

So there is no single correct scalar for request_token. Off-peak covers 17 of the 24 hours on a weekday (peak is 3 + 4 = 7 hours) and all of Saturday and Sunday. Whichever number goes in, it is wrong most of the day, and it moves by 2× — larger than most of the model-to-model differences this repo tracks.

It cannot be resolved by reading the API either. DeepSeek exposes no rate endpoint and no tier indicator on the response; the boundary is a published wall-clock rule and nothing else.

Two shapes that already exist in this repo

• batch_config idiom. An off_peak_config sibling of pay_as_you_go, same shape as the batch_config blocks in pricing/google.json — same model, different rate depending on how the call lands. Base pay_as_you_go stays at peak so a missing or unparseable window can never make spend look cheaper than it was; the gateway drops to off_peak_config when it can prove the timestamp is off-peak.
• Key-suffix idiom. deepseek-chat-peak / deepseek-chat-off-peak, the way gemini-1.5-pro-gt-128k / -lte-128k splits a context threshold. Cheaper to land, but unlike token count the selector isn't in the request — the caller would have to know the schedule, which pushes the problem to every consumer.

I lean to the first, but which one is yours to decide, and I'd rather not guess at the policy inside a PR.

Offer

Happy to send either:

1. Just the numbers, no schema change — all four keys moved to one band plus the missing vision model. Say which band. Peak is the conservative choice for attribution (never hides overspend); off-peak is the accurate choice more hours of the week. I won't pick that for you.
2. The off_peak_config version, with the schedule as data — windows, the Asia/Shanghai weekend rule, and the effective instant — rather than prose in a comment.

Two details worth having in whichever lands, both of which cost nothing now and are wrong to discover later:

• The weekend is bounded in Beijing time, so in UTC it runs 16:00 Friday → 16:00 Sunday. Reading the weekday off a UTC clock happens to give the right band today, because both peak windows sit outside the 16:00–24:00 UTC hours where the two readings disagree — it is a trap that arms the day DeepSeek moves a window, not a live bug. Worth writing as +08:00 from the start.
• China has had no daylight saving since 1991, so a fixed +08:00 offset is exact here and needs no tzdata dependency.

Per your README: this is the velocity problem and the hidden-dimensions problem landing on the same provider in the same week.