Claude Desktop task can reschedule itself; a Sume schedule cannot

A Claude Code Desktop scheduled task can change its own schedule or prompt while it runs, through the update_scheduled_task MCP tool, for example to run a review earlier when it sees a release branch (Claude Code docs, read 2026-10-04). A Sume schedule cannot do that: the trigger type is fixed at create time, and the Developer API has no create or edit call.

If you want an agent to decide when Sume work runs, use the API trigger and let your own service make the decision.

What Sume fixes at create time

A Sume schedule is a saved automation with instructions, a model, a cron expression and a spend cap. Its trigger_type is cron or api and cannot be changed afterwards. An API-only schedule can never gain a cadence, and a cron schedule can never drop to API-only. A cron schedule can also enable the API trigger and accept both (Scheduled).

The Developer API can list schedules, read them, start runs and monitor runs. It cannot create, edit or delete them, and schedules are not exposed as an MCP tool or a CLI command.

Desktop self-edit vs Sume

The table shows who can change what after the first save.

The pattern that works: let the API trigger decide

Enable the API trigger on the schedule. Your service, or an agent behind it, calls POST /v1/actions/{action_id}/runs when the condition is met. The invoke endpoint needs actions:write, the schedule must be active, and an inactive schedule answers 409 action_inactive.

Send an Idempotency-Key on every call, and optionally a lower generation_spend_cap_usd for that run. A number above zero is clamped to the smaller of the request and the schedule cap.

curl -sS -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: release-branch-2026-10-04" \
  -d '{"generation_spend_cap_usd": 0.5}'

Before you let an agent decide when to run

Two properties make this safe enough to automate. The Action API trigger defaults to skipping a new run while another is active, so a double trigger records a skipped run rather than starting a second paid one. And the per-run cap can only be lowered from the schedule cap, so the agent that calls the endpoint cannot raise the spend ceiling you set in the dashboard.

• Create the schedule once in the dashboard, with the cap you are willing to pay per run.
• Enable the API trigger, copy the invoke endpoint, and keep the key in your service, not in a prompt.
• Send an Idempotency-Key that names the event, so a retry replays the original receipt.