deepseek-peak-guard

A DeepSeek-only peak-hours guard for omp: it encodes DeepSeek's published billing schedule, and during DeepSeek's peak windows it stops tool calls and subagent spawns until you explicitly approve them. This is not a generic cost guard and it does nothing for any other provider's rates — see Scope.

DeepSeek bills peak rates Mon-Fri 01:00-04:00 and 06:00-10:00 UTC, excluding Chinese public holidays. Every other hour — including weekends and Chinese public holidays in full — is off-peak at half the price. Source: https://api-docs.deepseek.com/quick_start/pricing (Chinese: https://api-docs.deepseek.com/zh-cn/quick_start/pricing).

Scope

DeepSeek only, by design. Concretely, as implemented by extensions/deepseek-peak-guard.ts:

• The windows are DeepSeek's own published billing schedule (https://api-docs.deepseek.com/quick_start/pricing). They are not derived from any other provider's pricing, and the package makes no claim about other providers' rates.
• onlyDeepSeekModels defaults to true: the guard is inert unless the current model is DeepSeek. With that default, guardActiveFor() returns early and nothing is gated for a known non-DeepSeek model.
• The model test is modelIsDeepSeek(): it matches when the model id/name or the provider contains deepseek (case-insensitive), and it treats an unknown model as DeepSeek — the comment in the code is "Unknown model: assume DeepSeek so the guard still protects the user."
• Therefore, with a non-DeepSeek model selected this package does nothing. Set onlyDeepSeekModels: false in ~/.omp/agent/deepseek-peak-guard.json if you want the same peak/off-peak rule applied to every model.
• The Chinese public-holiday calendar ships in skills/deepseek-peak-hours/peak_config.json because DeepSeek's off-peak pricing applies in full on those days. It holds the official 2026 State Council dates plus estimated 2027 dates, so refresh it annually (see Maintenance) and bump the version.

Nothing DeepSeek-specific can be relabelled away: the package name, the DEEPSEEK_PEAK_CONFIG environment variable, the DEEPSEEK_PEAK_FORCE test override, and the state/deepseek-peak-approvals.json approval store all keep their names.

What it does

The extension registers on the host event bus and:

• injects the rule plus the live window state at the start of every session, so the model knows the billing state without being asked;
• gates tool calls during peak: they are blocked until you approve the window, and it never prompts off-peak;
• blocks subagent spawns during peak (blockSubagentSpawns);
• aborts an in-flight turn when a peak window begins (stopTurnOnPeakEnter) and asks for permission (or, if there is no UI, leaves the tool blocked);
• resumes automatically at off-peak when you chose /peak wait (autoResumeAtOffPeak);
• shows peak: PEAK … / peak: off-peak … in the status line.

Approvals are persisted per peak window in <agentDir>/state/deepseek-peak-approvals.json, so an approval covers that window only.

Installing

omp install deepseek-peak-guard               # from npm, once published
omp install /path/to/deepseek-peak-guard      # from a checkout (local paths are linked)

# From a tarball: `omp install <file.tgz>` does not unpack archives (it treats an
# absolute path as a local directory to link, and `file:` specs as invalid package
# names), so unpack it first, or install it as a package with bun:
npm pack
tar -xzf deepseek-peak-guard-0.1.0.tgz
omp install ./package

# or, into a package root of your own:
bun add file:./deepseek-peak-guard-0.1.0.tgz

omp plugin list --json                   # confirm it is enabled and its manifest is seen
omp plugin doctor --json                 # `plugin:deepseek-peak-guard` must report ok

The installed package contributes two things:

1. extensions/deepseek-peak-guard.ts, declared under both the omp and the legacy pi manifest key ({"extensions": ["./extensions/deepseek-peak-guard.ts"]});
2. the sibling skills/deepseek-peak-hours/ payload (SKILL.md, peak_config.json, peak_hours.py, peak-guard.test.ts), discovered as a plugin skill.

Requires Bun >= 1.3 (engines.bun). No runtime dependencies.

Commands

Configuration

Optional guard config at <agentDir>/deepseek-peak-guard.json (defaults shown):

{
  "enabled": true,
  "mode": "ask",
  "onlyDeepSeekModels": true,
  "blockSubagentSpawns": true,
  "autoResumeAtOffPeak": true,
  "stopTurnOnPeakEnter": true,
  "pollSeconds": 30,
  "injectSessionBrief": true
}

mode: ask (prompt during peak, block when headless), block (never prompt, always block), wait (never prompt, pause until off-peak), off (no enforcement).

Peak config resolution

The peak windows and holiday calendar are read from the first of these that applies, highest precedence first:

1. DEEPSEEK_PEAK_CONFIG — explicit override, used verbatim even if the file does not exist.
2. <agentDir>/skills/deepseek-peak-hours/peak_config.json when present — the long-standing agent-dir copy keeps winning, so an existing machine keeps reading exactly the file it read before.
3. <pkg>/skills/deepseek-peak-hours/peak_config.json — the copy shipped beside the module inside an installed package, found one directory up from the module.

Without step 3 an installed package would ship its holiday calendar but never read it and would silently classify with holiday-blind windows, reporting PEAK on days DeepSeek bills off-peak (for example a Chinese public holiday such as 2026-09-25). If no file exists at all, the agent-dir path is used and the guard degrades loudly instead of disappearing: it keeps the built-in windows, drops the holiday calendar, and warns peak_config.json unreadable (…); using built-in peak windows without holidays.

The module never touches import.meta: omp evaluates extension modules both as ESM and through a CommonJS object-module wrapper, and a plain function-body evaluation rejects import.meta while parsing — before any statement runs — which no try/catch could recover from. Module location is feature-detected at call time from __filename and any path that yields no filename keeps the agent-dir behaviour.

The CLI half

The same rules are enforced outside the agent by peak_hours.py, which ships in the package and reads the same peak_config.json:

S=<pkg>/skills/deepseek-peak-hours/peak_hours.py
python3 "$S" status          # full report; exit 0 off-peak, 3 peak
python3 "$S" check --json    # one-line state, or machine-readable JSON
python3 "$S" next --count 4  # upcoming transitions
python3 "$S" windows --days 7
python3 "$S" selftest        # asserts the raw rule
python3 "$S" wait            # block until off-peak
python3 "$S" guard -- ./train.sh                  # wait for off-peak, then run
python3 "$S" guard --now -- ./train.sh            # run immediately (accepting peak)
python3 "$S" watch --poll 30 --on-peak 'pkill -f train.sh'

DEEPSEEK_PEAK_FORCE=on|off pins the classification; it exists for tests.

The classification lives twice on purpose — peak_hours.py for shell/agent use and classifyPeak/isPeakAt in the extension for in-process enforcement — and the two must agree.

Maintenance

• Refresh the holiday calendar each year, when China's State Council publishes the schedule, and replace the estimated dates. peak_config.json carries its own holidays_status and holiday_sources fields describing what is official and what is estimated. Bump the package version with the refresh.
• Change the rule in both halves, then run the two parity checks below.

Verification

cd skills/deepseek-peak-hours
python3 peak_hours.py selftest      # asserts the raw rule against the shipped config
bun peak-guard.test.ts              # parity with peak_hours.py + gate behavior

peak-guard.test.ts runs its phases in child processes (the guard reads its config, approval store, and agent dir once per process) and compares the extension's classification against peak_hours.py over a dense sample of instants.

License

MIT © 2026 Zenon. Not affiliated with DeepSeek; the schedule is quoted from DeepSeek's public API pricing documentation.