A Sume scheduled run is not in /v1/jobs: where to read it back

A scheduled run on Sume is not a generation job, so polling /v1/jobs for its id finds nothing. Read it from GET /v1/action-runs/{run_id} (or under its schedule at /v1/actions/{action_id}/runs/{run_id}). The run is an agent working from saved instructions in a new thread, and any generations it makes are separate work inside that run.

Everything below comes from the Sume docs pages Scheduled and Runs and results, read on 2026-10-03.

Two objects, two read paths

The confusion usually starts in a monitoring script that was written for generation jobs and reused for schedules. The two have different ids (arun_ for a schedule run), different status vocabularies and different overlap handling.

What to poll

The accepted receipt carries status_url, result_url and cancel_url for the run, so a client does not need to build paths. Poll status_url until the status is terminal, then fetch result_url. The next_action field on the receipt says poll_status while the run is still going.

Because a run can contain several generations, the run's own status is the one that matters for the caller. Do not try to infer completion by listing jobs; the run decides when it is done, and its output and artifacts are populated only on completed.

Choosing between a job and a schedule

Use a generation job when you want one model invocation. Use a schedule when you want saved instructions that an agent carries out on a cadence, possibly across several generations. If the task changes on every call and there is nothing worth saving, Agent Completions is the closer fit: same agent, no saved object, with the instruction supplied per request.

The practical consequence for monitoring is to keep two dashboards or two code paths. A failed generation job and a failed schedule run have different causes and different retry rules, so do not fold them into one status enum.

Spend and cost lookups

The default generation spend cap on a schedule is $1.00 when unset, and a per-run override can lower that cap but not raise it. Because the run is not a job, cost for the run is read through the run, not by summing job rows. The MCP usage_get tool accepts a run_id starting with arun_ for exactly this purpose and reports what the wallet actually debited.

Permissions and a common 403

Run reads need a key with actions:read; creating or canceling a run needs actions:write. Keys created before the API-call trigger shipped do not carry these scopes, and scopes cannot be added to an existing key, so the fix is a new key and a rotation. Service-account keys cannot create schedule runs at all and fail with 403 insufficient_scope.

If a script that works for generation jobs returns 403 on /v1/action-runs, check the key before the code: generation scopes and actions:* scopes are separate.