Update DeepSeek V4 to the 2026-08-17 peak/off-peak prices - #581

Fixes #571.

What this changes

deepseek-v4-flash and deepseek-v4-pro still carried flat rates checked on 2026-05-12 and 2026-06-02. Since 2026-08-17 DeepSeek bills both at two rates depending on the time of day.

Source: https://api-docs.deepseek.com/quick_start/pricing/, read 2026-08-22. Peak hours are 01:00–04:00 UTC and 06:00–10:00 UTC; every other hour is off-peak.

The old flat rate stays as the unconstrained first price, the new off-peak rate is gated on start_date: 2026-08-17, and the two peak windows come last. Both engines try conditional prices last-to-first and fall back to the first entry, so:

V4 needs two peak entries rather than the one deepseek-chat uses, because its peak hours are two disjoint windows. Neither shadows the other.

deepseek-v4-flash-vision-exp matches starts_with: deepseek-v4-flash and DeepSeek publishes exactly the flash rates for it, so it is covered without a separate entry.

Two things I could not express, flagged rather than guessed

1. Price history is preserved for 17 hours of the day, not all 24. constraint is StartDateConstraint | TimeOfDateConstraint | None, a union, so one entry cannot be both "from 2026-08-17" and "during 01:00–04:00 UTC". The dated off-peak entry recovers every pre-repricing hour outside the peak windows, but a request from May at 02:00 UTC still matches the time-of-day peak entry and gets billed at August peak rates. That residual gap is stated in price_comments on both models and pinned by a test, so the data does not look authoritative for dates it isn't. Raised as #582.

(An earlier revision of this PR overwrote the old rates outright and claimed interleaving the two constraint kinds was strictly worse. That was wrong — cubic caught it. The layout above is its suggestion.)

2. The weekend rule. From midnight Beijing time on 2026-08-23, DeepSeek bills off-peak all day on Saturdays and Sundays. start_time/end_time alone cannot express a day-of-week condition, so on weekends the peak entries here are an upper bound. The error is bounded and one-directional: at most 2x on 6 of 168 hours per week, always an overestimate. Dropping the peak entries instead would understate every weekday peak request by the same 2x. Noted in price_comments on both models and raised as #582. (I raised the same limitation on simonw/llm-prices, so it is not specific to this repo's schema.)

One thing worth a second look, not changed here

deepseek-v4-pro's previous 0.435 / 0.003625 / 0.87 matches LiteLLM's tencent/deepseek-v4-pro (0.4350 / 0.0036 / 0.8700) to four significant figures, including the unusual 0.003625. That looks like a Tencent reseller price that landed under a pricing_urls pointing at DeepSeek's own page. This PR replaces it with DeepSeek's published rate either way, but you may want to check whether the importer that produced it is mixing resellers into first-party providers elsewhere.

Tests

tests/dataset/usages.json pins a single UTC instant (2025-11-06 12:00Z, off-peak), so it cannot catch constraint-resolution drift between the two engines — which is exactly what the two-window shape introduces. So this adds a parametrized test on each side over the shipped data, covering both window edges and the gap between them:

• tests/test_price_calc.py::test_price_constraint_two_time_of_date_windows
• packages/js/src/__tests__/comprehensive.test.ts → calcPrice - Deepseek V4 peak windows

Both run the same eight hours against both repriced models — 00:00 off-peak, 01:00 peak (inclusive start), 04:00 off-peak (exclusive end), 05:00 off-peak (the gap), 06:00 peak, 09:00 peak, 10:00 off-peak, 23:00 off-peak — so a wrong rate on either flash ($22/$44 per 100M input tokens) or pro ($66/$132) fails CI on both sides.

A second pair pins the preserved history and the known residual gap at 2026-05-01:

• tests/test_price_calc.py::test_price_deepseek_v4_before_repricing
• packages/js/src/__tests__/comprehensive.test.ts → calcPrice - Deepseek V4 before the 2026-08-17 repricing

00:00, 12:00 and 23:00 must return the old flat rate (flash $14, pro $43.50 per 100M input tokens); 02:00 is asserted to return the peak rate, so the 7h/day gap in §1 is a pinned known limitation rather than something that can drift silently. 24 cases per language.

usages.json is byte-identical to main: its pinned instant is 2025-11-06 12:00Z, which now resolves to the preserved flat rate rather than the new one.

Verification

Every generated file here was written by make build — none hand-edited.

make build       # data.py, data.ts, v2/data.json, v2/data_slim.json; README and schemas unchanged
make lint        # 61 files already formatted; all checks passed
make typecheck   # 0 errors, 0 warnings, 0 notes
make test        # 877 passed, 41 xfailed, 100.00% coverage; usages.json up to date
npm run ci       # 1876 passed, 1 skipped, 14 files

Diff of the generated v2 payload, confirming nothing outside these two models moved:

import json, subprocess
old = json.loads(subprocess.run(['git','show','main:prices/new_data/v2/data.json'],
                                capture_output=True, text=True, check=True).stdout)
new = json.load(open('prices/new_data/v2/data.json'))
flat = lambda d: {(p['id'], m['id']): json.dumps(m, sort_keys=True)
                  for p in d for m in p.get('models', [])}
a, b = flat(old), flat(new)
assert not set(a) ^ set(b)                                  # no models added or removed
print(sorted(k for k in a if a[k] != b[k]))
# [('deepseek', 'deepseek-v4-flash'), ('deepseek', 'deepseek-v4-pro')]