Weekly trend video schedule stops early: the $1.00 default cap

If a weekly trend-video schedule produces one clip and then stops, check its spend cap. A Sume schedule with no cap set uses $1.00 of generation per run, and once a job would push the run past that, the job is refused with 402 automation_generation_spend_cap_exceeded. Set the cap on the schedule to match what the plan actually generates.

Where the number comes from

You create schedules in the Agents dashboard; the Developer API has no create or update endpoint. The generation spend cap is set there. If you do not set it, the effective default is $1.00 for each run. A caller who starts the schedule through the API can lower the cap for one run, never raise it above the schedule's cap.

The cap counts generation only. The agent's own language-model turns bill a separate wallet and are not in this number.

Sizing the cap for a weekly plan

Write the plan first: how many clips, how long, which models. Add up the estimates from the model catalog or the pricing page, add a margin for retakes, and put that in the cap. Do not guess from a single clip, since the number of clips is what changes from week to week.

A schedule that fetches trends and makes five clips needs a different cap from one that makes fifteen. If the count varies, send the count in input and let the instructions say what to do when the plan is bigger than the cap allows: make fewer clips instead of failing.

curl -sS -X POST "https://api.sume.com/v1/actions/aut_REPLACE/runs" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"input":{"clips":5,"week":"2026-W41"},"generation_spend_cap_usd":6}'

Checking what happened

Read the run's receipt. usage.billable_amount_usd_micros is the generation spend, including reserved and captured amounts, and it is the same total the cap is enforced against. If it is near the cap and the run made fewer clips than planned, the cap was the cause.

usage is null when the spend could not be read, which is different from zero.

A planning habit

Keep a small table of plan sizes beside the schedule: the small week, the usual week and the big week, each with its clip count and cap. When the instructions say how many clips to make from the input, the cap follows from the table, and nobody has to remember why it is set where it is.

If a run ends short because of the cap, treat it as information. Either the plan grew, or an earlier job in the same run used more than expected, and both are worth knowing before the next firing.

Limits

A higher cap raises the most a single run can spend, which is the point, but it also removes a guardrail. Prefer a finite, plan-sized number over null for anything that takes outside input. And a cron schedule skips a firing when the previous run is still active, so a run that now takes longer because it makes more clips can cause the next week's firing to skip.