Sume has two 429s: rate_limited and queue_full, handled differently
rate_limited is a request window. queue_full means workspace concurrency and queue capacity are both full; wait for a job to finish or cancel one.
Both are HTTP 429, but rate_limited means too many requests in the window, while queue_full means workspace generation concurrency and queue capacity are both full (read 2026-10-06 in the errors docs).
Why does the difference matter?
Full concurrency alone is not an error: while queue capacity remains, valid jobs are accepted as queued. queue_full clears only when a queued or processing job finishes or is canceled.
| Code | Cause | Fix |
|---|---|---|
| rate_limited | Request window | Wait for retry-after |
| queue_full | Concurrency and queue full | Wait for a job to finish or cancel one |
What should I do in practice?
See the generation admission page for the rules.
- Do not hammer a full queue.
- Cancel work you no longer need.
- Use the same idempotency key on retry.
Sources
Related posts
More in Developers
- Which statuses to retry when reading back a Sume job (Python)
After a Sume submit returns a job id, retry reads on 408, 425, 429, 500, 502, 503, 504 and 520 to 525. A tested Python classifier and the 409 gotcha.
- Webhook URL with user:pass@ gets a 400: verify the signature instead
Sume refuses a run webhook_url that carries credentials, plain HTTP or a private host. Authenticate your receiver with the signed headers, not the URL.
- Sume SDK 402 insufficient credits: it is returned, not thrown
Generated Sume SDK calls resolve with data, error and response. Turn a 402 into SumeInsufficientCreditsError with toSumeApiError and stop retrying.
- Sume SDK idempotencyKey: null sends no key, so POST retries stop
subscribeFormatRun mints a UUID Idempotency-Key by default. Pass null and the create call carries no key, so the SDK will not retry it on a 429 or 5xx.
Written by Sume