A 10-minute render needs 11 to 12 jobs_wait calls, not one long one

The count

A single jobs_wait on Sume's hosted MCP holds for at most 55 seconds, and the default is 50. For a render that takes 10 minutes (600 seconds), that is 600 / 55 = 10.9, so up to 11 calls at the cap, or 600 / 50 = 12 calls at the default. Each call returns when the job is terminal, so the last one is usually shorter, and a job that finishes early needs fewer.

The documented guidance is to wait again, not to ask for a longer wait. Sume does not extend the hold for you.

Why the hold is bounded

A wait is one HTTP request that stays open for the whole slice, and no data moves during it. Every edge between you and the server closes such a request at some point, and then your client gets no tool result while the job keeps running and billing. Sume bounds the slice so the answer arrives before that happens.

If you pass a bigger timeout_seconds, the API accepts values up to 600 and clamps them to 55 on remote MCP. The response tells you about the clamp in wait_slice_clamped. When a wait runs out, the outcome is wait_slice_expired. Retry with the same ids.

What your client must be set to

Set your MCP client's tool-call timeout above 55 seconds, with some margin for the network. The docs do not name a client number, so pick one you can defend, such as 60 to 90 seconds, and keep your agent from treating a quiet slice as a failure.

A 524, 522, 523 or 525 on jobs_wait is a transport failure, never a job outcome. Issue jobs_wait again on the same ids, or read jobs_status once. Do not report the job as blocked, and do not submit the paid create a second time.

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

The rule that protects your wallet

The create call carried an idempotency_key. The wait does not need one, and it does not spend. If your process restarts, recover with the job id you stored from the create response and carry on waiting. Resubmitting the create with a new key starts a second paid job.

Use exponential backoff on jobs_status if you poll over REST instead, and stop on completed, failed or canceled.

• Default 50 s, cap 55 s, on remote MCP.
• A wait returns the moment the job is terminal.
• operator_stopped means Sume operations stopped the job; waiting again will not change the answer.

A loop that survives restarts

Write the loop so that all state lives in the job id. Call jobs_wait with 55 seconds, and if the outcome is wait_slice_expired call it again. After a handful of slices, log one line with the job id and elapsed time so a human can tell a slow render from a stuck loop.

Put a ceiling on total waiting that matches the work. For a 10-minute render a 20-minute ceiling is generous. When it trips, read jobs_get once, report the status and the job id, and stop. Do not create the job again.

• Keep the client tool timeout above 55 seconds.
• Store the job id before the first wait.
• Treat gateway errors as retryable waits.