The 50% discount is actually a price increase On September 10, 2026, DeepSeek pushed V4.1-Flash live on its API with a rate card split in two: $0.15 per million input tokens and $0.60 per million output tokens during "off-peak" hours, both doubling to $0.30 and $1.20 during seven "peak" hours on weekdays, with cache-hit input following the same split at $0.003 off-peak and $0.006 at peak. Source: TechBriefly, "DeepSeek launches V4.1-Flash with ultra-cheap off-peak API pricing" Read the launch post fast and it sounds like a loyalty discount for teams willing to shift work into the cheap hours. Read DeepSeek's own rollout of the same mechanic on V4-Flash and V4-Pro a month earlier and the sign flips: "off-peak," the supposedly cheap tier, priced 52% to 507% above the flat rate those same models charged the day before the split went live. Source: Digital Applied, "Off-Peak LLM Pricing Lands: Cheaper Hours, Higher Rates" The "50% off" is real, it's just 50% off a new, higher number, not 50% off what the workload cost in July. Two vendors split the day into peak and off-peak tokens: DeepSeek's two daily peak blocks and Z.ai/GLM's weekly peak block both land outside US business hours but overlap the European morning Two vendors, the same idea, two days apart DeepSeek wasn't first. Z.ai's GLM coding plan turned on its own peak/off-peak split on August 14, 2026, pricing Monday-Friday 14:00-18:00 UTC+8, four hours a week, as "peak," with every other hour, including both full weekend days, billed at half that rate. Source: Digital Applied, "Off-Peak LLM Pricing Lands: Cheaper Hours, Higher Rates" DeepSeek followed two days later, effective August 16, 2026 at 16:00 UTC, setting peak as 01:00-04:00 and 06:00-10:00 UTC, Monday through Friday, seven hours a day, off-peak the remaining seventeen. Source: Digital Applied, "Off-Peak LLM Pricing Lands: Cheaper Hours, Higher Rates" September's V4.1-Flash launch reused the exact same weekday windows on a new model, which makes this a standing policy, not a one-off experiment on an aging SKU. The August numbers are the ones worth budgeting off, because they're the only pair with a real "before" attached: | DeepSeek line item | Flat rate before split | Off-peak, now | Peak, now | |---|---|---|---| | V4-Flash cache-hit input | $0.0028 / M | $0.007 / M (+150%) | $0.014 / M | | V4-Flash cache-miss input | $0.14 / M | $0.22 / M (+57%) | $0.44 / M | | V4-Flash output | $0.28 / M | $0.66 / M (+136%) | $1.32 / M | | V4-Pro cache-hit input | $0.003625 / M | $0.022 / M (+507%) | $0.044 / M | | V4-Pro cache-miss input | $0.435 / M | $0.66 / M (+52%) | $1.32 / M | | V4-Pro output | $0.87 / M | $1.98 / M (+128%) | $3.96 / M | Source: Digital Applied, "Off-Peak LLM Pricing Lands: Cheaper Hours, Higher Rates" DeepSeek V4-Pro output tokens indexed to the flat rate before the split: 1.00x before, 2.28x on the new off-peak rate, 4.55x on the new peak rate Why now, in DeepSeek's own words DeepSeek's stated rationale ties directly to agent workloads, not general chat traffic: cache-hit charges "can account for a significant share of agent costs when systems repeatedly reread the same repository, tool definitions, system instructions or conversation history." Source: TechBriefly, "DeepSeek launches V4.1-Flash with ultra-cheap off-peak API pricing" That's a real cost center this blog has measured before, the repeated re-reading of a stable system prompt and tool schema that inflates agentic prompt-caching spend on every turn of a long agent loop. Splitting the clock into peak and off-peak windows gives DeepSeek a lever to shape when that re-reading happens, pulling predictable, automatable agent traffic toward the hours its infrastructure has spare capacity, without touching the sticker price for the hours it doesn't. Nobody publishes the underlying utilization numbers, but the incentive matches the same GPU-idle-time economics behind self-hosting's utilization tax: unused inference capacity at 3 a.m. UTC is a sunk cost either way, and pricing it separately from the mid-morning rush is the fastest way to pull demand toward it. Whose 9-to-5 is the discount hour A rate-card table doesn't show this part: both vendors' peak windows land squarely inside Asia-Pacific and European business hours, and outside US business hours entirely. Convert the blocks and the winners and losers sort by time zone, not by workload. US teams (Eastern or Pacific): DeepSeek's two daily peak blocks fall at 9 p.m.-midnight and 2-6 a.m. Eastern, entirely outside a standard workday. An interactive product built around US business hours runs at off-peak rates by default, no scheduling required. European teams (CEST): One DeepSeek peak block, 8 a.m.-noon CEST, sits directly on top of the first half of the workday. A team that wants the cheaper rate has to defer that morning's batch and eval traffic to the afternoon. Teams on GLM's coding plan: the single weekly peak window, 2-6 a.m. Eastern / 8 a.m.-noon CEST, is already off-hours for US and EU teams alike; an APAC team sees it land on an ordinary Monday afternoon instead. None of this is intentional, it's what happens when a vendor prices around its own infrastructure's local peak load. The effect on a global team's bill is the same either way. A new axis, not a replacement for the old ones Time-of-day pricing doesn't compete with batch inference, prompt caching, or model routing, it stacks alongside them, and it fails differently than each. Batch inference already discounts roughly 50% off standard pricing at both OpenAI and Anthropic, but trades a real latency hit, hours instead of seconds, for that discount, at any time of day. DeepSeek and GLM's split keeps synchronous, seconds-scale latency available around the clock, but only discounts specific windows, so the trade isn't speed for price, it's scheduling flexibility for price. A workload has to be movable in time, not necessarily slower, to benefit, and DeepSeek has already shown once this year that its rate card moves fast enough to change the routing math between one post and the next. That distinction matters for the stacking order this blog has mapped before: compression shrinks what gets sent, caching avoids resending what's already been seen, routing picks the cheapest model that clears the quality bar, and time-of-day pricing now adds a fourth lever that has nothing to do with the request's content or the model answering it, only when the request fires. Stack all four and a nightly batch of agent evals, re-run against a cached system prompt, routed to the cheapest model that holds quality, fired inside a provider's off-peak window, compounds the way Nadir's own architecture already compounds routing with compression and caching, each lever cutting a cost the others don't touch. Four questions before you schedule around someone else's clock Sort traffic into movable and fixed before touching a scheduler. Nightly agent evals, backfills, and batch summarization jobs can wait for a cheap window. A customer-facing chat completion cannot. Time-of-day pricing only pays off on the first kind. Convert the peak window into your own team's time zone, not UTC. DeepSeek's 01:00-04:00 and 06:00-10:00 UTC reads as an abstraction until it's 9 p.m.-midnight and 2-6 a.m. Eastern, or 8 a.m.-noon CEST. One of those is free money against a US team's existing schedule. The other is a scheduling problem to solve before the discount means anything. Compare off-peak to the old flat rate, not to peak. The 50%-off headline is real only against the vendor's own new peak price. Check it against what the same model cost the week before the split existed, the way this post checked it against DeepSeek's own August numbers, before assuming the new floor is actually a discount. Don't let a clock decide what a quality bar should decide. A request that needs frontier-tier reasoning doesn't get cheaper because it's midnight in Beijing, it gets cheaper because a smaller model can answer it just as well. Time-of-day pricing is a multiplier on top of whichever model answers the call, not a substitute for choosing the right one. import openai client = openai.OpenAI( base_url="https://api.getnadir.com/v1", api_key="YOUR_NADIR_KEY", ) response = client.chat.completions.create( model="auto", messages=conversation_history, Time-of-day pricing is a scheduling decision your job queue makes before the call fires. Model selection is a quality decision the router makes on every call, regardless of the hour. Stack them: defer the movable batch job into a provider's off-peak window, then let auto route it to the cheapest model that still clears your quality floor once it runs, instead of paying an off-peak rate for a model the request never needed. ) print(response.model) metadata = response.model_extra["nadir_metadata"] print(metadata["cost"]["total_cost_usd"]) The cheapest hour is still the wrong model paying it A request routed to a model it never needed pays the off-peak discount and still overpays, because the multiplier lands on the wrong number. Start free and route every request against a quality floor first, so whichever hour it fires in, it's already running on the cheapest model that clears your bar, then layer your own team's off-peak scheduling on top for the traffic that can actually wait. For the rest of the stack, see the complete guide to cutting LLM API costs. FAQ Q: What is off-peak or time-of-day LLM pricing, and which providers use it? A: It's an API pricing model that charges a different per-token rate depending on the clock hour a request runs, rather than one flat rate all day. Z.ai's GLM coding plan turned it on August 14, 2026, and DeepSeek followed on August 16, 2026, then carried the same mechanic into its V4.1-Flash launch on September 10, 2026. As of this post, no other major lab publishes time-of-day pricing. Q: Is DeepSeek's off-peak rate actually cheaper than what it charged before the split? A: Not against its own prior flat rate. When DeepSeek introduced the split on August 16, 2026, the new "off-peak" tier priced 52% to 507% above what V4-Flash and V4-Pro charged the day before, depending on the line item. The 50% figure DeepSeek advertises is real only as a comparison against its own new, higher peak rate, not against what the workload cost before the split existed. Q: What are the exact peak windows for DeepSeek and GLM? A: DeepSeek's peak windows are 01:00-04:00 and 06:00-10:00 UTC, Monday through Friday, seven hours a day. GLM's peak window is Monday-Friday 14:00-18:00 UTC+8, which converts to 06:00-10:00 UTC, the same block as DeepSeek's second daily window. Both fall outside standard US business hours and overlap the European morning. Q: How is time-of-day pricing different from batch inference discounts? A: Batch inference at OpenAI and Anthropic discounts roughly 50% off standard pricing at any hour, in exchange for hours instead of seconds of latency. DeepSeek and GLM's off-peak pricing keeps normal, synchronous latency available around the clock, but only discounts specific time windows. The trade isn't speed for price, it's scheduling flexibility for price, so a workload only benefits if it can be moved in time, not necessarily if it can tolerate being slower. Q: How should a team decide what to move into a provider's off-peak window? A: Start by separating movable traffic, like nightly agent evals, backfills, and batch summarization, from fixed, latency-sensitive traffic like customer-facing chat completions. Convert the provider's UTC peak window into your own team's local time before assuming it helps you. Then compare the new off-peak rate to what the model cost before any split existed, not just to the new peak price, since the discount is only real against the right baseline. Time-of-day pricing is a scheduling lever on top of model choice, not a replacement for routing each request to the cheapest model that still clears its quality bar.