A program to check whether it's peak for DeepSeek or not
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
2026-10-27 22:38:38 +05:00
.gitignore feat: on more format. 2026-10-27 22:38:38 +05:00
go.mod Init. 2026-10-27 22:16:27 +05:00
holidays.go Init. 2026-10-27 22:16:27 +05:00
main.go feat: on more format. 2026-10-27 22:38:38 +05:00
main_test.go feat: on more format. 2026-10-27 22:38:38 +05:00
peak.go Init. 2026-10-27 22:16:27 +05:00
peak_test.go Init. 2026-10-27 22:16:27 +05:00
readme.md feat: on more format. 2026-10-27 22:38:38 +05:00

dsprice

Tells you whether DeepSeek's API is billing at peak or off-peak rates right now, so you know when it's cheaper to run.

Off-peak is half of peak.

$ dsprice
OFF-PEAK

Add -until to append the time until the change:

$ dsprice -until
OFF-PEAK 7h 50m

Add -verbose for the reasoning and the next transition:

$ dsprice -verbose
OFF-PEAK · half of peak rates
  now    2026-10-27 17:09 UTC  (Wed 01:09 Beijing)
  why    outside the peak windows
  next   PEAK in 7h 50m — 2026-10-28 01:00 UTC

The rule

From the DeepSeek pricing page:

Peak hours are 01:00 - 04:00 and 06:00 - 10:00 UTC, Monday through Friday, excluding Chinese public holidays. All other hours are off-peak, including weekends and Chinese public holidays in full.

So an instant is peak only if all three hold: it falls in 01:00–04:00 or 06:00–10:00 UTC, the day is Monday–Friday, and the day is not a PRC public holiday.

Usage

dsprice                          # one word: PEAK or OFF-PEAK
dsprice -until                   # that word, plus time until the change
dsprice -verbose                 # what that word means, and what's next
dsprice -at "2026-11-02 03:00"   # evaluate a specific UTC instant

The three output formats are mutually exclusive: passing -until and -verbose together is rejected rather than silently ordered.

-at accepts RFC3339 or a naive YYYY-MM-DD HH:MM (read as UTC), which is handy for checking a future run before you schedule it. It combines with both output modes.

Exit status is 0 whenever an answer was produced, including PEAK. To branch on the answer, compare the word:

[ "$(dsprice)" = OFF-PEAK ] && run-the-batch-job

Install

go build -o dsprice .
install -m 755 dsprice ~/.local/bin/    # or anywhere on $PATH

No dependencies outside the standard library, and no network access: the rule is a fixed function of the clock plus the embedded holiday table.

Keeping it correct

Two things in this repo can go stale, both deliberately visible rather than silent.

Holidays live in holidays.go, keyed on the Beijing date. Rest days come from the State Council's annual announcement via NateScarlet/holiday-cn. Make-up workdays on weekends are intentionally omitted: weekends are off-peak anyway, so listing them changes nothing.

Coverage is 2025–2026. The 2027 calendar has not been published yet, so the program warns on stderr and falls back to the weekday-and-weekend rule alone:

dsprice: warning: no PRC holiday calendar for 2027; assuming none, so only weekends are excluded

When the State Council publishes 2027, add its rest days to holidays and register the year in holidayYears.

The rule itself is scraped by hand from a docs page that DeepSeek may rephrase or reprice. Nothing in this program fetches that page, so a change upstream will not be noticed automatically. Re-read the pricing page occasionally; the peak windows and the half-price ratio are the parts worth re-checking.

Tests

go test ./...

Covers window boundaries to the second, weekends, holidays, make-up workdays, the unknown-year fallback, the -until duration format, and an invariant test asserting that no peak instant straddles the UTC and Beijing calendar dates — which is what makes the Beijing-dated holiday lookup sound.