Scheduled AI runs: default spend cap is $1.00, only lowerable

A scheduled Action's spend cap defaults to $1.00 when unset. A per-run generation_spend_cap_usd is clamped to the smaller value. null lifts the ceiling.

4 min readSume
All posts

A scheduled Sume Action has a per-run generation spend cap, and when nobody set one the default is $1.00 (1000000 USD micros). A run started through the API can pass generation_spend_cap_usd, but a number is clamped to min(request, Action cap): it can lower the cap and never raise it. null runs without the automation ceiling, and 0 is rejected with 400.

This is from the Scheduled overview and API trigger docs, read 2026-09-29. A video-heavy schedule can need more than $1.00, so raise the cap where you author the schedule.

What does the cap rule look like?

Per-run cap rules, from API trigger, read 2026-09-29.
Request fieldEffective cap
OmittedThe Action's cap (default $1.00)
A number above 0min(request, Action cap)
nullNo automation ceiling; wallet balance, generation admission and org limits still apply
0400

Where can I read a schedule's cap?

GET /v1/actions/{action_id} returns generation_spend_cap_usd_micros, or null when the default applies. The API cannot create, edit or delete a schedule: you author it in the dashboard or by chat, and the API lists, reads and runs it.

curl -X POST https://api.sume.com/v1/actions/$ACTION_ID/runs \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{ "generation_spend_cap_usd": 0.5 }'

How do I see what a run spent?

Read GET /v1/action-runs/{run_id}: usage.billable_amount_usd_micros is the generation spend attributed to the run, counting reserved and captured amounts, and it settles when the run ends. It is the same running total the cap is enforced against.

What should I check before an overnight schedule?

  • Compare the cap with one manual run's spend, then add headroom.
  • Keep on_active_run at skip if overlapping triggers are harmless, or reject if a dropped trigger should be an error.
  • Watch runs with the monitoring endpoints, not by refreshing the dashboard.

Which run statuses can I see?

Action runs use queued, processing, completed, failed, canceled and skipped. A skipped run carries skip_reason: previous_run_active. The run's events_url is always null, so poll status_url and result_url instead, or use run webhooks.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume