Running LLM Jobs in the Off-Peak Window: Our Night-Shift Cron Schedule

Back in August we covered DeepSeek’s move to make weekends half price — off-peak rates all day on Saturday and Sunday (the post is here). A reasonable reaction to that news is: nice press release, but who actually restructures a workload around a discount? The answer, it turns out, is anyone whose AI agent has a cron table. Most of what an agent does on a schedule is not urgent. It reads, summarises, reports, files — work that tolerates being moved a few hours as long as it is done by morning. That tolerance is exactly what the off-peak window pays for.

We went through our own schedule and pushed every LLM job into the night. This post shows the actual table — times, jobs, the boundary rule, the stagger — and an honest list of what the move buys and what it does not.

Off-peak is a defined window, not a mood

Per DeepSeek’s official pricing page, peak hours are 01:00–04:00 and 06:00–10:00 UTC, Monday through Friday. Every other hour is off-peak — evenings, nights, weekends and Chinese public holidays in full — and off-peak rates are exactly half of peak. For the flash model that means:

The discount is always 50% of whatever the job costs, so the savings scale with the batch. A nightly job that writes 100k output tokens costs roughly $3.60 a month at peak rates and $1.80 off-peak — pocket money per job, but the principle compounds across a busy schedule and bigger batches. The full pattern (peak windows, weekend pricing) is on the official page.

GLM meters its subscription with the same clock

The second provider in our stack runs the same trick — on its subscription. The GLM Coding Plan (the flat monthly plan that puts GLM-5.3 and GLM-5.3-Flash inside coding agents) bills in credits, and its official overview states: during off-peak hours, model usage is charged at 50% of the standard credit rate. Peak hours are Monday to Friday, 14:00–18:00 Singapore time (UTC+8) — that is 06:00–10:00 UTC, or 09:00–13:00 in Minsk. Nights and all weekend deduct half.

The size of the effect is not a rounding error. Z.ai’s own allowance table for the entry plan quotes 146–292 million GLM-5.3-Flash tokens per week at a 95% cache-hit rate — where the minimum assumes every call lands in peak and the maximum assumes every call lands off-peak. Same quota, twice the tokens, and the only variable is the clock. The usage policy adds a quieter perk: concurrency limits are dynamically higher during off-peak hours, so night jobs are also the ones least likely to be throttled.

One structural difference is worth knowing: on DeepSeek the window lives in the pay-as-you-go API, so the invoice itself shrinks. On GLM the standard API has flat per-token prices around the clock ($1.40 in / $4.40 out per million for GLM-5.3; $0.15 / $0.50 for Flash) — the window lives in the subscription’s credit accounting instead. Z.ai sums up the upside as up to 92% saved versus pay-as-you-go GLM-5.3 calls when you fully exploit the off-peak rate; that is their marketing number, but the mechanism behind it is the plain 2× credit spread.

Cross-check the two providers in UTC and one band jumps out: DeepSeek peaks at 01:00–04:00 and 06:00–10:00 UTC; GLM peaks at exactly 06:00–10:00 UTC. That morning band is expensive on both at once — and it is precisely where our token-free script jobs sit (08:00–10:00 UTC). Every token-burning job keeps to the night, where both providers are cheap at the same time.

Our night shift

Here is our real table — six scheduled agent jobs, every one of them an LLM consumer, every one inside the off-peak window (times in UTC, with Minsk time next to them; we sit at UTC+3):

None of these is interactive. Each one wakes the agent, lets it read and summarise something, and delivers a finished digest to chat. By breakfast the whole stack is waiting — the agent works the night shift, the human reads at 8 a.m.

The contrast in the same table: every job that does not touch an LLM runs in the daytime, whenever it is convenient — an SSH log scan at 08:00, a mail check at 09:00, package updates at 10:00. Disk I/O and IMAP have no peak pricing; only tokens do.

One honest exception: an interval-based job (every 24 hours) that drifts through the day — it last fired at 14:49 UTC. Interval schedules cannot be pinned to a window; only explicit cron times can. If that job ever grows heavy, it gets a fixed night slot too.

Three rules the schedule follows

1. Land inside the window — with a buffer. The last job starts at 00:15 UTC and it is a small one, finished well before peak pricing opens at 01:00. Do not schedule right up against a window edge: a job that overruns slides across the boundary mid-generation. I have not measured exactly how a provider bills a request that straddles the cutoff — I’d rather not find out on an invoice, so every job gets a margin.

2. Stagger the jobs. Ours sit 30–45 minutes apart. That is cheap insurance on three fronts: the jobs never compete with each other for rate limits, one wedged run does not collide with the next dispatch, and the deliveries arrive in a readable order in the morning instead of six messages landing at once.

3. Write the schedule in UTC, think in your own morning. Cron strings on our box are UTC; the agent’s night shift only makes sense because it maps onto the human’s absence. A schedule written in local time will betray you the day a server, a provider or a daylight-saving switch interprets it differently. UTC everywhere, then convert once.

What the night shift actually buys

• Money. On DeepSeek the API invoice halves for night work; on a GLM coding plan the same clock roughly doubles what the weekly credits buy. Weekends are entirely off-peak on both.
• Congestion, probably. Fewer clients hammer the API at 2 a.m., so I’d expect faster and steadier responses at night — but we have not run a controlled before/after, so treat this as intuition, not a measurement.
• Free interactive hours. When a real question arrives at noon, the agent is not competing with a 200k-token digest for attention and rate budget. Scheduled bulk work stays out of the way of live work.
• The morning newspaper effect. The intangible one. Scheduled intelligence is mostly a read–digest–act loop, and the act part happens over coffee, on a finished, delivered summary — not while the job is still running.

And one honest note about our own stack: the main model has since moved to a flat-rate GLM coding subscription, so no invoice moves when a job fires. But the plan meters work in credits — and credits deduct at half rate at night. The cluster now stretches the weekly quota to roughly double what the same jobs would consume at midday. Different currency, same clock. The remaining reasons cost nothing to keep: the daytime stays clear for interactive work, and the schedule is portable if a per-token model ever returns to rotation.

A checklist for your own table

1. Classify your jobs: interactive (answer now) versus scheduled batch (done by morning). Only the second group moves.
2. Find your provider’s off-peak window on its official docs — DeepSeek writes it in UTC, GLM in Singapore time; convert once, schedule in UTC.
3. Move the batch jobs inside the window, with a buffer before every boundary.
4. Stagger them 30–45 minutes apart.
5. Leave non-LLM scripts time-agnostic; they have no window to hit.
6. Re-check the pricing page every few months — the windows themselves change, and the weekend half-price rule is barely five months old.

The whole move took one evening and no code: it is a table of cron strings. That is the quiet point — the cheapest optimisation in an agent setup is not a smarter model or a shorter prompt, it is the timestamp in front of the job.

Sources: DeepSeek Models and Pricing, the GLM Coding Plan overview and usage policy, verified October 2026; our August note on weekend off-peak rates.