jobs_wait timeout_seconds 600 returns at 55 seconds, clamped

If you call Sume's remote MCP jobs_wait with timeout_seconds: 600, it returns after at most 55 seconds, not ten minutes. Values up to 600 are accepted and clamped rather than rejected, and the response says so in wait_slice_clamped. The default is 50 seconds.

So a long render is waited out by repeating the wait, not by asking for a longer one. The behavior is documented on the Jobs and results page.

Why does Sume clamp the wait?

A wait is one HTTP request held open for the whole slice with nothing transferring, and every edge closes such a request eventually. When that happens the caller gets no tool result at all, while the job keeps running and keeps billing. The docs also note that a held request of ten minutes dies at the edge (502 or Transport send error) before it can answer, which is why there is no longer a thread-header 600-second server-side hold.

Clamping gives you a predictable ceiling instead of a silent transport failure.

What should I loop on?

Repeat the wait until the ids are terminal, with a deadline of your own. The arguments below show the shape; your MCP client sends them as a jobs_wait tool call:

// jobs_wait arguments, repeated with the SAME ids until every id is terminal
{ "job_ids": ["job_a", "job_b"], "timeout_seconds": 50 }

// timeout_seconds 600 is accepted but clamped to 55;
// the answer carries wait_slice_clamped to say so

Is a longer slice ever the right answer?

Not on the remote MCP endpoint. The cap is enforced by the server, so changing client settings will not extend it, and a client whose own tool timeout is shorter than 55 seconds will give up before the slice ends. The two numbers have to agree: your client's per-call timeout must be longer than the slice you ask for, or the client fails first and reports a transport error while the job is fine.

Over the HTTP API the same idea appears in a different form. sync and subscribe modes wait at most 30 seconds on the submit call, and wait_timeout_seconds is clamped to 0 through 30. That bounds how long the request blocks, not how long the job takes. For anything that can outlast the wait, submit with async, store the job id, and poll status_url honoring next_poll_after_seconds when it is present.

In both cases the principle is the same. The wait lives in your client, where a deadline of minutes costs nothing, and not in a held HTTP request, where it costs a dropped connection and a lost answer.

What if I get a 524?

A 524 (or 522, 523, 525) on jobs_wait is a transport failure, never a job outcome. Re-issue jobs_wait on the same ids, or read jobs_status once. Do not resubmit the paid create and do not report the job as blocked.

The discipline that is documented is slices of at most 55 seconds, the same ids on every retry, and no resubmit. Put your own overall deadline around the loop, for example 20 minutes for a video wave, because the server will never hold longer than one slice.

A client-side deadline stops you from watching, but it does not cancel the job. If you no longer want the work, request cancellation, which succeeds only before generation work starts; afterwards the API returns 409 job_generation_already_started. See MCP jobs_wait for long video jobs for the longer walkthrough.