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.
A video product usually wants a progress bar, and Sume does not provide one for the queue. The generation admission page states it under current boundaries: Sume exposes queue counts and remaining accepted capacity, not a precise per-job queue position or ETA. Queue expiration and a client-supplied fail-fast queue length are not public API options either. So the honest interface says what state the job is in and when you will look again, and nothing more precise.
This note shows the three states you can display truthfully and the fields behind each.
What the API does give you
The states and fields below come from the jobs and admission pages, read 2026-10-03.
| Job state | What you know | What to show |
|---|---|---|
| queued | Accepted, waiting for a processing slot | Queued, with no time estimate |
| processing | Running or being finalized | Working |
| completed | Result ready | Done, with the file |
| failed | Terminal failure with a public error | Failed, with the category and next action |
| canceled | Cancellation requested and terminal | Canceled |
Fields that help without inventing an ETA
The status response carries booleans, terminal and result_ready, and a next_poll_after_seconds value when present; the docs tell clients to honor it and to back off otherwise. The submit response carries generation_limits, which gives queue counts. You can show "N jobs ahead in your workspace" only if you compute it from your own records, since Sume does not report a position for a single job.
Do not turn queued into a failure. The docs say queued is a normal accepted state, and workspace concurrency limits apply when workers move jobs into processing, not when the API accepts them.
Copy that stays true
If you still want a duration cue, record your own completed jobs per model and show a range from your history. Label it as your own average.
- Say "Queued" or "Rendering"; avoid "about 2 minutes".
- Show the time since submit, which you measure yourself.
- Offer cancel while the job is queued, since it works only before generation starts.
- On failure, show the public reason and the next action from the job error, not a generic message.
Measuring your own numbers
Because Sume does not publish a time, you can build one from your own history. Record the submit time and the terminal time for each job, grouped by model id and resolution. After a few dozen jobs, the median and the slowest tenth are real numbers about your traffic.
Show them as a range with a label such as "Your recent clips took". If your sample is small, say nothing. A wrong estimate that users learn to ignore is worse than none.
Limits
The docs do not publish typical render times for any video model and they describe the queue as capacity by plan. This post does not give a time, and it does not claim one will appear later.
Sources
Related posts
More in Developers
- 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.
- Node-RED http request node: submit a Sume job and branch on statusCode
Node-RED's http request node returns payload, statusCode and headers. Wire a Sume submit, branch on 202 vs errors, and keep the job id for the status read.
Written by Sume