How many video jobs can I send now? The in-flight budget, worked
Concurrency 100, queue 500, 30 processing and 10 queued gives a new in-flight budget of 60 on Sume. Why the 450 wave hint is a hint, not your limit.

Generation admission gives one worked example that is worth copying into a batch planner. A workspace with concurrency_limit 100, queued_jobs_limit 500 and no active or queued jobs has queue_capacity_remaining 600 and a wave_size_hint of 450. The workspace is set to 100, so at most 100 new in-flight jobs are the budget in that snapshot. With 30 processing and 10 queued, the new in-flight budget is 60.
The trap is the 450. It is a submission-wave hint that includes queue slots, not a concurrency number, and the docs say never to present it as concurrency.
The two snapshots
Numbers are from the Generation admission page, read on 2026-10-03.
| Snapshot | Processing | Queued | Queue capacity remaining | New in-flight budget |
|---|---|---|---|---|
| Idle workspace (limit 100, queue 500) | 0 | 0 | 600 | 100 |
| Busy workspace (same limits) | 30 | 10 | Not stated | 60 |
How to use the number
Treat the new in-flight budget as the number of video submits to release now. Accepted capacity above it, up to the queue limit, is a buffer that Sume will hold as queued, but it is not the right target for a clean run, because queued jobs wait behind running ones and reserve balance while they wait. A full queue still means wait, even though the hint's minimum value is 1.
Release work in waves: submit the budget, poll or take webhooks until some jobs reach a terminal state, then submit the next group. Keep one Idempotency-Key per clip so a restart replays a job instead of paying for another.
A small planner
The docs list cancel as available only before generation starts. After that a cancel returns 409 job_generation_already_started and the job completes or fails normally.
- Read
generation_limitsfrom the last submit response. - Compute new work as the effective concurrency limit minus processing and queued jobs, never below zero.
- Submit that many; leave the queue buffer for retries.
- On
429 queue_full, stop adding work and wait for a terminal job; cancel queued jobs you no longer need.
Why not submit the full hint
It is tempting to submit 450 jobs because the hint says so. Sume would likely accept them as queued, but you would hold 450 reservations against the balance, and a mistake in the prompt would be paid 450 times before you noticed. Starting with the in-flight budget gives you a feedback loop: the first results arrive, you look at them, and then you release more.
This is also the cheaper way to find out that a prompt template is broken. Ten finished clips tell you more than four hundred queued ones.
Limits
The docs example uses round numbers for a large account, so it does not describe a default plan. The busy snapshot does not state a remaining queue capacity, so the table shows it as not stated rather than computing one.
Sources
Related posts
More in Developers
- No queue position or ETA for a Sume video job: what to show users
Sume exposes queue counts and remaining capacity, not a per-job queue position or ETA, and has no queue expiry option. What a video UI can say honestly instead.
- Node 22.23.3: pace Sume status polls with ratelimit headers
Read ratelimit-remaining, ratelimit-reset and retry-after from every Sume response in Node 22.23.3 and slow a wave of job polls before a 429 appears.
- Node 22.23.3 fetch: retry a Sume submit with one Idempotency-Key
Node 22.23.3 LTS bundles Undici 6.28.1. A fetch submit loop that retries 429 and 5xx with one Idempotency-Key so a retry never bills twice.
- Node-RED http request: node headers overwrite msg.headers (Sume key)
Node-RED's http request node lets node-configured headers overwrite msg.headers. Keep Sume's one credential header in the node, per-call headers in the msg.
Written by Sume