In April 2024, DeepSeek-V2's $0.14/M price helped start the first large AI price war. In April 2026, DeepSeek-V4 repeats the challenge with an architecture built to lower long-context work. An API invoice has more than one number. Input is the text the service must read, output is the text it generates, and a cache hit is input whose earlier computation the service can reuse. A cache miss is new input that must be processed into a fresh key-value cache. Each rate below is priced per million tokens, where a token is the small unit of text a model reads and produces. The distinction matters because a long request has two kinds of work. Prefill reads the prompt and writes its memory state. Decode produces the response token by token from that state. Reusing a prefix can lower prefill work, but it does not remove the cost of new output. The earlier chapters explain why compressed attention, FP4 experts, 13B active parameters, and reusable on-disk caches can change those three lines at once.
How to read the price table
Why prices differ by time
The July change adds a time-of-day grid. Peak hours, when the service expects higher demand, pay the full rate. Off-peak hours pay half. This is a capacity-management tool borrowed from electricity markets. A batch agent that can wait until 3am, such as a long repository analysis, can move to less-contended hours. Work that needs a person's immediate response can pay to run during the busy period. In the table's snapshot, the peak input figure is $0.22, higher than the $0.14 launch figure, while the off-peak input figure is $0.11. The point of separating the rows is to keep the cluster busy across more of the week rather than treating every request as equally urgent. The official schedule defines peak as 01:00 to 04:00 and 06:00 to 10:00 UTC on weekdays. That is 35 of 168 weekly hours, leaving 79% of the week at off-peak rates. The mechanism is ordinary capacity planning: a lower price invites delayable work into time that would otherwise leave accelerators underused. We also need to read the table as a set of snapshots rather than a single universal rate. The launch row, the later first-party row, and the OpenRouter listing refer to different dates, routes, and in some cases different releases. A provider can price the same open weights differently because it owns a different serving fleet, manages a different cache, or chooses a different margin. That is why cache-heavy and output-heavy workloads should not be compared with one input number alone. A repeated system prompt can benefit from a cache-hit rate. A request that emits a long answer still pays the output rate for every newly decoded token. The price question is therefore a workload question: how much of the prompt repeats, how much is new, how much output the task needs, and when the work can run.
Estimate an agent workload
Drag the token and cache sliders. Compare each estimated bill.
Prices are from OpenRouter on 2026-08-31. V4-Flash pricing awaits its final listing, as noted in the research file. Estimate = cached input × cache price + fresh input × input price + output × output price.