DeepSeek peak pricing: which 30% of your bill can move

Two model providers introduced time-of-day pricing in the same month. DeepSeek’s latest repricing splits every rate into peak and off-peak windows, and GLM-5.3 launched with off-peak discounts on day one. That makes the hour of the day an input to your inference bill — and if your architecture has nowhere to put that fact, your applications will end up paying peak rates for work that never needed to run at peak. The fix has three steps: measure how much of your traffic can move, make it movable, and put the moving decision in one layer instead of every service. This post walks the official rate cards first, then the arithmetic, then the architecture.

What actually changed

Start with the primary source. DeepSeek’s official rate card now prices every line — input, output, cache hit, cache miss — twice, once per window:

Three things jump out of that table before any commentary:

• Off-peak is exactly half of peak, across the board — the footnote on the official page says so outright, and defines the windows: peak is 01:00–04:00 and 06:00–10:00 UTC; everything else is off-peak.
• The repricing itself was steep. VentureBeat puts the sharpest jump at up to 1,100%, and that extreme sits on the cache-hit input tier — which is its own headline: the cached-prefix discount got sharply narrower at the same time the clock got involved.
• Cache state still dominates. Even after the increase, a cache hit bills at about 1/30th of a cache miss on flash. The cheapest token is still the one you didn’t re-send; the second cheapest is now the one you sent at 3 AM UTC.

The second data point landed the same week. GLM-5.3 shipped on 2026-08-14 — same base model as 5.2, all gains from post-training, weights promised “in two weeks after launch” — and its Coding Plan subscription launched with off-peak discounts built in: points burn at half rate outside peak hours.

Note the mechanics differ, and the difference matters: DeepSeek prices the clock into the per-token API rate; GLM prices it into subscription quota burn. Quota discounts can’t be arbitraged by switching providers the way wholesale prices can. But the shared signal is what counts — two visible vendors keyed cost to the hour in the same month.

Why providers price the clock

No inside information here, just fleet arithmetic. A provider’s GPU fleet is sized for peak demand and idles off-peak. Idle GPUs still depreciate. Anything that shifts elastic demand into the trough raises fleet utilization, and a price signal is the cheapest way to do that shifting — power grids figured this out decades ago. Expect more providers to copy it, because the incentive is structural, not a quirk of one vendor’s quarter.

This is also why the trend reads as one more step in a longer pattern. LLM pricing has been adding dials for two years, and each dial moved billing further away from “one flat rate”:

What it does to your bill

Whether this hurts depends on one question: how much of your traffic actually chooses its own schedule?

Interactive traffic doesn’t. A user asking a question at 2 PM has to be answered at 2 PM, at whatever that hour costs. And “that hour” now depends heavily on where your users live. Convert DeepSeek’s published peak windows and the geography does something interesting:

Where your users sit just became a pricing input: a Chinese-workday product pays peak rates almost by definition, while a US-daytime product gets the discount without lifting a finger. InfoWorld’s read is the same: the home market absorbs the peak, Western buyers mostly don’t.

But a surprising share of production LLM spend is not interactive — nightly summarization, embedding backfills, eval sweeps, report generation, batch classification. That work has a deadline, not a start time. Under flat pricing, “run it whenever the cron fires” was a harmless default. Under time-of-day pricing, the same default quietly books everything at whatever window your cron happens to hit.

The response is not complicated, but it has to be deliberate:

The first item costs you an afternoon: bucket a week of usage by hour and tag which share was deadline-driven. The math on the other side is not subtle — if 30% of your tokens are movable, a half-price off-peak window is worth up to 15% of your bill (30% of spend × 50% off), assuming the window can absorb that volume. If 5% are movable, stop here; the engineering below isn’t worth it. The second item is the hard one: making a workload movable means its scheduler, not its author, decides when it runs — and most pipelines weren’t written that way.

Where the decision should live

The tempting place to handle this is application code — a utility that checks the clock before picking a model. That works for exactly one service, then rots. Pricing windows are per-provider facts that change without your release cycle; sprinkling them across codebases means some service is always wrong about what an hour costs.

Schedule-aware placement belongs in the same layer that already decides where a request goes — the routing layer, because doing that job at all means holding a per-provider price sheet anyway. A routing policy that can express “this workload is movable” gets you the discount without any service knowing what time it is. A sketch, not any product’s schema:

{
  "workload": "nightly-summaries",
  "deadline": "07:00+08:00",
  "route": "cheapest-window",
  "fallback": { "on": ["window-missed"], "route": "balanced" }
}

Read it as: this job must land by 7 AM; until then, hold it for the cheapest pricing window available; if the deadline gets close before one opens, stop waiting and run it under the normal policy. The declaration is the point, not the syntax: deadline, not start time. Whatever layer owns your routing should be the one watching provider price windows — which is why a cross-provider price sheet (ours lives here) belongs to the routing layer, not to any one service’s config.

The part to take seriously

Time-of-day pricing is not a gimmick, and it is not going away — the fleet economics behind it are too solid. The teams that will feel it worst are the ones whose architecture treats price as a constant: hard-coded model choices, cron jobs firing at midnight local time into someone else’s peak window, no notion of “movable” anywhere in the stack. None of that is hard to fix. It is just work nobody scheduled — and as of this month, not scheduling it has a price you can put a number on. For the traffic mix above, it was 15% of the bill.