Cut DeepSeek V4 token bill in half off-peak
Move delay-tolerant DeepSeek V4 batch work into the off-peak window and cut that job's token bill.
Your batch job does not need to start the moment you finish the last commit. If it can wait, DeepSeek's API sets off-peak rates at 50% of peak rates.
Run delay-tolerant batch jobs outside DeepSeek's seven daily peak hours: weekdays 10:00–01:00 UTC and all weekend, because under DeepSeek's schedule weekdays have peak billing only from 01:00-04:00 and 06:00-10:00 UTC, making that 15-hour stretch and all weekend hours off-peak. For a side project, urgency is the only thing that costs extra.
The price change makes timing the control
DeepSeek's new V4 rate card becomes effective at 16:00 UTC on August 16, 2026. Before the August 16, 2026 change, DeepSeek's V4-Flash price was $0.0028 per 1M cache-hit input tokens, $0.14 per 1M cache-miss input tokens, and $0.28 per 1M output tokens. The new off-peak V4-Flash price is $0.007 per 1M cache-hit input tokens, $0.22 per 1M cache-miss input tokens, and $0.66 per 1M output tokens.
DeepSeek's post-August 16, 2026 off-peak V4 pricing is higher than the prior price in every category. Some V4 API price increases exceed 1,100%. The off-peak window is still the main control for a delay-tolerant batch job.
Start delay-tolerant jobs in the cheap window
Use the schedule as a rule, not a guess. If a job can wait, start it in the 15-hour weekday stretch or any weekend hour. If it cannot wait, leave it in the peak schedule and accept the higher bill.
- Inventory the jobs that can wait: report generation, data cleaning, content drafts, test suites, embeddings, or summaries. A short list is enough.
- Map each job to the off-peak window, starting after the weekday peak and avoiding the two weekday peak blocks. The schedule should show the start time, not just the idea.
- Move the trigger to the cheap hours with a cron, queue, or manual start that fires only when the run can finish before the next peak. If the queue is full, let the job wait.
- Keep the job inside one window so the run does not cross from off-peak into peak. A long batch that starts late can wake up in the expensive hours.
- Check the bill after the first run for the same token volume at the cheaper cost. The report is the proof that the schedule worked.
The usual mistake is treating the off-peak window as a weekend-only discount. The window is wide, but it has edges. Do not start a long job near the edge of the peak window. If the run crosses into peak hours, the expensive portion can erase the discount.
Make the cheap run the default
Most side projects stay side projects, and that is fine. Keep weekend side project costs near zero by making the cheap run the default. If the job is a nightly digest, a weekly data pass, or a batch of generated notes, the off-peak window is the default schedule.
Cache what you can, but do not let caching replace scheduling. A cheaper input price helps, yet the biggest swing comes from choosing the right hour.
Put the schedule in one place: a single cron file, a queue policy, or a note in the project README that says which jobs are delay-tolerant. One place makes the rule easy to follow when the next weekend project starts. When the next idea arrives, you can answer the cost question before you write the code. You do not need a full-time job; you need a repeatable weekend habit.
If the job is small, the savings may be small. Small jobs can stay cheap without ceremony. If it is a long-running batch, the same rule can keep the side project from becoming a monthly subscription.
When the next batch is ready, start it in the cheap window and let the report confirm the cheaper cost. If the job cannot wait, leave it out of the schedule and treat the peak price as the actual cost of immediacy for now.