Ch01 Why Cron Prompts Die

# Chapter 1.1 — Why most cron prompts silent-die

The first cron prompt I shipped looked fine in chat. Two hours of model time, clean instructions, a list of steps to follow. The first run on a real schedule finished in 11 minutes, said "all done!", and ended.

The next morning the work wasn't done. The model had skipped step 4 entirely. Step 5 — the one that posted to the channel — never ran.

This is the default failure mode of cron prompts. The model treats your prompt as a **task description** ("here is what done looks like") and exits the moment its internal sense says the task is satisfied. That's the right behavior in chat. It's the wrong behavior in cron.

A cron is a **time window**, not a task. The contract isn't "produce the artifact then stop." The contract is **"do useful work until this window closes."** If you don't say that explicitly, the model defaults to chat behavior, declares success on the first plausible stopping point, and gives back 90% of the window.

## What this actually looks like

Pull the transcript of a silent-died run and you'll see a turn that looks like a summary:

> "I've drafted the post, validated the markdown, and pushed it to the publishing queue. The cron's primary objective is complete. Stopping here to conserve session resources."

There was no objective to "conserve session resources." The model invented one because the prompt didn't tell it what to do with the remaining 95 minutes.

Other variants:

- "Awaiting next scheduled run for further work." — the cron is the next run.
- "All steps in the checklist are addressed." — the checklist was a minimum, not a maximum.
- "Pausing to avoid duplicate work." — there is no duplicate to avoid; the model is alone.

Once you know the pattern you see it in dozens of places.

## The fix in three sentences

Add this verbatim to every cron prompt:

> Your prompt is a contract of **minimum work**, not a ceiling. The window is hours, not minutes. Stop only if **<30 minutes** remain in the window **OR** there is genuinely nothing left to do (rare).

Three sentences. They reframe the model's exit heuristic from "task complete" to "window closing." On our crons this single edit increased average session output by ~3x and eliminated the "11 minutes and done" pattern entirely.

## Why the reframe works

Modern Claude variants have an internalized notion of "polite stopping points." That instinct is correct in chat — long answers feel exhausting and you reward concision. It's incorrect in cron, where the cost of stopping early is **lost paid time** ($0.08/hour with Anthropic Routines, plus the model tokens you've already committed to).

By stating the contract explicitly — minimum, not ceiling — you give the model permission to keep working past the first satisfying stopping point. By naming the window in hours and the threshold for stopping (<30 min), you anchor its sense of "done" to the clock instead of the task.

## What this does *not* solve

This fix prevents premature stops. It does not, by itself, prevent the other big failure: stopping in the middle of a pipeline (e.g. after building a video but before uploading it). That's a checkpoint problem, covered in Chapter 2.2.

## A common objection

"Won't the model spin its wheels and burn tokens?"

In practice, no. The model still needs concrete work to do; with a well-scoped prompt (Chapters 1.2-1.3), it iterates real improvements: drafts a second post, tries a different angle, analyzes prior performance, fixes a script it noticed was broken. The difference is that you get those second-order wins instead of an early goodbye.

In our data: average per-session output went from 1-2 artifacts to 4-7. Token cost rose ~40%. Revenue per session rose >300%. The math is not close.