A weekly scheduled agent run for podcast clips: cron, cap and trigger

A weekly podcast-clips job is a good fit for a Sume Scheduled Action: a 5-field cron expression plus an IANA time zone, a prompt that describes the clip task, and a spend cap. You create the action in the Scheduled section of the Agents dashboard; the API can list, read, run and cancel actions but cannot create them.

What you set

Schedule triggers use cron such as 0 9 * * 1 for Monday 09:00 in the zone you choose, or an API trigger for runs you start yourself. The default cap is $1.00 per run. A single run started through the API may pass a lower cap, never a higher one, so the dashboard value stays the ceiling.

A prompt that survives a weekly cadence

The action runs with no one watching, so write the prompt for that: name the folder or source to look at, the length of clips you want, what counts as done, and what to do when there is nothing new (stop with a short note, not an invented clip). Keep the work small enough for a $1.00 cap; a clip plan from a transcript fits, a full render batch may not, and the cap is the guard that stops it.

• Name the input explicitly (the newest episode URL, the transcript location).
• Ask for a typed result, and check it before you spend on trims.
• Keep media steps in separate API jobs, where prices are flat and known.

A realistic weekly flow

A workable split: the scheduled action finds the newest episode and writes the clip plan as its result, and your own service reads that result and runs the flat-priced media jobs, trim and captions, with its own idempotency keys. That keeps the action under its cap and keeps every paid media step visible in your logs. If you need the action's result pushed to you, remember signing secrets for webhooks are not self-serve, so a short poll on the run receipt is the dependable route.

Limits

Webhook signing secrets for these events are not self-serve according to the docs, so poll if you cannot get one. events_url on an action run is always null, and there is no MCP or CLI surface for schedules. on_active_run is skip or reject: with skip, a run that fires while another is active is recorded as skipped and never delivers a webhook; see overlapping runs.