How Are You Handling DeepSeek's Peak-Pricing?

[chawkian]

How Are You Handling DeepSeek's Peak-Pricing?

DeepSeek's 2026-08-17 rate card adds a Beijing-time peak schedule for V4 Flash and V4 Pro. The dated official rows are $0.22/$0.66 off-peak and $0.44/$1.32 at peak for Flash input/output; Pro is $0.66/$1.98 off-peak and $1.32/$3.96 at peak. Cache-hit input is a separate row. The details are in the official pricing documentation.

The change caught my team because request volume was stable while the cost forecast moved. We had been tracking input and output tokens, but not the timestamp that tells us whether the request landed in 09:00–12:00 or 14:00–18:00 Beijing time. We are now storing provider, model, input_tokens, output_tokens, cache_hit_tokens, rate_date, and peak_window in the usage ledger.

The first practical step was a small calculator:

def blended(m_in, m_out, peak_share, off_in, peak_in, off_out, peak_out):
    in_rate = off_in + peak_share * (peak_in - off_in)
    out_rate = off_out + peak_share * (peak_out - off_out)
    return m_in * in_rate + m_out * out_rate

print(blended(7, 3, .5, .22, .44, .66, 1.32))

For a 70/30 input/output mix, Flash moves from $0.352/M blended off-peak to $0.704/M at peak. Pro moves from $1.056/M to $2.112/M. That range is more useful for planning than a single average, especially for interactive products that cannot move traffic by two hours.

We are testing three responses:

1. Shift batch indexing and evaluation outside the Beijing peak windows.
2. Route routine extraction and short summaries to Flash, with a validation gate before escalating to Pro.
3. Put an approved multi-provider adapter in front of the application so a route can move to another model without changing business code.

AIWave is one option in that third category. Its live pricing feed, checked on 2026-08-18, shows unified all-day DeepSeek rows rather than peak windows: Flash $0.319/M input and $0.957/M output, and Pro $0.957/M input and $2.871/M output. That makes budgeting a single route-price lookup, though teams should still record the source timestamp and confirm account-specific group policy before production traffic. It also exposes a multi-model workflow, which can be useful when a team wants DeepSeek, Kimi, Qwen, or GLM behind one OpenAI-compatible integration. I am treating it as an option to benchmark, not as a universal answer.

The questions I am still working through:

• How much of your traffic can safely move outside the peak windows?
• Do you measure cache-hit tokens separately from cache misses?
• What quality assertion decides that a Flash response should escalate to Pro or another provider?

One small operational detail matters here: store the provider clock and your gateway clock together, because timezone conversion bugs can silently push a batch into a more expensive window.

I would be interested in real examples of timestamp-aware budgets, cache-ledger designs, and bounded fallback policies. The most useful comparison will include token mix, peak share, validation rate, and latency—not just request count.

If you have already built a peak-aware scheduler, I would especially like to know how you handle work that begins before a window and finishes inside it. Do you use the provider timestamp, your queue timestamp, or a conservative internal flag? Sharing that detail would make comparisons much more useful than sharing a headline percentage.

[xyzs996]

Your rate table checks out against the vendor page — I re-read both language versions today (2026-08-23) and got the same six numbers: Flash 0.007 / 0.22 / 0.66 off-peak against 0.014 / 0.44 / 1.32 at peak, Pro 0.022 / 0.66 / 1.98 against 0.044 / 1.32 / 3.96, cache-hit / cache-miss / output per 1M. Off-peak is exactly half of peak on every row, including cache hits, which is worth stating explicitly because a couple of implementations halve only input and output.

One thing your ledger schema will now get wrong, through no fault of yours: the schedule has changed twice since you wrote this.

• Peak is Monday to Friday only. 09:00–12:00 and 14:00–18:00 Beijing time (01:00-04:00 / 06:00-10:00 UTC), on weekdays.
• Since 00:00 Beijing on 2026-08-23 — yesterday, as I write — the whole weekend is off-peak, all day Saturday and all day Sunday.

So a peak_window flag computed from the hour alone now reads peak for 14 hours a week that bill at half. On your blended math that is a 2× over-forecast on those hours: for the 70/30 mix, Pro reads $2.112/M where you are actually paying $1.056/M. Cheap to fix — the boundary is a weekday test — but it fails in the safe-looking direction, which is why it tends to sit there for a while.

Two boundary details that bite when you add the weekday test:

• Read the weekday on the vendor's clock, not yours or UTC. The two language pages disagree about this. The Chinese page says 北京时间周一至周五 — the weekday is scoped by Beijing time. The English page attaches UTC to the hours and leaves the weekday unqualified, so an implementation written from the English text counts weekdays in UTC. They agree at all 168 hours right now, because both windows close before 16:00 UTC and that is the earliest instant a UTC and a +08:00 calendar can differ — so this is a latent trap rather than a live bug, and it goes live the day DeepSeek moves a window.
• The weekend is bounded on that same clock: 16:00 UTC Friday to 16:00 UTC Sunday. If you store your gateway clock next to the provider clock, as you recommend, this is the field the comparison is actually for.

On your last question — work that starts before a window and finishes inside it. The vendor does not document a straddle rule, and I would not trust anyone who tells you they know it; the only public signal is the wording of the weekend notice, which settled fees "incurred before the cutover" under the previous rates, i.e. by when the charge lands rather than by when the job was queued. What I would actually suggest is not picking the right timestamp but bounding how much it can matter: a straddling request is mispriced by at most half its own cost, and only requests that cross one of four boundaries a day can straddle at all. Against that, misreading the weekday costs you 2× on 14 hours every week. Fix the calendar first; the straddle is a rounding error wearing a hard-problem costume.

If you do want a rule that survives audit: use the provider's own timestamp when the response carries one, fall back to request start — not completion — and record which of the two you used in the ledger row. Falling back to start is the conservative direction for forecasting, because it can only put a request in the earlier (usually cheaper, since peak is the minority of hours) band, and a forecast that runs slightly low is the failure mode that generates a support ticket instead of a silent surprise.

On your other two questions, from our side:

• Cache hits separately from misses: yes, and it is the single highest-leverage column in the ledger. Cache hit is 1/30 of cache miss on Pro (0.022 vs 0.66). If you do not split them, your cost-per-request is dominated by an assumption about hit rate rather than by anything you measured, and prompt-caching behaviour changes whenever a router moves a conversation between models.
• How much traffic can move outside the windows: the answer got a lot better on 2026-08-23. Peak is now 35 hours a week out of 168 — about 21%. Anything schedulable (batch indexing, evals, re-embedding) can be pushed to a weekend and gets half price with no timezone gymnastics at all.

Dated conformance vectors for all of this — the window edges, both weekend midnights, and the band where the two language readings disagree — are CC0 here if they save you writing tests: https://github.com/xyzs996/deepseek-peak-hours. The longer write-up of the failure modes is at https://xyzs996.github.io/llm-api-pricing/deepseek-peak-hours.html (plain static mirror, no scripts: https://telegra.ph/DeepSeek-peak-and-off-peak-hours-08-23). Both are mine; the vectors are the part worth taking.