AI Compute Is Becoming a Scheduled Purchase

Key takeaway

DeepSeek's new peak and off-peak API prices turn inference timing into an operating decision. Teams that can queue work, reuse cached context and tolerate delayed completion can materially change unit cost; teams that cannot will pay for immediacy.

What's changing

AI buyers have spent the past two years comparing models by capability and price per token. DeepSeek has added a third variable: when the tokens are processed.

On August 13, DeepSeek released V4-Pro across its app, web product and API. The model announcement includes the usual capability claims, but the consequential part for operators sits in the billing note. From August 16, V4-Pro and V4-Flash API usage will carry different prices during peak and off-peak windows. Off-peak rates will be half the peak rate. DeepSeek explicitly says the structure is intended to encourage customers to schedule tasks around available capacity.

For V4-Pro, one million uncached input tokens will cost $1.32 at peak and $0.66 off peak. One million output tokens will cost $3.96 at peak and $1.98 off peak. Cached input will cost $0.044 at peak and $0.022 off peak. Peak hours are 01:00-04:00 and 06:00-10:00 UTC; every other hour is off peak.

Those rates are also a significant increase from the model's current prices. Before the change, V4-Pro costs $0.435 per million uncached input tokens and $0.87 per million output tokens. The peak output price will therefore be more than four times the current rate. Even the off-peak output price will be more than double it. DeepSeek is not simply discounting spare capacity. It is repricing the product while giving flexible workloads a way to reduce the increase.

The DeepSeek pricing page makes the trade explicit. V4-Pro supports a one-million-token context window, up to 384,000 output tokens and 500 concurrent requests. DeepSeek's August 13 change log also adds three reasoning-effort settings and native support for the Responses API. More capable, longer-running agent work can consume more tokens and hold capacity for longer. Time-based pricing is a rational way to allocate that scarce capacity.

Why it matters

The change exposes a cost that flat token pricing tends to hide. A model endpoint is not an infinitely elastic utility. It is a shared system with expensive accelerators, power, memory, networking and queuing constraints. When every customer wants high-throughput reasoning during the same working hours, the provider must add capacity, slow requests or use price to move demand.

DeepSeek has chosen price. That choice makes AI infrastructure procurement look more like cloud spot capacity, electricity tariffs or airline yield management than a conventional software seat. The customer is no longer buying only intelligence. It is buying intelligence with a delivery time.

This matters most for agentic workloads. A customer-support response may require low latency because a person is waiting. A nightly catalog enrichment job, code migration, compliance scan or research batch often does not. Putting both jobs through the same model, at the same priority and at the same time wastes money. It also makes finance teams blame the model for costs caused by poor scheduling.

Caching becomes more valuable under the new schedule, but it is not a complete answer. The peak cached-input rate for V4-Pro rises from $0.003625 to $0.044 per million tokens. That remains far cheaper than an uncached request, yet the increase is large enough to justify better cache measurement. Operators need to know which prompts repeatedly miss the cache because of unstable system instructions, unnecessary context changes or fragmented request design.

The broader signal is that headline token prices are becoming less useful. A credible unit-cost model now needs at least five inputs: cache-hit rate, input-to-output ratio, reasoning effort, latency class and time of execution. A provider can advertise a low off-peak rate while the customer's actual workload lands in the expensive window. Conversely, a seemingly costly model can be economical if it completes the job with fewer retries and less human review.

What operators should do

Start by classifying AI work according to latency rather than department. Interactive tasks should have a response-time objective. Batch tasks should have a completion deadline. Background tasks should be interruptible and movable across windows. This classification should live in routing policy, not in a spreadsheet that engineers consult occasionally.

Next, instrument cost per completed job. Tokens are an input, not the outcome. Measure how many requests, retries, tool calls and human corrections are required to resolve a ticket, enrich a product, review a contract or ship a code change. Record the provider, model, effort level, cache status and execution window alongside the result.

Then create explicit scheduling rules. A batch with a 9 a.m. local deadline can often start during the provider's off-peak period. A multinational operator may route work regionally or stagger background jobs. The savings should be tested against queue failures, delayed exceptions and the cost of keeping orchestration systems running longer.

Finally, put pricing volatility into vendor selection. Contracts and internal forecasts should model peak rates, not the lowest published number. Teams should preserve model portability for workloads that can tolerate it, while recognizing that switching costs include prompt behavior, tool interfaces, safety review and output quality. Cheap tokens are not cheap if migration breaks the workflow.

Bottom line

DeepSeek's schedule does not prove that every AI provider will introduce time-of-use pricing. It does show that inference capacity has a clock. Operators that treat latency as a uniform requirement will pay for urgency they do not need. The next stage of AI cost control is not another round of prompt trimming. It is deciding which work must happen now, which work can wait and how much that difference is worth.