What Should an AI Legion Do While You Sleep? 22 Cron Entries, Four Still Lit

Episode 19 of One Man One Legion — the first of the war stories. Episode 2 ended on a promise: “a scheduler that once ran 22 jobs.” This is that story, and the number needs correcting along the way.

Every legion eventually faces the seduction of the clock: if a job can run at 6 a.m. unattended, why shouldn’t everything? This is the story of a one-person AI legion that answered that question by growing a cron schedule into a small publishing empire — and then, in one day in July, switching most of it off on purpose.

An empire measured in JSONL

The run logs begin at 21:27 on March 29, 2026 — an odd hour for a job scheduled at 03:35, which is to say the first fire was a human pressing run-now to watch it work. In the 116 days from that click to late July, the schedule grew: hot-topic monitoring morning and evening, a pure-news push at both ends of the day, six WeChat article entries, three podcast productions (one reading the news aloud in a cloned voice), two Feishu pushes, a US-stock column, plus a diagnostic job and a headless video-factory trial that never fired once. At the observed peak, 16 jobs were lit at once.

What the empire actually did, in aggregate: 790 finished runs, 154 ending in status “error” — about one in five. The workhorse, the morning hot-topic monitor, fired 120 times with 25 errors; the voice podcast managed 11 errors in 21 runs. The seven backup snapshots in the cron directory read like growth rings: 12 entries on July 4, 17 by July 8 — then a snapshot from Aug 18 showing 20 entries with exactly 3 still enabled. The file kept accepting tombstones even as the lights went out; it holds 22 today.

July 23, 08:00

The last of the old guard ran at 08:00 on July 23 — a “deep story” slot whose label still said 17:20, the name and the cron expression having drifted apart sometime in the spring. Then: nothing. No backup marks the switch-off; the evidence is the silence. The old guard’s final runs cluster on July 22–23 (a one-shot diagnostic had fired its only run on July 5; one duplicate noon copy had gone quiet on July 11), and for 25 days the logs show no cron fire at all.

The file itself shows what kind of operation this had become. Two entries share the identical name — the noon topic slot, filed twice, each copy running for weeks in parallel. Six orphaned run files belong to jobs deleted so thoroughly they no longer have names, just 13 log lines of June experiments; one orphan is nothing but an apology, a note that a podcast episode couldn’t be delivered that morning. Automation’s last words were often about automation failing.

The relight, and the pattern in it

On Aug 17 at 16:31 — mid-afternoon, off-schedule, a hand on the button again — the first job came back: a YouTube-subscription material drop that feeds raw leads into a group at 03:30 each morning. The next day two “video topic” jobs relit on their own clocks, at 03:20 and 17:40; their entire job is to ask the operator what today’s video should be. Two days after that a fourth lit: an arXiv paper digest at 00:55, 08:55 and 16:55, feeding picks into the article pipeline. Its first delivery was 86 papers, on Aug 20 — itself an off-schedule manual fire, like the YouTube relight.

Look at what survived and the criterion is embarrassingly plain. The four live jobs either feed material to the human or ask the human a question. Everything that decided, finished, and published on its own schedule is dark. The WeChat articles didn’t stop being made — they moved to a human-gated pipeline with machine QC gates, where nothing ships without a nod. What remains on the clock is precisely the work that makes sense unattended: gathering and asking.

Nor was this an isolated instinct. Five days before the lights went out, the same operator cut a 2,182-line workflow SOP down to about 180 lines, and 161 mandatory rules down to 15 (operator’s memory diary, 2026-07-18). Over-automation was being pruned everywhere the hand could reach.

The survivors still bleed

Do not mistake the cut for a reliability upgrade. During the Aug 21–27 model storm — the cloud GLM-5.3 timing out and the local fallback dying with it, in the log’s own words “All models failed (2)” — the arXiv job logged 18 consecutive errors across its 24 runs to date. Its 16:55 slot on Aug 27 came back green and delivered 82 papers. The lesson is not that contraction fixed anything; it is that once only feed-and-ask jobs remain, an unreliable day costs you a missed digest instead of a publication you didn’t want.

What we claim and what we don’t

Counts are from jobs.json (22 entries, 4 enabled), seven backup snapshots (peak observed enablement 16), and 27 per-job run logs (790 finished runs, 154 errors), read Aug 27, 2026, timestamps Asia/Shanghai. The switch-off itself left no log line — “the operator cut it” is inferred from what was relit and when, not from a recorded decision. First-run manual fires are inferred from off-schedule timestamps. Error status includes timeouts whose work may have partially completed; no failure taxonomy is claimed. The 22 entries include both noon duplicates; 16 is the peak observed in backups, not a proven maximum.

Primary sources: jobs.json and its backups (entry counts, enable states, schedules, name drift), runs/*.jsonl (790 run records with statuses and summaries), and the workstation operator’s memory diary (SOP cut, 2026-07-18), 2026-03–08.

Measured 2026-08-27 from live files. License: CC BY 4.0 — cite the source URL.

Next in the war stories arc: the legion’s bug diary — the failures it kept on itself. Back to the series map.