Sume timeouts in one table: 30 s, 55 s, 10 s, 90 minutes

Sume has seven different waits and they do not mean the same thing: sync blocks for at most 30 seconds, MCP jobs_wait holds for 50 seconds by default and 55 at most, a webhook attempt gets 10 seconds, the SDK's waitForRun stops after 10 minutes and waitForJob after 20, and a Format run is force-finalized 90 minutes after it was created. Only the last one ends the work. The others end your wait.

The numbers in one place

The table groups each number by who is waiting. The key column is the last one: whether the timeout touches the job. For every client-side timeout the answer is no, which is why the right response is to read the status again and not to submit again.

Why 30 and 55 are not job durations

The 30-second number limits how long one HTTP request stays open, and the docs spell out that it is not how long a job can take. Images often finish inside it. Video, avatar-video and face-swap jobs usually do not. When the budget ends the response is still a 2xx with the job id and a sync.timed_out flag, and your next step is a status read, not a new submit.

The MCP number exists for the same reason. A request held open for ten minutes dies at an edge proxy before it can answer, so jobs_wait returns a wait_slice_expired result after at most 55 seconds, and the loop is yours: call it again with the same job ids.

The one that does end work

A Format run has an expires_at that is 90 minutes after creation, or sooner if the run goes silent. When it passes, Sume finalizes the run as failed, so it is the only deadline in the table that ends work. If your own timeout is shorter than 90 minutes, a run you gave up on can still be running and still be billing, and the only way to stop it is to cancel it while the cancel still works.

Pick your client timeouts from the product. A single image can take a short poll loop. A video should be a webhook with a poll fallback, and a long Format run should store the run id and check back.

Setting your own numbers

Your serverless platform has its own limit too, and it is often shorter than any number above. A function that waits for a 20-minute waitForJob will be killed first, which means your timeout is the platform's, not Sume's. Submit, persist the job id, return, and let a webhook or a scheduled poll finish the work.

Keep two clocks in your own code: a per-request deadline for the call you are making now, and a per-job deadline that you store with the row. When the job deadline passes, read the status once more, then decide whether to cancel.

Do not copy a number from this table into a retry loop without the idempotency rule next to it. The SDK client retries 408, 429 and 5xx twice, and it retries a POST only when you passed an idempotency key, so a missing key is the difference between a safe retry and a second paid job.