| name | cron-cost-scheduling |
| version | 1.0.0 |
| category | devops |
| description | Schedule LLM crons around provider peak/off-peak windows. |
Cron Cost Scheduling
When a provider introduces time-of-use pricing (peak vs off-peak rates) and the
user asks whether LLM crons should be rescheduled to save money. Covers the
verification, classification, and decision procedure. Does NOT cover cost
metering (see cron-cost-tracking for the SQLite cost DB) — this is about
scheduling decisions.
When to Use
- User asks "when are the off-peak hours for ?" or "should we move our LLM crons off-peak?"
- A provider announces a pricing change with time-of-use windows
- Reviewing whether existing cron schedules are cost-optimal
Procedure
1. Fetch the LIVE pricing page — never trust search snippets
Search results carry stale windows for months. The old DeepSeek "off-peak
16:30–00:30 UTC" card appeared in search results alongside the live card
(2026-08-18). Always pull the provider's own pricing page and grep the window
text:
curl -sL <pricing-url> -o /tmp/provider_pricing.html
grep -oiE '.{80}(peak hours|off-peak|UTC|discount).{80}' /tmp/provider_pricing.html
Docusaurus/Next.js doc pages render fine as static HTML — no browser needed.
If the pricing table only appears without its footnote, grep for utc and
peak separately; the footnote is usually below the table.
2. Convert the window to the user's local time
Windows are always stated in UTC. Seoul = UTC+9. DeepSeek live card
(2026-08-18): "Peak hours are 01:00 - 04:00 and 06:00 - 10:00 UTC (all other
hours are off-peak)" → Seoul peak = 10:00–13:00 and 15:00–19:00 KST, off-peak
= 19:00–10:00 plus the 13:00–15:00 lunch gap. State the local windows
explicitly in the delivery — don't make the user do the conversion.
3. Classify every LLM cron against the windows
Expand each cron's hour/minute fields (ranges 9-17, lists 18,20,22,
wildcards) and count peak hits per job. Most night/early-morning crons already
run off-peak — zero change needed; say so instead of proposing mass
rescheduling. Classification table for the DeepSeek case:
references/deepseek-peak-offpeak-2026-08.md.
4. Decision rule — move only the free wins
- Do NOT move crons whose purpose is daytime responsiveness (workday
auto-remediation:
agent-fixer-workday, cortex-bus-workday,
orch-backlog-driver). Their function beats the pennies (~$0.003–0.007
extra per peak run at flash rates). Rescheduling them to off-peak-only
guts the service to save cents.
- DO move runs sitting just inside the peak boundary where sliding a few
minutes costs zero coverage (e.g. 18:50→19:50, 12:00→13:30). These are the
only free wins.
- Night crons are already off-peak — leave them.
5. Quantify before trimming frequency
If cron-cost-tracking isn't deployed, deploy it and collect a week of real
spend rather than trimming on estimates. Cron-run spend is often trivial next
to interactive-session spend — the recommendation should say so.
Pitfalls
- Stale search snippets outnumber live pages. A third-party "pricing
clock" or aggregator blog can keep the old window for months after a rate
card change. The provider's own page is the only authority.
- Rate cards change without fanfare. The DeepSeek peak/off-peak card was
live by 2026-08-16 while older docs pages still implied the old flat
pricing. Re-verify the page every time this question comes up.
- Don't propose moving daytime crons to night. It reads as cost rigor but
is actually a service regression — call it out explicitly with the
per-run cost delta so the user can judge.
- web_extract may be search-only on some backends (DDG); if it errors,
fall back to
curl + grep as in step 1 — the page is static HTML.
Verification
- The window quote comes from the provider's own page fetched this session
(cite the URL and date).
- The local-time conversion is stated explicitly (e.g. "UTC+9 → KST").
- Every LLM cron's peak-hit count is backed by an actual parse of the live
cronjob action='list' output.
- The recommendation names which crons to move, which to keep, and why.
Related
cron-job-management — naming, install, doctor-sync for any schedule change you do makecron-cost-tracking — the SQLite cost DB that quantifies the actual spend
