# DeepSeek Now Prices Tokens Like Electricity: 50% Off-Peak Discount and a Spring Boot Pattern to Profit From It > Source: > Published: 2026-08-16 03:12:15+00:00 Three days ago I knew exactly what a DeepSeek call cost me. I had wired DeepSeek V4 Pro 0813 into a Spring Boot app with Spring AI, and the math was simple: $0.435 per million input tokens, $0.87 per million output tokens, and a cache-hit rate so aggressive that long agent sessions stayed embarrassingly cheap ([I wrote up the integration](https://dev.to/jamilxt/deepseek-v4-pro-is-out-heres-how-to-wire-it-into-spring-boot-with-spring-ai-213m)). Then the pricing update landed, and tokens suddenly have rush hour. DeepSeek's [official announcement](https://api-docs.deepseek.com/news/news260813/) introduces peak and off-peak billing: off-peak rates are 50% lower than peak, and the new prices take effect today, August 16, 2026 at 16:00 UTC (10 PM in Dhaka). The headline reads like a discount. The fine print is a price increase, and the difference matters a lot if you run batch workloads or agentic tools. Full disclosure up front: the new billing starts today, so I have not run a real bill through it yet. What I have done is read the price table carefully, watched the Hacker News thread do the math for two days, and built a scheduling pattern in Spring Boot that shifts heavy work into the off-peak window. That pattern is what I want to show you, because the interesting part is not the announcement. It is what the numbers actually mean. The [pricing page](https://api-docs.deepseek.com/quick_start/pricing) now splits every price into peak and off-peak tiers. Peak hours are 01:00 to 04:00 UTC and 06:00 to 10:00 UTC. Every other hour is off-peak, which is 17 out of 24 hours. Here are the new per-1M-token rates, straight from the page: The off-peak discount is real: every off-peak number is exactly half of its peak counterpart, which matches the announcement's "50% lower" claim. But compare those off-peak numbers to what DeepSeek charged before this change, and the picture inverts. V4 Pro was $0.435 input and $0.87 output at a flat rate. Off-peak is now $0.66 and $1.98, which is about 1.5x and 2.3x the old price. Peak is $1.32 and $3.96, roughly 3x and 4.6x. V4 Flash was $0.14 input and $0.28 output. Off-peak is 1.6x that, peak is 3x to 4.7x. The most aggressive jump is cache hits. V4 Pro cache-hit pricing went from $0.003625 to $0.022 off-peak and $0.044 peak. That is a 6x increase off-peak and a 12x increase at peak. So the honest summary is: DeepSeek did not cut prices. It introduced time-of-day pricing with a higher baseline, and it is offering a 50% discount off that new baseline for anyone who can move their work into the cheap hours. The [discussion thread](https://news.ycombinator.com/item?id=49285160) (128 points, 183 comments when I checked) did the multiplier math within hours, and a few comments are worth reading before you touch your config: That last one is the key insight: price comparisons are now time-dependent. "Is DeepSeek cheap?" is not a yes or no question anymore. It is "cheap at 11 PM, expensive at 9 AM, and how much of your traffic is cache hits?" For anyone building AI features in Java, this change splits your workloads into three groups: The pattern I use for the first group is a small scheduling layer. It does not touch your model code. It just makes the "when" a first-class decision. Start with scheduling enabled: ``` @Configuration @EnableScheduling public class AiBatchConfig { } ``` Then define the off-peak window exactly as DeepSeek defines it, in UTC: ``` @Component public class OffPeakWindow { private static final ZoneId UTC = ZoneId.of("UTC"); public boolean isOffPeak(ZonedDateTime now) { int hour = now.withZoneSameInstant(UTC).getHour(); // Peak: 01:00-04:00 and 06:00-10:00 UTC. Everything else is off-peak. return !((hour >= 1 && hour < 4) || (hour >= 6 && hour < 10)); } } ``` Now the batch job itself. The cron runs in UTC, so the schedule is stable regardless of where the server lives. 22:00 UTC is 04:00 in Dhaka, deep inside off-peak: ``` @Component public class NightlyEmbeddingJob { private static final Logger log = LoggerFactory.getLogger(NightlyEmbeddingJob.class); private final OffPeakWindow offPeakWindow; private final ChatClient chatClient; public NightlyEmbeddingJob(OffPeakWindow offPeakWindow, ChatClient chatClient) { this.offPeakWindow = offPeakWindow; this.chatClient = chatClient; } @Scheduled(cron = "${ai.batch.cron}", zone = "UTC") public void runBatch() { if (!offPeakWindow.isOffPeak(ZonedDateTime.now())) { log.warn("Skipping batch run: peak hours in UTC"); return; } // Heavy work: embeddings, summarization, eval runs. } } ai.batch.cron=0 0 22 * * * ``` The window check is a safety net, not the primary control. The cron is the primary control, and the check exists for the day someone changes the cron to 08:00 UTC and forgets what that costs. Defensive, cheap, and it turns a pricing policy into code. The second piece is an estimator, because a cost problem you cannot see is a cost problem you will not fix. Model the official table as data: ``` public record TokenPrice(double inputPerM, double outputPerM, double cacheHitPerM) {} public final class DeepSeekRates { public static final TokenPrice FLASH_OFF_PEAK = new TokenPrice(0.22, 0.66, 0.007); public static final TokenPrice FLASH_PEAK = new TokenPrice(0.44, 1.32, 0.014); public static final TokenPrice PRO_OFF_PEAK = new TokenPrice(0.66, 1.98, 0.022); public static final TokenPrice PRO_PEAK = new TokenPrice(1.32, 3.96, 0.044); private DeepSeekRates() { } } ``` Then a component that picks the right tier by hour and logs an estimate after every call: ``` @Component public class CostTracker { private final OffPeakWindow offPeakWindow; public CostTracker(OffPeakWindow offPeakWindow) { this.offPeakWindow = offPeakWindow; } public void track(String model, TokenPrice peak, TokenPrice offPeak, long cacheHitTokens, long inputTokens, long outputTokens) { boolean offPeak = offPeakWindow.isOffPeak(ZonedDateTime.now()); TokenPrice price = offPeak ? offPeak : peak; double cost = (cacheHitTokens / 1_000_000.0) * price.cacheHitPerM() + (inputTokens / 1_000_000.0) * price.inputPerM() + (outputTokens / 1_000_000.0) * price.outputPerM(); log.info("{} {} cost estimate: ${} (tokens: {} cache hit / {} input / {} output)", model, offPeak ? "off-peak" : "peak", cost, cacheHitTokens, inputTokens, outputTokens); } } ``` Wire `track(...)` wherever you call the model, and after a week you have a distribution: what your workload costs at each hour. That distribution is the thing to optimize, because the off-peak discount only helps the workloads you actually move. `zone = "UTC"` on `@Scheduled` keeps the schedule honest.The lesson here is not "DeepSeek raised prices." Every frontier provider will eventually do time-of-day or tiered pricing, because demand is diurnal and infrastructure is expensive to idle. The lesson is that model cost stopped being a constant, and my code was written as if it was. I have been building production AI systems with Spring Boot and Spring AI for over a year, and the first time I integrated a frontier model I hardcoded a price per million tokens in a constants file. That file is now a time function. The fix is not cleverer math, it is treating pricing like configuration: a table, a UTC clock, and a log line that makes the cost visible per call. When the next provider copies DeepSeek's playbook, you change the table, not the architecture. **Have you checked what your DeepSeek bill would look like under the new peak and off-peak rates? What workload are you planning to move into the off-peak window? I read every response.** I write about Java, Spring Boot, and AI every week. Subscribe, it's free. **Bookmark this one.** The next time a model provider announces a discount, your first question should not be "how much off?" It should be "off what baseline, and at what hour?"