Scheduled tasks & /loop

Three mechanisms, split by whether the work needs a session open. For the full picture of when to use which, and the cadence cost math, see Loops & Autonomy.

How you use it day-to-day

• /loop repeats a prompt or slash command. Lead with an interval (/loop 30m /babysit-prs, units s / m / h / d) or trail it (every 2 hours). Omit the interval to let the model pace itself. Default if you say nothing is about 10 minutes. It is session-scoped: it ends when the session ends.
• ScheduleWakeup is the engine behind self-paced /loop. You set delaySeconds (1 minute up to 1 hour) and pass the same prompt forward. Short delays while something is in flight, long delays when idle. Watch the cache: 270s stays warm, 1200s and up amortizes the miss, never 300s.
• Cron tools (CronCreate / CronList / CronDelete) schedule programmatically with standard 5-field cron expressions (*/15 * * * *, wildcards, ranges, steps, lists). Also session-scoped. One-time future runs are supported.
• /schedule creates cloud routines that run with no session open and survive the session closing. This is the one to reach for when the work must happen whether or not you are around.

Gotchas

• Session scope is the big divider. /loop and the Cron tools die with the session; /schedule routines do not. If it has to run overnight unattended, it belongs in /schedule.
• Recurring tasks auto-expire. A safety bound (docs and community cite about 7 days): the task fires one last time, then deletes itself, so a forgotten loop cannot run forever. A session also caps at around 50 scheduled tasks. Verify the exact current numbers in the docs.
• Define a stop condition. A self-paced /loop with no exit keeps firing. End it by omitting the next wake-up.
• A detached routine on a paid API spends while you sleep. Put the spending cap in the job.