Which Sume timeout is which: sync, jobs_wait, waitForJob, webhooks

Sume has no single timeout. The sync wait is capped at 30 seconds, the remote MCP jobs_wait tool waits 50 seconds by default, the TypeScript waitForJob helper gives up after 20 minutes, and a webhook attempt must answer within 10 seconds. None of these cancels the job when it expires, so a timeout is a reason to poll again, not to resubmit.

The table below puts every wait side by side with its unit, because the mixed units (seconds in the API, milliseconds in the SDK) cause most of the confusion.

Every wait in one table

Values come from the Sume jobs, webhooks and SDK run docs, plus the SDK source, read 2026-10-10.

The two traps

The first is units. wait_timeout_seconds takes seconds; timeout: 600 in waitForJob is 600 milliseconds, not ten minutes. Write 10 * 60_000 so the unit is visible in the code. The second is that the MCP tool and the REST parameter differ: the API accepts a larger wait value and clamps it, while the MCP tool is capped at 55 seconds. Do not assume that a longer number buys a longer wait.

• Use sync mode only for work that normally finishes inside 30 seconds; for video, submit with mode: "async".
• Treat any wait expiring as "not finished yet": read GET /v1/jobs/{id} and look at status and next_poll_after_seconds.
• Never cancel a job just because your own timer fired; a canceled job is a separate call.

Choosing the right wait

A browser-facing request has a few seconds of patience, so submit async and return the id. A worker can use waitForJob with a ten-minute budget and let the server hint pace its polls. A fire-and-forget pipeline should use a webhook and stop polling at all, with a polling sweep as the backstop for a missed delivery.

One more consequence: because expiry never cancels, a script that times out and resubmits the same prompt can end up paying twice. Reuse the original job id, or resubmit with the same Idempotency-Key.

Worst case for a webhook

A webhook that never answers has a bounded cost. Each attempt can use up to 10 seconds, there are 10 attempts, and the docs give a 30-second spacing between them. Ten attempts of 10 seconds plus nine gaps of 30 seconds is 370 seconds, or a little over six minutes, before delivery is marked exhausted.

Your fallback poll should therefore start after that window, not before. A sweep that lists active jobs every few minutes catches any completion your endpoint missed without hammering the read budget.