How to Cut LLM Costs With Off-Peak API Pricing

DeepSeek Just Turned the Lights On for LLM Pricing

On August 16, 2026, DeepSeek quietly rewired how its most-used API endpoints charge for compute. V4-Flash and V4-Pro moved to a UTC-based peak and off-peak pricing schedule, with output tokens and, more consequentially, cache-hit tokens now costing different amounts depending on when a request lands. Some cache-hit prices jump by more than 10x during peak hours. On the surface, this reads like a routine price adjustment from a vendor trying to lift revenue. Underneath, it is the first time a major LLM provider has made a structural admission: intelligence has a physical capacity constraint, and that constraint has a clock attached to it.

What Changed on August 16

The mechanics are straightforward. Instead of a flat per-token rate that applies at any hour, V4-Flash and V4-Pro now split the day into peak and off-peak windows defined in UTC. Output pricing shifts between the two windows, and cache-hit pricing, the rate charged when a request reuses a previously processed prompt prefix, shifts by a much larger margin. That second detail is the one worth sitting with, because cache-hit pricing has quietly become the backbone of how modern agent systems keep their bills manageable.

For readers comparing this against other frontier releases, it's worth placing DeepSeek's move alongside the wider pricing conversation this year, including the head-to-head look at DeepSeek V4 Pro vs Grok 4.6 on price and agent benchmark gains, and the commoditization trend flagged when Claude Opus 5 launched at roughly half its predecessor's price. Both stories were about the sticker price falling. This one is about the sticker price becoming conditional on time of day, which is a different kind of change entirely.

Why Cache Pricing Is the Real Story

Most public commentary on LLM pricing fixates on the per-million-token rate, because it is the easiest number to put in a comparison table. But for any system that runs a long conversation, repeats similar queries, or loops a tool call multiple times inside an agent workflow, the price that actually determines the monthly bill is the cache-hit rate, not the headline rate. Prompt caching works by storing the computed state of a prompt prefix so that a follow-up request referencing the same prefix doesn't have to reprocess it from scratch. In agent systems, where a model might re-read the same system prompt, the same tool schema, and the same accumulated conversation history dozens of times within a single task, cache hits can represent the overwhelming majority of total token volume.

Until now, that cache-hit volume was priced close to free. That pricing choice, whether intentional or not, functioned as a subsidy. It rewarded exactly the workloads that are hardest on infrastructure: long-running agent loops, tool-calling chains, and repeated queries against the same context window. Anyone building on top of models like Claude Sonnet 5 in agent-heavy configurations, a pattern discussed in the piece on Claude Sonnet 5 running agent workloads, or wiring multi-step tool loops the way the teardown of Claude Code's 512,000 lines of TypeScript exposed, has effectively been operating under that hidden discount for as long as aggressive prompt caching has existed.

The End of the Near-Free Cache Subsidy

Removing that subsidy, even partially and only during peak hours, changes the economics of exactly the workloads that agent builders have been scaling the fastest. A long conversation that reuses context ten or twenty times over an hour used to cost close to what a single short exchange costs. Under the new peak pricing, that same conversation, if it happens to run during a busy UTC window, can cost meaningfully more, because the cache-hit multiplier is no longer negligible.

This is the part of the DeepSeek change that deserves more attention than it has received. The framing that circulated when the news broke treated it as a straightforward vendor price increase. The more accurate framing is that long-horizon, tool-heavy tasks are, for the first time, being asked to confront the actual physical capacity of the data centers processing them. Compute has always been finite. Pricing had simply not been reflecting that scarcity at the times when it matters most.

Intelligence as a Utility, Not a Bargain

The comparison that keeps surfacing around this shift is electricity. For years, the working metaphor in AI commentary has been that intelligence is becoming "cheap like water and electricity," implying an ever-falling flat rate. Peak and off-peak API pricing suggests the metaphor was half right and incomplete. Electricity itself isn't priced flat everywhere. Grids that face real capacity constraints during the day use time-of-use rates specifically to shift demand into cheaper, less congested hours. DeepSeek's move applies the same logic to inference capacity.

That reframing matters because it connects pricing directly to physical infrastructure rather than to a vendor's discounting strategy. The broader inference capacity story, including why chip supply for running models is arguably a bigger constraint than chip supply for training them, was laid out in the analysis of China's AI chip anxiety being really about inference, not training. Peak pricing is the commercial expression of exactly that constraint: when everyone's agents fire tool calls during the same daytime hours, the data center has to serve all of it at once, and someone has to pay for the headroom that requires.

What This Means for Agent Builders

The practical consequence lands hardest on anyone running agentic systems: coding agents, research loops, customer-support bots, or any pipeline that chains multiple model calls together. These systems were the biggest beneficiaries of near-free caching, and they are now the biggest exposed party when that subsidy is withdrawn during peak hours. The debate over where the real competitive battleground sits in agent development, covered in the piece on the harness war shifting the battlefield away from the model itself, gains a new dimension here: the harness now also has to manage when a task runs, not just how it's structured.

Comparing API providers by headline per-million-token price alone is no longer sufficient. Two providers can post identical flat rates and still produce very different bills once cache-hit multipliers and time-of-day windows are factored in. Builders who evaluate a new model purely on its listed price, without checking how caching is priced across the full day, will be underestimating their actual production costs the moment a workload runs during a peak window.

How to Actually Schedule Workloads Now

The direct response to time-of-use API pricing is the same response power-hungry industries have used for decades: shift what can be shifted into off-peak windows. For agent systems, that means separating latency-sensitive, user-facing calls (which have to run whenever the user shows up) from batch or background work that doesn't (index rebuilding, bulk summarization, evaluation runs, scheduled reports, and any agent task that can tolerate running a few hours later).

• Route real-time, user-facing requests as before, and accept that they will sometimes land in a peak window.
• Push batchable, non-interactive workloads, evaluation suites, nightly summarization, large-scale document processing, into off-peak UTC windows deliberately.
• Audit which agent loops are burning the most cache-hit volume and estimate their cost under both peak and off-peak rates before assuming a flat average.
• Treat smaller, locally deployable models as a genuine cost hedge for workloads that don't need frontier-level reasoning, rather than a fallback used only when API budgets run out.

That last point connects directly to a parallel trend: as hosted API pricing gets more time-sensitive, the appeal of running smaller models locally grows. The comparison of Qwen3.8-27B against Qwen3.8-Max for local deployment and the case made for tiny on-device capability in Liquid AI's LFM2.5-350M proving agent skills don't need billions of parameters both point toward the same off-ramp: workloads that can be handled locally sidestep peak pricing entirely, because there's no shared data center clock to negotiate with.

The Broader Pricing Landscape

DeepSeek is not moving in isolation. The open-weight model market has been repricing aggressively all year, visible in the scale-driven economics behind Kimi K3's 2.8-trillion-parameter release rewriting who sets the price of intelligence, and in the falling frontier prices signaled by Claude Opus 5. What makes the DeepSeek change distinct is that it doesn't lower a number, it adds a dimension. Price is no longer just a function of model and token count; it is now also a function of time. Anyone still comparing providers with a single static rate card is comparing an incomplete picture.

The self-hosted alternative for teams that want full control over both cost and scheduling was also on display in Block's open-source Goose, a local, model-agnostic coding agent, which sidesteps hosted-API pricing structures entirely by running against whatever backend, hosted or local, a team chooses hour by hour.

What to Watch Next

The open question is whether peak and off-peak pricing stays a DeepSeek-specific move or becomes standard practice across the industry as inference demand keeps climbing. If other providers follow, the API comparison tables that currently list a single price per million tokens will need an additional column: not just the rate, but the hours it applies to. Cheap intelligence isn't disappearing. It's becoming schedule-dependent, available in the off-peak hours, in local models, and to whoever has bothered to build the scheduling logic to take advantage of it.