12 — Scheduling Jobs — Prompts on a Clock

"Cron for AI" got the shape of scheduling right and the boundary wrong — the boundary is the session. The idea that straightened it out: a scheduled task is a prompt that fires automatically on a clock, but by default it lives inside an open session — so the real question is always whether the job needs to survive the terminal closing. [1] That single question decides which mechanism to reach for.

The framing that clicked is to separate the _trigger_ from the _runtime_. The trigger is easy: /loop repeats a prompt at an interval (every 5 minutes, every 2 hours) while the session is open, and I can set one-time reminders for specific times [1]. The runtime is the catch. Tasks run in the background and stop when I close Claude Code. If the job is "check the deploy every 10 minutes while I'm at my desk," the session-bound /loop is perfect. If the job is "run a security scan every night at 2am whether I'm asleep or not," session-bound is wrong — that job has to move to Cloud or Desktop scheduled tasks that don't depend on my terminal being open [1][2].

The two kinds of schedule

The roadmap distinguishes the shape of the schedules, and reading them as interval-versus-moment made them click:

• Recurring intervals — repeat a prompt at a regular cadence. "Every 5 minutes, check CI status." The /loop command drives these. The right fit for monitoring or polling tasks during a session.
• One-time reminders — fire once at a specific moment. "At 3pm, remind me to review the PR." The right fit for time-anchored nudges.

Both run in the background of an open session, which is the property that makes them feel weightless — I set them and they fire on their own. It's also the property that bites if I forget it: close the laptop, the clock stops.

When to move off the session

The decision the roadmap is bluntest about: if I need tasks to keep running after I close the program, I should use Cloud or Desktop scheduled tasks instead of /loop [1][2]. The distinction is the runtime, not the trigger:

• Session-bound (/loop) — fires while my terminal is open. Zero setup beyond the command. Right for in-session monitoring and polling.
• Survives close (Cloud / Desktop scheduling) — runs on a server or the desktop app's own scheduler, independent of any terminal. Right for overnight scans, daily reports, anything that must fire whether or not I'm at the machine.

The mistake I made once: I set a /loop to monitor a long-running deploy, closed my laptop for the night, and came back to a clock that had stopped at 6pm. The job wasn't wrong; the runtime was. Anything that matters outside my working hours has to live on the Cloud or Desktop scheduler.

How I use this

The habit these notes left me with is one question before I schedule anything: _does this need to fire when my terminal is closed?_ If no, /loop or a one-time reminder inside the session is the lightweight answer. If yes, it goes straight to Cloud or Desktop scheduling, because pretending a session-bound job will survive a closed laptop is the one scheduling mistake I keep making. The trigger is easy either way; the runtime is the whole decision.

References

[1] Anthropic, "Run prompts on a schedule," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/scheduled-tasks

[2] Anthropic, "Schedule tasks on the web," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/web-scheduled-tasks