fetch-deepseek: DeepSeek's new peak/off-peak column shifts every price one model to the right

[xyzs996]

On 2026-08-16 DeepSeek moved V4 to peak / off-peak billing. The pricing table gained an extra OFF-PEAK / PEAK column between the row label and the first model's price, which shifts every price cell one position right. parsePricingPage reads them positionally, so each model now gets the price of the model to its left.

I ran the current parsePricingPage verbatim against the page as it is served today. Output:

parsed.length = 3            ← FALLBACK_MODELS does not engage

deepseek-v4-flash              undefined
deepseek-v4-pro                {"input":0.22,"output":0.66,"cached_input":0.007}
deepseek-v4-flash-vision-exp   {"input":0.66,"output":1.98,"cached_input":0.022}

Correct values from https://api-docs.deepseek.com/quick_start/pricing/, USD per 1M, off-peak:

	input (miss)	output	cached input
deepseek-v4-flash	0.22	0.66	0.007
deepseek-v4-pro	0.66	1.98	0.022
deepseek-v4-flash-vision-exp	0.22	0.66	0.007

So deepseek-v4-pro gets flash's card (3× too cheap) and deepseek-v4-flash-vision-exp — which is priced identically to flash — gets pro's card (3× too expensive). Both are wrong in a way that looks entirely plausible on the page.

Why it shifts

The table rows are now shaped like this (tags stripped):

PRICING(1)(2) | 1M INPUT TOKENS(CACHE HIT) | OFF-PEAK | $0.007 | $0.022 | $0.007
PEAK          | $0.014 | $0.044 | $0.014
1M INPUT TOKENS(CACHE MISS) | OFF-PEAK | $0.22 | $0.66 | $0.22
PEAK          | $0.44 | $1.32 | $0.44
1M OUTPUT TOKENS | OFF-PEAK | $0.66 | $1.98 | $0.66
PEAK          | $1.32 | $3.96 | $1.32

cellPrice(row[i + 2]) at i = 0 now lands on the literal string OFF-PEAK. extractPrice finds no $, returns undefined, and the loop continues — so index 0 is skipped rather than misparsed, and every subsequent index reads its left neighbour's cell. The PEAK rows are harmless: priceName is "PEAK", which matches none of the CACHE HIT / CACHE MISS / INPUT / OUTPUT tests, so they are dropped.

The comment above cellPrice is now describing a page that no longer exists:

// Pricing cells can look like "$0.003625 (75% off(3))$0.0145" — the first $
// is the current (discounted) price, which is what we want.

That in-cell discount format is gone; the discount became a column.

Why none of the guards catch it

• FALLBACK_MODELS only engages on parsed.length === 0. Three models parse, so it never fires.
• deepseek-v4-flash keeps its stale prices. With input/output both undefined, pricing is undefined, so if (m.pricing) skips the pricing block and packages/data/providers/deepseek/models/deepseek-v4-flash.json keeps 0.14 / 0.28 / 0.0028 — the pre-2026-08-16 card. deepseek-v4-pro.json currently reads last_updated: "2026-08-16" while holding 0.435 / 0.87 / 0.003625, i.e. it is stamped with the date of the change and holds the values from before it.
• check-freshness.ts structurally cannot see this. Its own note says so: "Price cannot corroborate: the same model is priced differently per provider, which is the point of tracking price at all." It compares model presence against aggregator witnesses — and this run would make DeepSeek look healthier, because it adds a genuinely new model (deepseek-v4-flash-vision-exp) that the witnesses also list.
• detect-changes.ts reports rather than gates. A 3× move in both directions would land in changes.jsonl as an ordinary price change, and the price-history feature from feat: track and surface model price history #87 would then surface it to users as a real DeepSeek reprice.

Every health signal reads green.

Repro

curl -s https://api-docs.deepseek.com/quick_start/pricing/ -o /tmp/ds.html
# then call parsePricingPage(fs.readFileSync("/tmp/ds.html","utf-8"))

I ran it by copying parsePricingPage, findHtmlTables, parseHtmlTable, stripHtml, extractPrice, parseTokenCount and stripFootnote unchanged into one file — no edits — and got the output above.

Fixing it needs a schema decision, which is why this is an issue and not a PR

The parser side is small: when the cell at the model-0 position parses to no price and reads OFF-PEAK / PEAK, the row has a tier column and the offset is one greater. Something like keying off the tier label rather than assuming a fixed offset would also survive the column being dropped again later.

The harder half is that ParsedModel.pricing is { input; output; cached_input } and buildPricing produces one number per field. DeepSeek now publishes two numbers per field, selected by wall-clock time:

Off-peak rates are half of the peak rates. Peak hours are 01:00 - 04:00 and 06:00 - 10:00 UTC, Monday through Friday (all other hours are off-peak).

That is 25 of every 168 hours at peak; weekends are off-peak end to end. Three ways I can see:

1. Store off-peak and note it. Off-peak covers 143 of 168 hours, so it is the better single number, and it keeps the schema untouched. Every consumer is then quietly 2× low for 15% of the week.
2. Store peak. Safer for anyone budgeting, wrong the other way for 85% of hours.
3. Add an optional time-of-use field to the pricing schema. Correct, and it would generalise — DeepSeek is not likely to be the last provider to do this — but it is a schema change that touches packages/npm and the web app, not just the fetcher.

If (1) or (2), the fix is contained enough that I am happy to send a PR with the parser change and the three corrected model files. I did not open one because picking among these is your call, and the parser fix alone would write a confidently wrong number under any of them.

One thing worth doing regardless of which route: a sanity check that refuses to write when a model's price moves by more than some factor without the model id changing. This bug moved deepseek-v4-pro by 3× in one run, and nothing in the pipeline had an opinion about that.

The vision model is also new to the catalog (deepseek-v4-flash-vision-exp, image input, priced identically to flash) — worth adding, just not with pro's numbers.

Per-vendor cache-read rates I checked these against: https://xyzs996.github.io/llm-api-pricing/

[rupic-app]

I find #101 is an open, actionable bug: packages/data/scripts/fetch-deepseek.ts:102-121 reads DeepSeek pricing with a fixed cell offset, so the new tier column can shift values while a partial parse bypasses fallback. The same fetcher still emits discovered models and passes only scalar pricing fields (packages/data/scripts/fetch-deepseek.ts:307-310,405-410), and no linked PR establishes a fix. The remaining design choice is whether peak/off-peak rates should be represented as tiers or reduced to one canonical scalar, so this requires maintainer judgment rather than automated resolution.

Triage by Rupic. Mention @rupic-app to re-run.

[rupic-app]

I confirmed issue #101 on main: parsePricingPage uses fixed offsets in packages/data/scripts/fetch-deepseek.ts:102-121, while parse.ts:116-121 returns no price for tier labels. Three partial models therefore bypass FALLBACK_MODELS at fetch-deepseek.ts:307-310. Existing V4 records still contain stale scalar cards, and no linked PR exists. The parser fix is mechanical, but representing peak and off-peak rates requires a maintainer decision.

Readiness: 🟡 yellow

Plan

1. I recommend preserving both schedules through the existing ModelPricing.tiers field in packages/data/src/types.ts:49-68, using off-peak for legacy scalar fields and documenting the UTC schedule in pricing_notes.
2. Refactor parsePricingPage to detect OFF-PEAK and PEAK semantically, map prices after the tier cell, retain compatibility with the previous no-tier layout, and replace the stale in-cell discount comment.
3. Reject incomplete pricing parses before writing models. A nonempty result with missing required prices must not pass the length-only fallback condition at fetch-deepseek.ts:307-310.
4. Thread tier data through the buildPricing call at fetch-deepseek.ts:405-410, updating packages/data/src/types.ts or packages/data/scripts/shared.ts only where needed to retain both schedules.
5. Update FALLBACK_MODELS, deepseek-v4-flash.json, and deepseek-v4-pro.json with the corrected source date and values. Add deepseek-v4-flash-vision-exp.json only with verified image-input metadata; its off-peak card matches Flash.
6. Add a checked-in pricing fixture and parser regression coverage for legacy and tier-column layouts, asserting no missing first-model price, no shifted Pro price, and equal Flash and vision pricing. Add a pre-upsert factor-change guard because detect-changes.ts:116-130 only reports differences.

Risks

• Legacy scalar consumers cannot represent wall-clock rates. Off-peak is understated during peak hours, while peak is overstated for most of the week.
• The generic PricingTier shape has labels, columns, and rows but no explicit time-of-use semantics, so consumers may need display and documentation changes.
• The current fetcher assigns text-only modalities to generated entries. Adding the vision SKU without independently verified metadata could publish incorrect capabilities.
• A factor-change guard can block legitimate provider repricing if its threshold and exemption rules are too strict.

Questions

• Should the canonical scalar be off-peak, peak, or should both schedules be exposed through ModelPricing.tiers with a selected scalar fallback?
• Should deepseek-v4-flash-vision-exp be added in this change, and what source-verified release, modality, capability, and version metadata should it carry?
• What factor threshold should reject suspicious price changes, and should that protection apply only to DeepSeek or to every provider writer?

The run continues after a 10 minute veto window unless cancelled with @rupic-app cancel. It will open a fix PR, or post a proposal instead if a maintainer decision turns out to be needed.

Fix plan by Rupic.

[xyzs996]

Three answers, to the extent I can source them rather than opine.

The exact table shape, since the fixture in step 6 needs it. Parsed off the live page today, row by row, with colspans:

[MODEL ×3]                      [deepseek-v4-flash] [deepseek-v4-pro] [deepseek-v4-flash-vision-exp]
[MODEL VERSION ×3]              [DeepSeek-V4-Flash-0731] [DeepSeek-V4-Pro-0813] [DeepSeek-V4-Flash-Vision-Exp]
[CONTEXT LENGTH ×3]             [1M ×3]
[MAX OUTPUT ×3]                 [MAXIMUM: 384K ×3]
[FEATURES] [Json Output ×2]     [✓] [✓] [✓]
[Tool Calls ×2]                 [✓] [✓] [✓]
[Responses API ×2]              [✓] [✓] [✓]
[Anthropic API ×2]              [✓] [✓] [✓]
[Chat Prefix Completion（Beta）×2] [✓] [✓] [✓]
[FIM Completion（Beta）×2]       [Non-thinking mode only] [Non-thinking mode only] [Not supported]
[PRICING (1)(2)] [1M INPUT TOKENS (CACHE HIT)] [OFF-PEAK] [$0.007] [$0.022] [$0.007]
[PEAK]                          [$0.014] [$0.044] [$0.014]
[1M INPUT TOKENS (CACHE MISS)]  [OFF-PEAK] [$0.22] [$0.66] [$0.22]
[PEAK]                          [$0.44] [$1.32] [$0.44]
[1M OUTPUT TOKENS]              [OFF-PEAK] [$0.66] [$1.98] [$0.66]
[PEAK]                          [$1.32] [$3.96] [$1.32]
[Concurrency Limit (3) ×3]      [2500] [500] [2500]

Note the PEAK rows carry no row-label cell at all — the label is rowspanned from the OFF-PEAK row above. So the price rows are not merely shifted by a constant, they are ragged: the OFF-PEAK rows have label + tier + 3 prices, the PEAK rows have tier + 3 prices. A fixture that only shifts every row by one won't reproduce the second half.

Q: off-peak, peak, or both? Off-peak as the canonical scalar. Two reasons beyond the 143-of-168-hours split: footnote (1) states peak is exactly 2× off-peak with no per-model variation, so storing off-peak plus the schedule loses no information and peak stays derivable; and off-peak is the tier a legacy scalar consumer is actually on for any request outside Mon–Fri, which includes every weekend hour.

Q: vision SKU metadata. Everything above is from the pricing table itself, so it's as source-verified as the prices are: id deepseek-v4-flash-vision-exp, version DeepSeek-V4-Flash-Vision-Exp, 1M context, 384K max output, thinking mode default-on, JSON output / tool calls / Responses API / Anthropic API / chat prefix completion all ✓, FIM not supported (the only feature cell where it differs from Flash), concurrency 2500, and an off-peak card identical to Flash. For the image modality, footnote (2) is explicit:

Images sent to deepseek-v4-flash-vision-exp are converted into tokens based on their dimensions and billed as input tokens together with your text tokens. See Vision: Token Usage for the conversion rule.

So image input is confirmed, image tokens bill at the text input rate, and there is no separate per-image price to model. What the pricing page does not give you is a release date, so if the schema requires one, that has to come from elsewhere.

Q: factor threshold. I'd push back on a magnitude guard, because the two things you'd want it to separate overlap the wrong way. This repricing moved deepseek-v4-pro's cache-hit rate from 0.003625 to 0.022 — a legitimate 6.07× change. The column shift, meanwhile, hands deepseek-v4-pro Flash's 0.007, a 3.14× error. The real repricing is the larger jump. Any threshold low enough to catch the bug would have rejected the correct update, and any threshold high enough to let the correct update through sails past the bug.

Which I think argues for your step 3 doing the work alone: reject on structure — a parsed model missing a required price, a row whose cell count doesn't match the header, a tier cell whose text is neither OFF-PEAK nor PEAK — rather than on how much a number moved. That also fails loudly the next time the layout changes in a way nobody predicted, which is the actual recurring failure here.

One thing to fold into step 5 while you're in FALLBACK_MODELS: its current DeepSeek entries are the same pre-2026-08-16 promotional card, so today the fallback and the parser are wrong in different ways, and the fallback never engaging is what keeps that from showing.

[rupic-app]

Diagnosis

I verified that #101 is a real defect on the checkout at c931457. packages/data/scripts/fetch-deepseek.ts:110-121 treats row[i + 2] as the model price for the first pricing row, so OFF-PEAK becomes the first model's cell and later models read their left neighbour's price. The ragged continuation rows use row[i + 1] at packages/data/scripts/fetch-deepseek.ts:130-139, so they exhibit the same semantic misalignment.

if (currentCategory === "pricing" && itemName) {
  for (let i = 0; i < modelIds.length; i++) {
    const p = cellPrice(row[i + 2]);
    if (p == null) continue;

The parser then emits every discovered model even when either required scalar is absent (packages/data/scripts/fetch-deepseek.ts:143-157), while fallback is selected only when parsed.length === 0 (packages/data/scripts/fetch-deepseek.ts:307-310). The broken invariant is: each stored model price must be associated with its own model column, and a source layout that cannot satisfy that invariant must not produce a partial write. The current code produces the missing first card, shifted later cards, stale existing values for the omitted model, and no fallback because the partial result is nonempty.

Candidate designs

1. Canonical off-peak scalar plus a pricing note. Keep the public shape unchanged and write the off-peak values into input, output, and cached_input; document the UTC peak schedule in pricing_notes. This is the smallest change and matches the majority of the published schedule, but scalar consumers remain 2× low during peak hours and the peak values are not retained structurally.

2. Canonical peak scalar plus a pricing note. Keep the same public shape but choose peak values for budgeting safety. This also has a small blast radius, but it is wrong for most hours and is the opposite of the issue author's stated off-peak preference.

3. Preserve both schedules in the existing ModelPricing.tiers field, with off-peak as the legacy scalar. The checkout already defines tiers in packages/data/src/types.ts:49-79, and CONTRIBUTING.md:120-153 documents tier rows as the representation for multiple pricing categories. A Token pricing tier can carry OFF-PEAK and PEAK rows while legacy list/compare fields use off-peak. This retains the source information without widening exported types, but the generic tier labels do not have a dedicated time-of-use semantic and consumers must render the labels clearly.

A new explicit time-of-use schema would be more precise, but it widens the exported data contract and requires coordinated consumer changes; no checkout guidance or decision record authorizes that API direction.

Decision needed

The issue author replied with a source-based preference for candidate 3, but the live thread does not identify that reply as a maintainer decision. The repository therefore records the defect but not the policy needed to choose a safe implementation. A maintainer needs to answer:

• Should the immediate fix use candidate 3, preserving both rates in existing tiers and using off-peak for legacy scalar consumers?
• If only one scalar is desired, should it be off-peak or peak, and should the other schedule be documented only in pricing_notes?
• Should the newly listed deepseek-v4-flash-vision-exp be added now, given that the issue supplies pricing-page metadata but no release date?

Once that direction is recorded, the mechanical parser change should detect OFF-PEAK/PEAK semantically, validate complete model pricing before upsert, retain compatibility with the old layout, and add regression coverage for both the legacy and ragged tier-column rows.

Fix proposal by Rupic. A maintainer decision is needed before a fix PR: reply with the chosen direction and comment @rupic-app fix to start the fix.