Can an API caller raise a Sume schedule's spend cap? No

No. When you start a Sume schedule run over the API, generation_spend_cap_usd is clamped to the smaller of your request and the schedule's own cap. A request can lower the cap for one run. It cannot raise it. Sending 0 is rejected with a 400, and sending null removes the automation ceiling for that run.

The clamp rule

The API trigger docs define the field as a number greater than zero, or null, with the schedule's cap as the default. The rule is min(request, Action cap). That makes the schedule owner, who sets the cap in the dashboard, the authority on the ceiling, and it makes your calling service safe to be sloppy about the number.

Six cases

Assume a schedule whose cap is $1.00.

What null does and does not mean

null is the sharp edge. The docs say it runs without the automation ceiling, and that wallet balance, generation admission, and org limits still apply. That is not a safe default for an unattended caller. If your code builds the value from a config lookup that can come back empty, a missing entry could turn into null and lift the ceiling. Validate the number before you send it, and send a number.

When no cap is set on the schedule

The Create a schedule page says an unset cap means an effective default of $1.00 for each run. On the receipt, generation_spend_cap_usd_micros of null on the schedule object also means the $1.00 default applies, per the Scheduled overview.

Why this matters when the model changes

New fast models, such as Claude Haiku 5.5 on 2026-10-07, make agents cheaper to think with, and cheaper thinking tempts teams to loosen limits. The spend cap does not measure thinking at all: the receipt figure is generation spend and excludes the agent's own LLM turn. A cheaper model changes the Agent-wallet side of the bill. It does not change what this cap protects.

Practical settings

The points that matter here, in the order you will hit them:

• Choose the schedule cap as the most you accept for any single run.
• Let callers lower it per run for cheap variants.
• Reject null in your own code unless you mean it.
• Compare the cap with GET /v1/usage after the run.

Reading the cap on the receipt

The cap appears on the run receipt in USD micros, where 1,000,000 micros equal $1.00. The Agent Completions example in the docs shows generation_spend_cap_usd_micros: 5000000, which is a $5.00 cap. When you debug a surprise, compare that integer with the spend figure on the same receipt rather than with what your code meant to send. If the integer is smaller than expected, the clamp lowered it. If the schedule shows null, the $1.00 default applies. Remember that Agent Completions differ: there the cap is required on every call and has no default, so the clamp story applies to schedule runs, where a saved cap exists.