---
title: "12 — Scheduling Jobs — Prompts on a Clock"
uid: scheduling-jobs
tags: ["loop", "scheduling", "roadmap:claude-code", "reminders", "cron", "automation", "claude-code"]
excerpt: "A scheduled task is a prompt on a clock — but session-bound by default. The real question: does the job need to survive the terminal closing?"
date: 2026-08-13T03:28:21+0000
source: https://www.aveshina.my.id/en/blog/scheduling-jobs
---

"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.

```figure
<svg viewBox="0 0 740 260" xmlns="http://www.w3.org/2000/svg" class="my-6 w-full max-w-2xl" role="img" aria-label="Two schedule shapes and the runtime catch. Left: a recurring interval (/loop) firing a prompt every 5 minutes into an open session. Right: a one-time reminder firing once at a specific moment. Below both: an open terminal session keeps them alive; a closed terminal stops them; a cloud icon labelled Cloud/Desktop scheduling keeps them running after close.">
  <defs>
    <marker id="sc1" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto">
      <path d="M0,0 L10,5 L0,10 z" fill="#64748b"/>
    </marker>
  </defs>
  <g font-family="ui-sans-serif, system-ui, sans-serif" text-rendering="geometricPrecision">
    <!-- recurring -->
    <text x="185" y="30" font-size="12" font-weight="700" fill="#1e1b4b" text-anchor="middle">Recurring interval — /loop</text>
    <rect x="60" y="45" width="250" height="34" rx="8" fill="#e0e7ff" stroke="#6366f1" stroke-width="1.5"/>
    <text x="185" y="66" font-size="10" fill="#1e1b4b" text-anchor="middle">every 5 min → check CI</text>
    <rect x="60" y="90" width="250" height="34" rx="8" fill="#e0e7ff" stroke="#6366f1" stroke-width="1.5"/>
    <text x="185" y="111" font-size="10" fill="#1e1b4b" text-anchor="middle">every 5 min → check CI</text>
    <text x="185" y="142" font-size="10" font-style="italic" fill="#64748b" text-anchor="middle">repeats while session is open</text>

    <!-- one-time -->
    <text x="555" y="30" font-size="12" font-weight="700" fill="#422006" text-anchor="middle">One-time Reminder</text>
    <rect x="430" y="45" width="250" height="34" rx="8" fill="#fef9c3" stroke="#ca8a04" stroke-width="1.5"/>
    <text x="555" y="66" font-size="10" fill="#422006" text-anchor="middle">at 3:00pm → review the PR</text>
    <text x="555" y="111" font-size="10" fill="#94a3b8" text-anchor="middle">···</text>
    <text x="555" y="142" font-size="10" font-style="italic" fill="#64748b" text-anchor="middle">fires once at the moment</text>

    <!-- runtime catch -->
    <rect x="60" y="170" width="620" height="40" rx="8" fill="#fce7f3" stroke="#db2777" stroke-width="1.5"/>
    <text x="370" y="187" font-size="10.5" font-weight="700" fill="#500724" text-anchor="middle">Runtime catch</text>
    <text x="370" y="203" font-size="10" fill="#500724" text-anchor="middle">both stop when you close Claude Code → for jobs that must survive, use Cloud / Desktop scheduling</text>

    <path d="M250,150 C260,160 280,168 298,170" fill="none" stroke="#64748b" stroke-width="1.5" marker-end="url(#sc1)"/>
    <path d="M490,150 C480,160 460,168 442,170" fill="none" stroke="#64748b" stroke-width="1.5" marker-end="url(#sc1)"/>
  </g>
</svg>
```

## 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](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](https://code.claude.com/docs/en/web-scheduled-tasks)

```quiz
Q: What does the /loop command do?
- Runs a shell command in a subshell
- Repeats a prompt at a regular interval while the session is open
correct: 1
explain: /loop is the in-session scheduling command. It fires a prompt on a cadence (every 5 min, every 2 hours) in the background, and stops when Claude Code closes.

Q: You set a /loop to monitor a deploy, then close your laptop for the night. What happens?
- The loop keeps running on a server
- The loop stops when Claude Code closes — session-bound jobs don't survive
correct: 1
explain: Scheduled tasks run inside an open session and stop when it closes. For jobs that must fire while you're away, use Cloud or Desktop scheduling instead.

Q: Which schedule shape fits "remind me to review the PR at 3pm"?
- A recurring /loop
- A one-time reminder at a specific moment
correct: 1
explain: Time-anchored, single-fire nudges are one-time reminders. /loop is for recurring cadences like "every 5 minutes."

Q: When should you reach for Cloud or Desktop scheduled tasks instead of /loop?
- When the task needs to run faster
- When the task must fire whether or not your terminal is open (overnight, daily, unattended)
correct: 1
explain: Cloud/Desktop scheduling runs independently of any session. Use it for any job that has to survive a closed laptop.
```