jobs_wait defaults to 50 seconds: how many calls for a long render

A render that takes N minutes needs at most ceil(N x 60 / 50) jobs_wait calls on remote MCP, because the default wait slice is 50 seconds and the cap is 55. Each call returns as soon as the job is terminal, so the last call is usually short. Every call after the first uses the same job id: you wait again, you never submit the paid create again.

Why the slice is bounded

A jobs_wait call is one HTTP request that stays open for the whole slice with no data moving. Edges close such requests, and the caller then sees no tool result while the job keeps running and billing. So the server enforces the bound: timeout_seconds defaults to 50 and is capped at 55 on remote MCP. A larger value is clamped, not rejected, and the response tells you in wait_slice_clamped. The API accepts values up to 600 and clamps them.

This is the same shape as the 30-second cap on the HTTP sync mode: a limit on how long a request blocks, not on how long a job can run.

Handling the slice outcome

When a slice ends before the job does, the outcome is wait_slice_expired. Retry jobs_wait with the same ids. A 524, 522, 523 or 525 on jobs_wait is a transport failure and never a job outcome: issue the wait again, or read jobs_status once. Do not report the job as blocked and do not submit the create again.

For a wave of jobs, job_ids takes 1 to 20 ids with wait_for of all or any. Pass include_results: true and each completed id returns its jobs_result in results[], so a wave needs no second read. results_omitted.job_ids names the ones that did not fit; read those with one batch jobs_result.

Budgeting an agent loop

Each call is a tool call from the model's point of view, so a 10-minute render consumes about a dozen calls of an agent's step budget if you wait with the default. The calls cost nothing in generation spend because they are reads, but they do count against the step cap of whatever framework runs the agent. If the framework's cap is lower than the table suggests, move the wait out of the model loop: have your own code poll GET /v1/jobs/:id/status and give the agent only the finished result.

Keep jobs_wait for the cases where the agent should stay in the conversation, and use the bounded batch form so that a fan-out of 20 clips takes one call per slice, not 20.

Choosing the batch size

jobs_wait takes up to 20 job ids in one call, so a wave of ten renders is one wait, not ten. Each call still has a ceiling of 55 seconds, with 50 as the default, so a long render needs several waits in a loop. With include_results set, a completed job's result comes back in the same response and you can skip the second read.

Treat each wait as a slice, not a promise. A response that comes back with some ids still running is normal: take the finished ones, and call again with the ids that remain. Loop until none remain or until your own deadline passes. If you hit your deadline, stop waiting; the jobs keep running and you can read them later.

Count calls by dividing the expected duration by the slice you chose. A longer render needs more slices, and the arithmetic above shows how few calls a batch needs.

• Batch up to 20 ids per call.
• Set include_results to skip a read.
• Loop on the ids that remain.
• A deadline in your code is not a cancel of the job.