Replicate Prefer: wait holds 60 s by default; Sume's sync cap is 30 s

Replicate's sync mode is the Prefer: wait header: the request stays open for 60 seconds by default, or for the number of seconds you give, as in Prefer: wait=5. Sume's sync mode is a mode: "sync" field with a wait_timeout_seconds value that is clamped to 0 to 30. When the wait runs out, both return a still-running object with an id; you poll it, you do not resubmit.

Replicate's behaviour is from its Create a prediction page, read on 2026-10-02. Sume's is from Jobs and results and Image generation.

How does Replicate's sync mode work?

Sync mode is enabled by setting Prefer: wait on the create request; the default hold is 60 seconds and Prefer: wait=5 waits 5. If the model finishes in time, the response is the prediction with output filled. If not, you get the incomplete prediction with status starting or processing, and you fetch it again from the Location header or urls.get.

For models that produce files, Replicate responds as soon as all files are available, so output can be filled while the status still reads processing and completed_at and metrics are empty. Async is the default mode, and a webhook plus webhook_events_filter is its alternative to polling.

How does Sume's sync mode work?

wait_timeout_seconds is clamped to 0 to 30 and bounds how long the HTTP request blocks, not how long the job takes. On the image route the default is 30. When the budget runs out, or when the server has no waiter capacity left, the response is still 2xx and still carries the job id, plus status_url, result_url, events_url and cancel_url. A sync object says timed_out or capacity_exhausted.

You then poll status_url, honouring next_poll_after_seconds, and you must not submit a new paid job for the same intent. Retrying the submit is fine if you reuse the same Idempotency-Key. Mode subscribe is an alias of sync and waits no longer.

What changes when I port a client?

The header becomes a field, and the wait budget shrinks.

What should a long video job use instead?

Sume's docs say sync is the wrong tool for anything that can outlast 30 seconds, which is most video work. Submit with mode: "async" and an Idempotency-Key, then poll GET /v1/jobs/{job_id}/status until terminal is true, and read GET /v1/jobs/{job_id}/result when result_ready is true. Or take a signed webhook and keep polling as a backup.

A client-side timeout does not cancel the job; it keeps running and billing, so keep the job id and resume from status_url.