Schedule fires while the last run is active: skip or reject?

If a Sume schedule is triggered while its previous run is still active, the default on_active_run: skip returns 200 with a receipt whose status is skipped and skip_reason is previous_run_active. The alternative, reject, returns 409 action_run_in_progress and records no run. Choose reject when a dropped trigger must look like an error to your caller.

The two behaviors

The API trigger docs define both values for runs started by API.

Why this comes up with model choices

Agent runs are not fixed length. A run opens a sandbox, calls tools, and can generate media. A larger, slower planning model, or a run with more tool calls, can still be going when the next trigger lands. A fast model such as Claude Haiku 5.5, which Anthropic describes on its page (read 2026-10-08) as its fastest and most efficient in the 5.5 family, shortens the planning part, but it does not bound the media generation that follows. So pick the overlap policy on purpose rather than hoping runs never collide.

Choosing

Use skip for idempotent, level-triggered jobs, such as "refresh this week's teaser", where a second trigger during a run adds nothing. Use reject for event-triggered jobs, such as "render this order", where a lost trigger means a lost customer action and your service should retry or alert.

Format runs differ. Their default is allow, which permits concurrency. The Scheduled docs call out the different defaults, so do not assume a Format-trained habit carries over.

What your monitoring sees

A skipped run does not deliver a webhook, because no work started. The create response already told you, so read status on the response you got and do not wait for a POST. A rejected trigger creates no run at all. Log the 409 and its code.

If you also use run webhooks, remember the cancel path: a canceled run does not deliver one either, so poll status_url until the payload status is canceled.

Add an idempotency key either way

Send Idempotency-Key (1 to 255 characters) on every trigger. A replay with the same key returns the original receipt with idempotency_hit: true, so a network retry does not look like an overlap.

A timeline

Suppose a trigger arrives every 15 minutes and each run takes 25 minutes. The run at minute 0 ends at minute 25. The trigger at minute 15 finds it active and is skipped. The trigger at minute 30 starts a run that ends at minute 55. The trigger at minute 45 is skipped, and the one at minute 60 starts. So half of all triggers are skipped, with no error anywhere. If that surprises you, either lengthen the interval beyond the run time or switch to reject so each dropped trigger becomes a visible 409.

Whichever you choose, make the choice visible in code review. The field is on_active_run, and the body only accepts the properties listed in the docs; the API silently drops unknown top-level properties instead of rejecting them. A misspelled on_active_runs would therefore quietly leave you on the default skip. After you set it, send one test trigger while a run is active and confirm you get the response you expect.