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.

What actually changed

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:

• DeepSeek V4 Flash, off-peak: $0.22 input (cache miss), $0.66 output, $0.007 cache hit.
• DeepSeek V4 Flash, peak: $0.44 input, $1.32 output, $0.014 cache hit.
• DeepSeek V4 Pro, off-peak: $0.66 input, $1.98 output, $0.022 cache hit.
• DeepSeek V4 Pro, peak: $1.32 input, $3.96 output, $0.044 cache hit.

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.

What Hacker News figured out first

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:

• The full before/after table. One commenter laid out every model's old, off-peak, and peak rates with the multipliers (Flash input 1.6x off-peak, 3.1x peak; output 2.4x and 4.7x; Pro cache hit 6.1x and 12.1x). It matches the official page exactly.
• The cache-hit warning for agentic tools. The sharpest comment in the thread notes the 6x off-peak and 12x peak jump on Pro cache hits, since cache hits can make up 90% or more of input on long agent sessions. As the commenter put it, this "will put an end to those 'I used 1 billion tokens and spent $4' reports."
• The peak hours map to China's workday. Another commenter observed that peak hours are working hours in China, night in the US and Europe. DeepSeek's pricing is shaped by its domestic traffic, and everyone else gets to schedule around it.
• Open weights mean you have an exit. A commenter pointed out that other providers on OpenRouter still sell the same open-weight models at the old prices, or lower. The pricing change is DeepSeek-first-party; the ecosystem around it moves slower.
• The sticker shock is real. One developer estimated their $5 a month DeepSeek bill becomes $15, and another flagged that peak Flash output at $1.32 is above the cheapest OpenRouter provider at $0.16.

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?"

What this means for Java and Spring Boot teams

For anyone building AI features in Java, this change splits your workloads into three groups:

• Shift this to off-peak. Batch summarization, nightly embedding jobs, evaluation runs, report generation, anything a cron job can own. These do not care if they finish at 3 AM UTC. In Dhaka time, off-peak covers 4 PM to 7 AM plus 10 AM to 12 PM, so a nightly batch at 10 PM or 2 AM lands squarely in the cheap window.
• Keep this on-peak, and pay for it. Interactive chat, anything a user is waiting on. You cannot schedule a user's question. But you can measure it: log the estimated cost per request and watch the peak-hours line grow.
• Rethink the cache-heavy stuff. Long agent sessions with big static prompts are where the 6x to 12x cache-hit jump bites. If your agent re-sends a 200k-token system prompt with a small changing tail, most of your input is cache hits, and that is precisely the line that got expensive. Structure prompts so the stable prefix comes first and the changing part comes last, and treat cache-hit ratio as a first-class metric, not a footnote.

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.

The build: a cost-aware scheduling layer

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.

The checklist before you run a bill through it

• Move the cron-able work first. Embeddings, nightly evals, digest generation. These are pure savings: same output, half the price.
• Instrument cache-hit ratio. If 80% of your input tokens are cache hits, the new cache-hit price is your real price. Log it per request and per session.
• Set the window in UTC, not server-local time. A server in Dhaka and a server in Frankfurt must agree on what "off-peak" means. zone = "UTC" on @Scheduled keeps the schedule honest.
• Re-check OpenRouter and other resellers. DeepSeek's first-party pricing changed, but the same open-weight models are still sold by other providers at older rates. A one-line base-URL change in Spring AI is your cheapest mitigation.
• Re-run your cost estimates after August 16. The old flat-rate math is dead. If your spreadsheets still say $0.435 for V4 Pro input, they are wrong twice: the price moved, and it now depends on the hour.

What I would do differently

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?"