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

> DeepSeek now prices every line twice, peak and off-peak; GLM-5.3 launched with off-peak discounts. If 30% of your tokens are movable, a half-price window is worth up to 15% of the bill. The official rate cards, the peak windows converted to your timezone, and where the deadline-not-start-time decision belongs.

- Published: Aug 21, 2026
- Author: Leo Kaka, Engineering
- Tags: pricing, routing, cost
- Canonical: https://pirouter.ai/blog/time-as-a-pricing-variable

---
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:

| Per 1M tokens | deepseek-v4-flash (off-peak / peak) | deepseek-v4-pro (off-peak / peak) |
|---|---|---|
| Input, cache hit | $0.007 / $0.014 | $0.022 / $0.044 |
| Input, cache miss | $0.22 / $0.44 | $0.66 / $1.32 |
| Output | $0.66 / $1.32 | $1.98 / $3.96 |

![DeepSeek's official Models & Pricing page, showing peak and off-peak rates for every line item](/blog/images/deepseek-official-rates.png "Fig. 1 — the official rate card: every line is priced twice. Source: [DeepSeek API docs](https://api-docs.deepseek.com/quick_start/pricing).")

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%](https://venturebeat.com/orchestration/deepseeks-top-ranked-v4-flash-stumbles-on-real-agent-tasks-as-its-prices-surge),
  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](https://z.ai/blog/glm-5.3) — 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.

![Z.ai's GLM-5.3 launch benchmark chart across six evaluation suites](/blog/images/glm53-benchmarks.png "Fig. 2 — the launch post's own benchmark chart. The pricing move rode in quietly alongside these bars. Image: [Z.ai release post](https://z.ai/blog/glm-5.3).")

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":

![Timeline of LLM pricing mechanisms: flat per-token, tiers and batch, cached input, time-of-day](/blog/images/time-as-a-pricing-variable-pricing-eras.png "Fig. 3 — each pricing era added a dial; time-of-day is the first one keyed to the clock.")

## 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:

| Region | Peak window 1 | Peak window 2 | Verdict for interactive traffic |
|---|---|---|---|
| UTC | 01:00–04:00 | 06:00–10:00 | — |
| Beijing (UTC+8) | 09:00–12:00 | 14:00–18:00 | ⚠ squarely the workday — peak-priced |
| Central Europe (UTC+2) | 03:00–06:00 | 08:00–12:00 | ⚠ mornings peak, afternoons free |
| US Pacific (UTC−7) | 18:00–21:00 (prev. day) | 23:00–03:00 | ✓ the workday is entirely off-peak |

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](https://www.infoworld.com/article/4209439/deepseek-raises-some-v4-prices-by-more-than-10x-as-ai-demand-strains-capacity.html):
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 peak-pricing playbook: learn your traffic's clock, make workloads movable, put the decision in a layer](/blog/images/time-as-a-pricing-variable-peak-playbook.png)

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:

```json
{
  "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](https://pirouter.ai/models)) 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.

---

## Sources

### api-docs.deepseek.com

- [DeepSeek API docs](https://api-docs.deepseek.com/quick_start/pricing)

### venturebeat.com

- [VentureBeat puts the sharpest jump at up to 1,100%](https://venturebeat.com/orchestration/deepseeks-top-ranked-v4-flash-stumbles-on-real-agent-tasks-as-its-prices-surge)

### z.ai

- [GLM-5.3 shipped on 2026-08-14](https://z.ai/blog/glm-5.3)

### infoworld.com

- [InfoWorld's read is the same](https://www.infoworld.com/article/4209439/deepseek-raises-some-v4-prices-by-more-than-10x-as-ai-demand-strains-capacity.html)