{"slug": "deepseek-now-prices-tokens-like-electricity-50-off-peak-discount-and-a-spring-to", "title": "DeepSeek Now Prices Tokens Like Electricity: 50% Off-Peak Discount and a Spring Boot Pattern to Profit From It", "summary": "DeepSeek introduced time-of-day pricing with peak and off-peak rates, where off-peak is 50% lower than peak but still higher than previous flat rates, effectively raising baseline prices. A developer built a Spring Boot scheduling pattern to shift batch workloads into the off-peak window, highlighting that price comparisons are now time-dependent.", "body_md": "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)).\n\nThen the pricing update landed, and tokens suddenly have rush hour.\n\nDeepSeek'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.\n\nFull 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.\n\nThe [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.\n\nHere are the new per-1M-token rates, straight from the page:\n\nThe off-peak discount is real: every off-peak number is exactly half of its peak counterpart, which matches the announcement's \"50% lower\" claim.\n\nBut 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.\n\nThe 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.\n\nSo 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.\n\nThe [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:\n\nThat 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?\"\n\nFor anyone building AI features in Java, this change splits your workloads into three groups:\n\nThe 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.\n\nStart with scheduling enabled:\n\n```\n@Configuration\n@EnableScheduling\npublic class AiBatchConfig {\n}\n```\n\nThen define the off-peak window exactly as DeepSeek defines it, in UTC:\n\n```\n@Component\npublic class OffPeakWindow {\n\n    private static final ZoneId UTC = ZoneId.of(\"UTC\");\n\n    public boolean isOffPeak(ZonedDateTime now) {\n        int hour = now.withZoneSameInstant(UTC).getHour();\n        // Peak: 01:00-04:00 and 06:00-10:00 UTC. Everything else is off-peak.\n        return !((hour >= 1 && hour < 4) || (hour >= 6 && hour < 10));\n    }\n}\n```\n\nNow 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:\n\n```\n@Component\npublic class NightlyEmbeddingJob {\n\n    private static final Logger log = LoggerFactory.getLogger(NightlyEmbeddingJob.class);\n\n    private final OffPeakWindow offPeakWindow;\n    private final ChatClient chatClient;\n\n    public NightlyEmbeddingJob(OffPeakWindow offPeakWindow, ChatClient chatClient) {\n        this.offPeakWindow = offPeakWindow;\n        this.chatClient = chatClient;\n    }\n\n    @Scheduled(cron = \"${ai.batch.cron}\", zone = \"UTC\")\n    public void runBatch() {\n        if (!offPeakWindow.isOffPeak(ZonedDateTime.now())) {\n            log.warn(\"Skipping batch run: peak hours in UTC\");\n            return;\n        }\n        // Heavy work: embeddings, summarization, eval runs.\n    }\n}\nai.batch.cron=0 0 22 * * *\n```\n\nThe 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.\n\nThe 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:\n\n```\npublic record TokenPrice(double inputPerM, double outputPerM, double cacheHitPerM) {}\n\npublic final class DeepSeekRates {\n\n    public static final TokenPrice FLASH_OFF_PEAK = new TokenPrice(0.22, 0.66, 0.007);\n    public static final TokenPrice FLASH_PEAK    = new TokenPrice(0.44, 1.32, 0.014);\n    public static final TokenPrice PRO_OFF_PEAK  = new TokenPrice(0.66, 1.98, 0.022);\n    public static final TokenPrice PRO_PEAK      = new TokenPrice(1.32, 3.96, 0.044);\n\n    private DeepSeekRates() {\n    }\n}\n```\n\nThen a component that picks the right tier by hour and logs an estimate after every call:\n\n```\n@Component\npublic class CostTracker {\n\n    private final OffPeakWindow offPeakWindow;\n\n    public CostTracker(OffPeakWindow offPeakWindow) {\n        this.offPeakWindow = offPeakWindow;\n    }\n\n    public void track(String model, TokenPrice peak, TokenPrice offPeak,\n                      long cacheHitTokens, long inputTokens, long outputTokens) {\n        boolean offPeak = offPeakWindow.isOffPeak(ZonedDateTime.now());\n        TokenPrice price = offPeak ? offPeak : peak;\n        double cost = (cacheHitTokens / 1_000_000.0) * price.cacheHitPerM()\n                + (inputTokens / 1_000_000.0) * price.inputPerM()\n                + (outputTokens / 1_000_000.0) * price.outputPerM();\n        log.info(\"{} {} cost estimate: ${} (tokens: {} cache hit / {} input / {} output)\",\n                model, offPeak ? \"off-peak\" : \"peak\", cost, cacheHitTokens, inputTokens, outputTokens);\n    }\n}\n```\n\nWire `track(...)`\n\nwherever 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.\n\n`zone = \"UTC\"`\n\non `@Scheduled`\n\nkeeps 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.\n\nI 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.\n\n**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.**\n\nI write about Java, Spring Boot, and AI every week. Subscribe, it's free.\n\n**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?\"", "url": "https://wpnews.pro/news/deepseek-now-prices-tokens-like-electricity-50-off-peak-discount-and-a-spring-to", "canonical_source": "https://dev.to/jamilxt/deepseek-now-prices-tokens-like-electricity-50-off-peak-discount-and-a-spring-boot-pattern-to-1j7g", "published_at": "2026-08-16 03:12:15+00:00", "updated_at": "2026-08-16 03:41:08.621247+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "ai-infrastructure"], "entities": ["DeepSeek", "Spring Boot", "Spring AI", "V4 Pro", "V4 Flash", "Hacker News"], "alternates": {"html": "https://wpnews.pro/news/deepseek-now-prices-tokens-like-electricity-50-off-peak-discount-and-a-spring-to", "markdown": "https://wpnews.pro/news/deepseek-now-prices-tokens-like-electricity-50-off-peak-discount-and-a-spring-to.md", "text": "https://wpnews.pro/news/deepseek-now-prices-tokens-like-electricity-50-off-peak-discount-and-a-spring-to.txt", "jsonld": "https://wpnews.pro/news/deepseek-now-prices-tokens-like-electricity-50-off-peak-discount-and-a-spring-to.jsonld"}}