Batched tool calls and video jobs: one jobs_wait for up to 20 clips

When a model submits several video clips in one turn, collect them with a single jobs_wait call that takes up to 20 job_ids, then read them with one jobs_result call. Anthropic's Sonnet 5.5 page says its testers found the model "batched tool calls together more than Sonnet 5", which is the behavior this pattern is built for.

Anthropic's statement is from its Sonnet 5.5 page, read 2026-09-29. It is a tester observation, not a guarantee, so check how your own runs behave. The wait and result rules below are from Sume's Jobs and results docs.

What does a batched wait accept?

Remote MCP jobs_wait takes either one job_id or a list. The list form returns a snapshot for every requested id.

Should I wait for all or any?

Use all when you need every clip before continuing, such as assembling a sequence. Use any to start work on the first finished clip. The docs say any still reports every id, and the remaining jobs continue and still bill, so it does not cancel the rest.

What if the wait slice expires?

A wait_slice_expired result means the slice ended, not that the jobs failed. Call jobs_wait again with the same ids. Do not resubmit the paid create, and do not raise timeout_seconds to wait longer: a request held that long can die at the edge with a 502, and the job keeps running and billing.

A 524, 522, 523 or 525 on jobs_wait is a transport failure, never a job outcome. Re-issue the wait or read jobs_status once.

How do I read the results of a wave?

jobs_result also takes job_ids, with the same 1 to 20 limit, and returns a job_result_batch with one entry per id in request order. Read ok on each entry: a job still running comes back as job_not_completed while finished ones return their value, and partial_failure.failed_job_ids names the ids worth re-reading.

Submitting many clips at once also meets queue limits: a full queue returns 429 queue_full, so check generation_admission_preview before a large burst.