DeepSeek API Weekend All-Day Off-Peak Pricing

DeepSeek Pushes Weekend API Pricing Straight Down to Off-Peak Rates

DeepSeek officially adjusted its API peak/off-peak billing rules today.

Starting at 00:00 Beijing time on August 23, 2026, the DeepSeek Open Platform will no longer distinguish between peak and off-peak periods throughout Saturday and Sunday. Instead, all weekend usage will be billed at off-peak rates. Charges incurred before the new rules take effect will still be settled according to the original pricing standards.

This adjustment comes less than a week after DeepSeek introduced peak/off-peak pricing on August 17. Under the previously announced rules, weekday peak hours were 9:00–12:00 and 14:00–18:00 Beijing time, with all other periods classified as off-peak. Off-peak prices were generally half the peak rates.

Take the flagship model DeepSeek-V4-Pro, cited in public reports, as an example. Its output price during peak hours is RMB 27 per million tokens, compared with RMB 13.5 per million tokens during off-peak hours. Once the new rules take effect, developers calling the model during the daytime on weekends will also be charged directly at the RMB 13.5 rate.

In other words, developers previously had to consider “what time to run it.” On weekends, they now only need to consider “how much to run.”

It Is Not Just a Price Cut—the More Important Change Is One Less Layer of Scheduling Logic

Looking only at the numbers, this is a relatively limited pricing adjustment: weekday peak prices remain unchanged, while the discount is concentrated on weekends. But for teams running large-scale workloads, its value is not merely that they pay less for some tokens. Rather, the billing strategy becomes easier to incorporate into production systems.

Under peak/off-peak pricing, developers typically put non-real-time tasks into queues and decide whether to release them based on the time period. Examples include:

• Large-scale document summarization and tag generation;
• Offline cleaning of RAG knowledge bases, question-and-answer pair synthesis, and quality evaluation;
• Model regression testing, prompt evaluation, and comparative experiments across multiple models;
• Agent trajectory generation and replay of failure cases;
• Code repository scanning, comment completion, and test-case generation;
• Data labeling, classification, rewriting, and review tasks.

These jobs generally do not require requests to finish within a few seconds. Their primary concern is the cost per task. Previously, teams might have had to split weekend workloads across different time windows to avoid accidentally entering a more expensive billing period. Now, the weekend has become one consistent low-cost window. Schedulers no longer need to pause during the day or wait across dates to obtain lower prices.

For an independent developer with relatively low usage, this may mean saving only a few dozen yuan per month. For enterprise workloads consuming hundreds of millions or even billions of tokens every day, however, the difference can be large enough to affect where and when batch jobs should run.

Using a simplified scenario that counts only output tokens:

Peak cost = output tokens ÷ 1,000,000 × RMB 27
Weekend cost = output tokens ÷ 1,000,000 × RMB 13.5
Savings = output tokens ÷ 1,000,000 × RMB 13.5

If an evaluation task produces 1 billion output tokens, then at the example prices above, running it during peak hours would cost approximately RMB 27,000, while running it on the weekend would cost approximately RMB 13,500. The difference would also be RMB 13,500.

Of course, this is only a simplified estimate for ease of understanding. Actual bills are also affected by the ratio of input to output tokens, context length, cache-hit rates, the pricing of the specific model, and task retry rates. It would therefore be incorrect to interpret all API costs as simply being “half price on weekends.” However, the change will be more pronounced for Agents, reasoning-trajectory generation, and data-synthesis tasks with a high proportion of output tokens.

DeepSeek Is Using Pricing to Guide Compute Migration

Peak/off-peak pricing is essentially not a promotion, but a compute-scheduling tool.

Like cloud servers, model APIs face pronounced fluctuations in demand. Enterprise production requests, internal tool calls, and development and testing traffic typically cluster during weekday mornings and afternoons, while overall utilization is relatively low during the early morning hours and on weekends. Once compute capacity is deployed, idle capacity still incurs depreciation, electricity, and operations costs. Rather than letting GPUs sit idle during low-load periods, providers can use lower prices to attract workloads that can be delayed.

This is somewhat similar to spot instances offered by cloud providers, but DeepSeek’s approach is easier to understand: instead of making developers bear the risk of instances being reclaimed at any time, it directly tells them through token pricing when calls are cheaper.

By classifying the entire weekend as off-peak, this adjustment further expands the low-cost “reservoir.” Real-time weekday workloads continue as usual, while elastic loads such as batch evaluations and data generation are directed toward the weekend. For DeepSeek, this can improve cluster utilization; for developers, it provides lower and more predictable costs.

From this perspective, the new rules are not simply a concession on price. They represent DeepSeek’s rapid revision of its product design based on developer feedback after launching peak/off-peak billing. The system began operating on August 17 and the weekend rules were adjusted on August 23—less than a week later. This suggests that the first version had an obvious problem beyond its affordability: the billing calendar was too fragmented.

API pricing can be complicated, but developers generally dislike prices that cannot be calculated mentally at a glance.

Weekends Are Suitable for Batch Jobs, but That Does Not Mean All Production Traffic Should Be Moved There

The most direct beneficiaries of the unified off-peak rate are tasks that can be delayed. A team can freeze its dataset on Friday evening, run inference and evaluations in bulk on Saturday, complete aggregation and manual spot checks on Sunday, and deliver the results to the R&D or operations teams on Monday.

Typical arrangements include:

1. Model evaluation: Running tens of thousands to hundreds of thousands of test cases at once to compare changes in prompts, model versions, and parameters;
2. Data synthesis: Generating training samples, preference pairs, reasoning processes, or multi-turn conversations;
3. Knowledge-base maintenance: Rewriting document summaries, extracting entities, and generating retrieval questions;
4. Back-office content processing: Classifying and archiving articles, video subtitles, and user feedback accumulated over the week;
5. Low-priority Agents: Conducting market research, static code analysis, and reviews of historical support tickets.

However, real-time customer service, search and question answering, trading assistance, and online programming tools should not deliberately delay requests until the weekend merely to obtain lower prices. The primary value of a model API lies in its responsiveness to business needs; price is only one constraint. Making users wait several hours to save a dozen yuan per million tokens is usually the wrong optimization.

A more reasonable approach is to divide calls into real-time and offline layers. The real-time layer sends requests whenever business needs require, while the offline layer places jobs in a message queue for batch execution during weekends or weekday off-peak periods. This preserves the front-end experience while allowing genuinely elastic token consumption to benefit from lower prices.

Developers Need to Check Three Details

Although the new rules are simpler, teams that have already integrated the DeepSeek API still need to review their cost systems.

1. Time Zones Must Be Standardized to Beijing Time

DeepSeek’s published peak/off-peak periods are based on Beijing time. If a task scheduler, Kubernetes CronJob, or cloud function defaults to UTC, the weekend boundary and off-peak windows may be shifted by eight hours.

This is especially important for services deployed across borders. Do not determine the pricing tier directly from the server’s local time. A more reliable approach is to consistently convert the billing calendar to Asia/Shanghai and keep the peak/off-peak rules in a configuration center rather than scattering them throughout business code.

2. Do Not Equate Lower Prices with Looser Rate Limits

Billing prices, request-rate limits, and actual service capacity are three separate things. Unified off-peak weekend pricing does not automatically mean that RPM, TPM, or concurrency quotas will increase as well.

If a large number of teams move their batch jobs to Saturday, the low-cost window could also become a new concentration point for traffic. Large-scale tasks should still use exponential backoff, idempotency keys, maximum retry limits, and queue-depth controls. Otherwise, temporary congestion could cause the same content to be generated repeatedly, ultimately spending the money saved on ineffective retries.

3. Cost Alerts Must Not Continue Using a Fixed Unit Price

Many teams’ FinOps dashboards estimate daily expenses using “total tokens × fixed price.” After the introduction of peak/off-peak billing, this method is no longer sufficiently accurate.

At a minimum, the cost system should record the model, input tokens, output tokens, request time, and pricing tier. For bills that span the time when the rules take effect, the platform’s final bill should be treated as authoritative. DeepSeek has explicitly stated that calls made before the new rules take effect will continue to be settled under the old standards. Therefore, historical usage before August 23 cannot all be recalculated at the weekend off-peak rate.

Compared with a Simple Price Cut, Predictability Matters More

Over the past two years, competition among large-model APIs has focused primarily on list prices per million tokens. But as enterprise usage grows, developers are increasingly concerned with several other questions: Can prices be predicted? Can bills be audited? Can tasks be scheduled reliably?

An API with a nominally low price but frequently changing rules may not be as suitable for production as a service with a slightly higher unit price but long-term stability. Enterprises ultimately bear more than token costs. They also incur the costs of engineering changes, capacity planning, failed reruns, and financial reconciliation.

The direction of DeepSeek’s adjustment is correct: assigning the entire weekend to a single pricing tier is more intuitive for developers than dividing each day into multiple fragmented windows. It allows teams to plan calls according to a simple principle—“real-time workloads on weekdays, batch jobs on weekends”—rather than maintaining an ever-changing hourly price table.

However, peak/off-peak pricing still increases the complexity of multi-model routing. When an application connects simultaneously to models such as GPT, Claude, Gemini, and DeepSeek, the router must compare not only capabilities, latency, and context length, but potentially also costs based on the day of the week and time of day. Model selection is evolving from a static configuration into a real-time decision-making problem.

This also means that API aggregation platforms and enterprise internal gateways will need to provide more granular cost-routing capabilities. The same task might use Model A on weekdays and switch to DeepSeek on weekends; online requests may prioritize latency, while offline requests prioritize unit token cost. Merely supporting the OpenAI request format will no longer be enough. Pricing calendars, budget caps, and observability will become foundational capabilities in the next stage.

It Is a Small Adjustment, but a Practical One

DeepSeek did not launch a new model in this update, nor did it change weekday peak prices. Judging solely from the announcement, it is far less attention-grabbing than a model release.

But for those who actually pay API bills, changes like this are often more valuable in practice.

The all-day weekend off-peak rate reduces the cost of batch jobs while also lowering the complexity of time scheduling and bill forecasting. More importantly, it shows that DeepSeek is trying to treat model APIs as cloud-computing resources capable of responding to demand, rather than merely attaching a fixed price list to each model.

Our assessment is: This rule change is worth recognizing, particularly for output-intensive tasks such as evaluation, data synthesis, and knowledge-base processing. However, it will not automatically reduce the total cost of every business, nor can it replace rate limiting, retry policies, or budget governance.

For teams with significant usage, two things can be done today: recalculate the budgets for weekend batch jobs and verify that the scheduling system is correctly using Beijing time. Offline work that can be migrated should be moved where possible, while real-time workloads do not need to have their operating schedules forcibly changed for the sake of lower prices.

Less than a week after introducing peak/off-peak billing, DeepSeek simplified the weekend rules. At least this time, the billing logic did not continue moving in the direction of an electricity tariff table.

Sources

• ITHome: IT Morning Report 0823—Summarizes the information that DeepSeek would adjust its API weekend billing rules starting August 23, 2026, and explains that Saturday and Sunday would both be billed at the off-peak rate.