Waiting 10 minutes for a Sume render over MCP: 11 jobs_wait calls

To wait 10 minutes for a Sume job over hosted MCP, call jobs_wait again each time it returns wait_slice_expired. At the 55-second cap that is at most 11 calls (600 divided by 55 is 10.9, rounded up). At the default of 50 seconds it is 12. A wait returns the moment the job is terminal, so these are worst cases. Do not ask for a longer timeout and do not submit the paid create again.

What Sume documents

Per the Jobs and results page (read 2026-10-08), the remote MCP default for timeout_seconds is 50 and the cap is 55. The API accepts values up to 600 but clamps them, and the response tells you in wait_slice_clamped. The page gives the reason: a wait is one HTTP request that stays open for the whole slice with no data moving, and each edge closes such a request at some time. The caller then gets no tool result while the job keeps running and billing.

• Default timeout_seconds: 50. Cap: 55.
• On wait_slice_expired, retry jobs_wait with the same ids.
• A 524, 522, 523 or 525 on jobs_wait is a transport failure, never a job outcome.
• After such a failure, issue the wait again or read jobs_status once.

Calls needed by render length

The count is ceil(seconds divided by slice length). The table assumes the job is still running at every slice, which is the worst case.

The call to repeat

Send the same arguments each time. Only the job id and the timeout matter; do not add a new idempotency_key, because jobs_wait is a read and creates nothing.

{
  "job_id": "job_123",
  "timeout_seconds": 55
}

With a wave of jobs

If you fanned out several jobs, pass job_ids (1 to 20 ids) with wait_for set to all (the default) or any. The response is a job_wait_batch with one status snapshot per id, so a 10-minute wave still costs about 11 calls in total, not 11 per job. With wait_for: any, the other jobs continue to run and bill. If you set include_results: true, each completed id returns its result in results[], and results_omitted.job_ids names any that did not fit; read those with one batch jobs_result.

One id that is unknown or belongs to another workspace makes the whole call fail, so keep the id list clean. If a job comes back with outcome: operator_stopped, Sume operations stopped it, it is terminal, the holds are refunded, and waiting again cannot change the answer.

What the agent should say

While the job is still running, the honest status is that it is still rendering. Do not report it as blocked or failed, and do not deliver a partial result. Stop re-waiting when the status is completed, failed or canceled, or when your own deadline passes. Then read the result with jobs_result, which works only after completion.