Prevent overlapping AI agent runs on Sume with on_active_run

To prevent overlapping AI agent runs on Sume, send on_active_run with the run request: skip records a skipped run instead of starting a second one, and reject refuses the request with a 409. Format run requests default to allow and run side by side; API run requests to a schedule (an Action) default to skip.

The rules below come from Sume's Create a run, Advanced: run a schedule via API, and Run webhooks docs pages, read on 2026-09-26. Setting up a schedule is covered in Scheduled AI video agent runs.

What does each on_active_run value do?

The check is per Format or per schedule: what to do when a run of this Format is already in flight, or when a run of this Action is active. The schedule's API-trigger docs add that only one run of an Action is active at a time.

Should I skip or reject the second request?

The schedule docs give one rule: use reject when a dropped trigger should surface as an error in your caller, and skip when overlapping triggers are expected and harmless. For the 409, the schedule docs say retry later or use skip, and the Format docs say wait, or drop reject. Keep allow on a Format only when runs may safely execute side by side.

curl -sS -X POST "https://api.sume.com/v1/formats/acme/product-promo/runs" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: catalog-sync-2026-09-26" \
  -d '{
    "input": { "product_url": "https://example.com/p/8823" },
    "on_active_run": "skip",
    "generation_spend_cap_usd": 20
  }' | jq '.data | {status, skip_reason, next_action}'

How do I recognize a skipped run?

A skipped run never ran: another run was in flight. It is terminal on the create response, carries a skip_reason, and its next_action is retry_later, the step both surfaces reserve for skips. On a schedule the reason is previous_run_active.

Branch on the receipt's status, not the HTTP status. On a schedule, 200 means either an idempotency replay or a skip, and 200 does not mean the work finished.

Does a skipped or rejected run cost money or send a webhook?

On a Format run, a skipped run costs nothing, and a 4xx at create, the 409 included, means nothing ran and nothing was charged. On a schedule, a skipped run never started work, and a rejected request records no run at all.

Neither sends a webhook. A skipped run records a terminal run immediately without starting work, so there is no completion to notify you about: read status on the create response instead of waiting for a POST. A rejected request is refused at create, so nothing ran and there is nothing to report. Webhooks fire once per run, when it completes or fails.

How is this different from an idempotency key?

They solve different problems. An Idempotency-Key replays the same request: the same key with the same payload returns the original receipt with idempotency_hit: true, and no second run starts. on_active_run governs a different request that arrives while a run is active. Send both when a retry and a second trigger can both happen. Key design is covered in idempotency keys for AI video APIs.

Where does on_active_run behave differently?

Watch these four cases:

• Cron fires: the docs define on_active_run as a field of the API run request, and they document no overlap setting for runs a cron expression starts.
• Bulk queues run every item with on_active_run: "allow", so skip or reject on an item does not stall the window. Workspace generation concurrency still applies to the children.
• Agent Completions list no on_active_run field. Each completion runs in a fresh thread.
• Copying a schedule body into a Format call changes the behavior: the Format docs say not to, because schedules default to skip and Formats to allow.