Claude Code /loop expires in 7 days: where a Sume job should live

Do not make /loop the owner of a recurring render. It is session-scoped and recurring tasks expire after 7 days, so the schedule belongs in Sume Scheduled, which runs on Sume's side, with /loop at most polling the results.

Claude Code's scheduled tasks page describes three places a recurring prompt can live. Each has a different answer to the question that matters for a weekly video: what has to be running for it to fire?

Where each scheduler runs

The numbers below come from the Claude Code docs; the last row is Sume.

Why the 7-day edge matters for renders

A task that quietly deletes itself after a week is fine for polling a deploy and bad for a Monday product clip. Nobody notices until the clip is missing. A self-paced /loop is also not restored when you resume a session, per the same page.

Sume Scheduled stores the instruction and the trigger. You author it in the dashboard or ask the Agent to set it up in chat; the API can list, read and run schedules but not create them. Each run has a spend cap, default $1.00, and a per-run override can only lower it. Overlap is handled with on_active_run, set to skip or reject. The Agents docs cover the details.

A split that works

Keep creation in Sume and observation in Claude Code. A session can use /loop for a bounded check, for example every 15 minutes while you work, and the MCP tools jobs_status and jobs_result read state without creating anything.

If the session ends, nothing is lost: the Sume run continues and its job results stay readable. The same goes when you use a cloud routine as the trigger; keep the schedule in one place so you do not get two renders for one Monday. See the routine versus Scheduled comparison.