Peak vs Off-Peak AI API Pricing: How Time of Day Changes Your Bill

For a decade, the price of an API call was a constant: a number per million tokens that you could paste into a spreadsheet and trust. That assumption is now dead. DeepSeek publishes two price cards for the same model separated only by a time window. OpenAI attaches expiration dates to promotional rates. Prompt caching turns repeated context into a fraction of the list price. The variable is no longer just what you run; it is when, how often, and with what residency.

If your cost model still assumes a flat rate, it is optimistic on the hours that matter most. Here is how the new price cards actually work, with the arithmetic.

Why the price card became a function

The old model was price(model). The current model is closer to:

[object Object]

Four modifiers show up again and again across the major labs, and each one is published rather than hidden. What changed is that they are now applied to a schedule: the Google-style "always 50% off for batch" is joined by time-of-day pricing and dated promotions. A single workload moved four hours earlier can change cost by 50% without a line of code changing.

DeepSeek: the clearest published example

DeepSeek is the cleanest case because it publishes the whole thing on one page. The official API pricing documentation↗ lists each model twice, with off-peak and peak columns:

Peak hours are Monday to Friday, 01:00–04:00 and 06:00–10:00 UTC. Every other hour — evenings, most of the Western working day, and the entire weekend — is off-peak, at exactly half the peak rate.

What share of the week is actually peak?

Do the arithmetic before you assume this is a niche discount. Peak is 3 hours plus 4 hours, so 7 hours per weekday, and 5 weekdays:

• Peak hours per week: 7 × 5 = 35 hours
• Total hours per week: 168 hours
• Share of the week at peak pricing: 35 ÷ 168 ≈ 20.8%

Roughly four fifths of the week is off-peak. For any workload that is not tied to business hours, time-of-day pricing is not an edge case — it is the default state of the calendar, and the peak window is the exception you schedule around.

Worked example: a nightly summarization pipeline

Suppose you run a document pipeline that consumes 8M input tokens and 2M output tokens per day on deepseek-flash.

Off-peak, on the $0.15 / $0.60 card:

• Input: 8 × $0.15 = $1.20
• Output: 2 × $0.60 = $1.20
• $2.40 per day → about $72 per 30-day month

Move the same pipeline into a peak window at $0.30 / $1.20:

• Input: 8 × $0.30 = $2.40
• Output: 2 × $1.20 = $2.40
• $4.80 per day → about $144 per 30-day month

Nothing changed except the clock. The 50% discount is structural, which means the difference between $72 and $144 is a cron expression.

On the v4-pro card at $0.66 / $1.98 off-peak, the same token volumes cost $9.24 per day off-peak against $18.48 at peak — the schedule scales with the tier you choose.

Cache pricing is a second, independent schedule

The same DeepSeek pricing page states a cache-hit rate of $0.003 per 1M input tokens for Flash. Against the off-peak cache-miss input rate of $0.15 per 1M, a cache read costs about 2% of a miss — a reduction of roughly 98% on that slice of the request.

That is not an optimization layered on top of the schedule; it is a second schedule that runs on repetition rather than on the clock. Worked out on the same 8M-token input volume, assuming the input is a stable system prompt and document set that caches cleanly:

Three scenarios, same workload, a spread of roughly 4× between the worst and the best. The economics of caching flip after the second request that shares the same context: the first call pays the miss, every later call pays the read rate.

OpenAI: promos with an expiration date

OpenAI's pricing documentation↗ does something rarer in this industry: it dates its numbers. The current promotional rate for its flagship is listed with an explicit "available at least through" date, with the previous, higher rate struck through above it.

Two budgeting lessons follow.

1. Budget at the post-promo price. If your unit economics only work at the promotional number, your unit economics have an expiry date. Treat the discount as upside, not baseline, and model the struck-through rate as steady state.
2. The struck-through number is real data. It tells you the vendor's own anchor for the model's durable price. That is the number to carry into any forecast that outlives the promotion.

Combine that with the standard modifier menu — a 50% batch discount, cached-input pricing, and a residency premium — and the headline rate becomes the least informative number on the page. The headline is what you pay when none of the modifiers apply, which for a production workload is increasingly the exception.

The modifier stack, side by side

Anthropic states its own stacking rules on its pricing page↗: batch at 50%, cache reads at a small multiple below list with an even lower rate on its newest model, and US-only inference at a premium above the base rate. Read the page for the current multipliers before you put them in a model, because these numbers move.

How the stack multiplies: an illustration

Take a hypothetical $10.00 per 1M input rate and apply the published multipliers from the table above in sequence:

The illustration uses a round base rate deliberately: the point is the mechanism, not a specific vendor quote. A cached, batched, residency-scoped request can land at a small fraction of the flat headline rate — and the flat rate is what you pay when none of the modifiers apply.

Caveat worth repeating: the order and stackability of these modifiers is provider-specific. Some apply cache and batch independently; some treat residency as a surcharge on top of the discounted rate. The only safe source is the modifiers section of your provider's own pricing page, read on the day you do the budget.

What this means for free tiers

Free tiers interact with the schedule in two ways that are easy to miss.

The value of an allowance is now time-dependent

A daily token allowance does not change with the clock, but its dollar value does. Take a free tier limited to 200,000 tokens per day per model, where the provider's paid rates for those models run from $0.22 to $3.00 per 1M input tokens:

• At $0.22 per 1M: 200,000 tokens ≈ $0.044 of value
• At $3.00 per 1M: 200,000 tokens ≈ $0.60 of value

Same allowance, same nominal size, a spread of roughly 13× in dollar value depending on which model you spend it on. Add a peak/off-peak card on top and the same 200,000 tokens buy half the output during peak hours that they buy off-peak. "Free tokens per day" is therefore an incomplete unit: the comparable metric is free tokens per day on a named model, in a named window.

The pattern you learn free is the pattern you pay for later

If your workload only fits inside a free tier when it runs during certain hours, that is a preview of your paid future. Free tiers are small enough that you can discover the shape of your traffic cheaply: which jobs are latency-sensitive, which can wait, and which repeat identical context often enough to cache. Take those three findings with you into paid capacity and you keep spending the off-peak rate.

The scheduling patterns that pay

Three patterns cover most of the recoverable money.

1. Off-peak default. Put everything non-latency-sensitive on a scheduler that prefers off-peak windows. On a DeepSeek-style card, on a fully schedulable workload, that is a 50% line item rather than a rounding error.
2. Cache-first. Structure repeated system prompts, reference documents, and few-shot blocks so the provider's cache actually hits. Measure the cache-hit share in your usage logs; a cache that never hits looks identical to no cache at all on the invoice dimension.
3. Batch the tail. End-of-day evaluation, reporting, and backfill jobs belong in the batch API at −50%, landing inside off-peak where the provider applies time-of-day pricing to batch traffic.

A minimal scheduler that encodes the rule:

[object Object]

Two operational details matter more than the code. First, keep the windows as configuration, not constants — providers edit them, and a hard-coded window silently becomes wrong. Second, log the window each job actually ran in, because that log is what lets you reconstruct an invoice that looks higher than the schedule predicted.

How we verified this

How we verified this (2026-09-17): we read the DeepSeek API pricing documentation↗ directly and recorded the peak windows and per-1M rates from the page itself, rather than from a summary. We then opened the OpenAI pricing page↗ and the Anthropic pricing page↗ to confirm which modifiers each vendor publishes and to note that promotional rates carry explicit dates. Every dollar figure in this article either comes from those official pages or is our own arithmetic over those published rates; where a vendor's number was not on an official page we describe the mechanism qualitatively instead of quoting a figure.

Caveats the marketing copy leaves out

• Time-of-day pricing is not universal. It is a published feature at some providers and absent at others. Do not plan for a discount that does not exist on your provider's card.
• Scheduling has a cost. Queueing work for a cheaper window adds latency and one more moving part. For a user-facing feature, the 50% saving is irrelevant; for a nightly pipeline, it is the whole budget.
• The windows are UTC. A peak window defined in UTC lands squarely inside the working day for some regions and in the middle of the night for others. Convert before you design an SLA around it.
• Promotions can be withdrawn, and models get renamed. A price card is a snapshot. Keep your own copy of the rate you budgeted against, with the date you read it.

The budget formula, in one line

Treat the price sheet as a function of state rather than a constant: price(model, when, cached, batch, residency). Fill in the schedule from the provider's own documentation, fill in the modifier multipliers from the same page, and run the arithmetic on your real token volumes — the worked example above shows the same workload moving from $4.80 to $1.22 a day without a single architectural change. The constants are gone. The function is the budget.