Hourly Sume schedule worst case: 24 runs a day at the $1 default cap

An hourly Sume schedule with no cap of its own can spend up to $24 of generation a day: 24 runs times the $1.00 default cap. Over 30 days that is $720. The cap is a ceiling for each run, not a budget for the schedule, so the schedule's total is the cap multiplied by the number of runs that actually start.

What the cap limits and what it does not

The Sume docs say a schedule has a cron expression, a model, and a generation spend cap. If generation_spend_cap_usd_micros is null, the $1.00 default (1,000,000 USD micros) applies. The figure counts generation spend that Sume attributes to the run, reserved and captured.

The docs are explicit that the receipt figure is not the full cost. It leaves out the agent's own LLM turn, which bills the separate Agent wallet. So the arithmetic below bounds generation only. Read GET /v1/usage for the authoritative record.

Skips shrink the number, but do not rely on them

With the default on_active_run of skip, a run that starts while another is active is recorded as skipped and does no work. So a slow schedule runs fewer than 24 times a day. That lowers the real figure, but it also means the work you scheduled is not getting done, so do not treat skipping as a budget control.

A skipped run is not delivered by webhook, and a canceled run is not either, so spend you expect to see may simply be missing runs. Use the run list to count completed runs against the table.

A practical habit is to write the daily and 30-day lines next to the cadence when you create the schedule, so whoever changes it later sees the exposure change, for example from every 6 hours ($120.00) to hourly ($720.00), a sixfold increase from one edit.

Lowering the ceiling

Set the cap in the dashboard at the amount one run should ever spend. On an API-triggered run, generation_spend_cap_usd is clamped to the minimum of the request and the schedule cap, so a request can lower the cap and never raise it. A request value of 0 is rejected, and null runs without the automation ceiling, which leaves wallet balance and admission as the only limits. Do not send null from unattended code.

Also note what the table leaves out. It assumes each run uses its whole cap, which a short task will not. It also assumes the schedule stays active. Setting a schedule to inactive makes it reject API runs, so pausing it is the quickest stop when a daily figure looks wrong.

• Multiply the cap by the maximum runs per day, not by a typical day.
• Put a cap that matches one run's real need, not the default.
• Count completed runs from the list endpoint and compare with usage.
• Add the Agent wallet separately; the cap does not include it.