DeepSeek Now Prices Tokens Like Electricity: 50% Off-Peak Discount and a Spring Boot Pattern to Profit From It

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).

Then the pricing update landed, and tokens suddenly have rush hour.

DeepSeek's official announcement 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 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 (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?"