Runway THROTTLED task status vs Sume queued jobs

On Runway's API, a task submitted beyond your concurrency limit gets the status THROTTLED: it is stored on Runway's servers but not enqueued for processing yet. Runway says it is safe to treat THROTTLED as PENDING. Sume reaches the same place with a plain queued job, and returns 429 queue_full only when the queue itself is at capacity.

What Runway documents

Runway's concurrency page says the limit is the maximum number of tasks that can run at once, and extra tasks are throttled and enqueued in approximately the order they were submitted. Its monitoring advice adds a metric: count your throttled tasks, because many of them can mean your integration is nearing the generation limit.

What Sume does

Sume accepts a valid job as queued and moves it to processing when a concurrency slot opens. Capacity defaults to max(3, concurrency_limit x 5), and the generation_limits object shows your effective numbers. Only when that queue is full does a submit fail with 429 queue_full.

One client rule

Both systems ask for the same discipline in a client, so write it once.

• Treat every non-terminal status as waiting, including ones you have not seen yet.
• Alert on how many jobs sit in the waiting state, not only on failures.
• On Sume, retry a queue_full with the same idempotency key.
• Never cancel and resubmit just because a job is waiting.

Put a limit on waiting

Runway's page does not say how long a throttled task may wait, so do not assume a bound. Build your own timeout and cancel on your side when a job passes it.