fix(pricing): DeepSeek V4 static defaults stale by 4 days, off by ~1.6-2.4x - #10635
Conversation
…6-2.4x DeepSeek switched v4-pro/v4-flash to peak/off-peak dynamic pricing on 2026-08-17 (off-peak = exactly half of peak; peak hours 01:00-04:00 and 06:00-10:00 UTC — https://api-docs.deepseek.com/quick_start/pricing/). The compiled-in DEFAULT_PRICING_FRONTIER.deepseek entries were last checked 2026-08-13, four days before the change, and never updated. sync-gateway-style writes to this table are rejected on this build (POST /api/pricing returns non-2xx — the table is compiled into the bundle), so this static default is the only lever available for correcting it; fixing the number here is the whole fix. Uses the OFF-PEAK values (documented lower bound) since getPricingForModel() has no time-of-day dimension anywhere in its resolution chain — true peak-awareness would need a `ts`/hour parameter threaded through the resolver and every call site, which is a real feature addition, not a bugfix, and is out of scope here. Off-peak-only is a strict undercount confined to the two peak windows, never wrong-direction, and is already a ~1.6-2.4x correction over the stale pre-change numbers it replaces. Confirmed live consumers of this table (src/shared/utils/costEstimator.ts, src/lib/batches/costEstimator.ts) and re-ran their test suites plus every pricing-* unit test (68 tests across 11 files) — all pass unchanged; nothing asserts the specific stale price values.
|
Reviewed — this is a clean, well-documented data fix. The rationale for using off-peak |
…ricing Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
…nsistency (diegosouzapw#10635 review follow-up)
d633658 to
3458380
Compare
|
Regression test landed on the branch (commit 3458380, co-authored with the review): tests/unit/pricing-deepseek-v4-static-regression.test.ts asserts the exact corrected off-peak values for deepseek-v4-pro/-flash AND the documented output=3x-input / reasoning=output consistency. Ran locally: 3/3 pass. Thanks for the review — ready for merge. |
…6-2.4x (diegosouzapw#10635) Merged — locally validated (28/28 focused pricing tests, gates green). Appreciate the conservative off-peak-only scope and the live verification against the pricing page. Thanks!
2 participants
Description
DeepSeek switched
deepseek-v4-pro/deepseek-v4-flashto peak/off-peak dynamic pricing on 2026-08-17 (off-peak = exactly half of peak; peak hours 01:00-04:00 and 06:00-10:00 UTC — pricing page).DEFAULT_PRICING_FRONTIER.deepseekinfrontier-labs.tsis datedchecked 2026-08-13, four days before the change, and was never updated — the compiled-in numbers are now stale by ~1.6-2.4x depending on token type.I hit this from the consumer side (a local cost-reconciliation pipeline reading
/api/pricing/defaults) and confirmedPOST /api/pricingstill returns non-2xx on this build — the table really is compiled-in, matching the existing pattern insync_gateway-style write attempts. Fixing the static default is the only lever available.Scope
Uses the off-peak values (the documented lower bound) since
getPricingForModel(provider, model)has no time-of-day dimension anywhere in its resolution chain. Adding real peak-awareness would mean threading ats/hour parameter through the resolver and every call site — a real feature, not a bugfix — so deliberately out of scope here. Off-peak-only is a strict undercount confined to the two peak windows, never wrong-direction, and is still a ~1.6-2.4x correction over what's there now.Validation
src/shared/utils/costEstimator.ts,src/lib/batches/costEstimator.ts.pricing-*/catalog-pricing-*unit test (68 tests across 11 files, includingtests/unit/lib/batches/costEstimator.test.ts) — all pass unchanged; none assert the specific stale values, so nothing needed updating on the test side.