List Agent Completions newest first: audit an overnight agent
After an agent on GPT-6.1 Sol or Sonnet 5.5 ran overnight, GET /v1/agent-runs lists its Sume completions. What to read from each receipt, and what not to infer.

GET /v1/agent-runs lists your Agent Completions, newest first, using a key with the agent_completions:read scope. For an agent that ran unattended overnight, it is the first place to look: each item is an agent.run receipt like the one you got at creation, with status, usage and, when finished, output and artifacts. Read statuses and spend from it, then confirm money against GET /v1/usage, which the docs call the authoritative record.
What the docs guarantee
The Agent Completions page says GET /v1/agent-runs lists your completions newest first, that statuses are queued, processing, completed, failed and canceled, and that a run belonging to another account answers 404 agent_run_not_found. A completed run fills output, with the closing text in output.text by default and generated media under output.images, output.videos, output.audio and output.files. The page does not document paging parameters for this list, so read the live OpenAPI at api.sume.com/reference/json before you build a loop that walks past the first page.
A morning audit
Work from the top of the list and stop when you reach runs from before the night began.
| Field | Question it answers | Caution |
|---|---|---|
status | Did it finish, fail or get canceled? | queued or processing after hours is worth a look |
usage | How much generation spend was recorded? | Spend recorded for the run; confirm money against GET /v1/usage |
output | What did it produce? | Media URLs are durable media.sume.com links |
thread_id | Which fresh thread ran it? | Every completion starts a new thread |
created_at | When did it start? | Use it to order overnight runs |
What the list cannot tell you
A receipt shows what a run recorded, not why your outer agent chose to start it. Log your own side too: the instruction, the cap you sent and the Idempotency-Key. Replays of a key return the original receipt with idempotency_hit: true, so two entries in your logs can map to one run.
If a run supplied a webhook URL, Sume sends a signed POST at the terminal status and retries up to 10 attempts in total; see Run webhooks for the signature header and the retry rules. The list is your backstop when a delivery was missed.
Keep the audit key narrow
Use a key that carries only agent_completions:read for the audit job, separate from the key that creates runs. Keys created before Agent Completions shipped do not carry the scopes at all, and scopes cannot be added later. Do not print signed URLs from receipts into shared logs, as Safe automation advises.
Sources
Related posts
More in Agents
- Agent Completions gaps today: plan around streaming and PDFs
What Sume Agent Completions does not do yet: streaming, thread continuation, assistant turns, PDFs. Workarounds for GPT-6.1 Sol and Sonnet 5.5 agents.
- AI video agent vs a single-model video generator: what you call
A single-model generator returns one clip from a prompt. An agent plans shots, calls tools and assembles a video. How the Sume calls differ.
- @-mention an agent on a video asset: Runway vs Sume
Runway Enterprise lets you @-mention its Agent in asset comments. Sume Agents take work via the Agent Completions API; media jobs report by webhook.
- Re-render Sora prompts from an agent: jobs_wait takes 20 ids
An agent re-rendering saved Sora prompts should wait on up to 20 Sume job ids per call, read results in one batch, and not resubmit after a wait slice expires.
Written by Sume