Runway THIRD_PARTY.UNAVAILABLE: retry rules vs Sume's codes

Runway's task-failure page says a THIRD_PARTY.UNAVAILABLE failure comes from a third-party model being unavailable, for example an outage or load shedding, and tells you not to retry immediately because it is unlikely to succeed; you may wait and retry. Sume's closest category is generation_unavailable, whose documented next step is "Retry later".

Runway text is from its Dev docs and Sume text from Errors and rate limits, both read 2026-10-01.

What does Runway say to do?

Wait, then retry. The page gives no wait time and no retry count. It attributes the failure to the provider of the model, not to your input.

Which Sume codes are the same kind of failure?

Three different things can look like an outage from the caller's side, and Sume names them separately.

Which of them keeps the same idempotency key?

The ones rejected at submit, before work is accepted, are retried with the key you already used. For a failed job the category table gives plain "retry later" for generation_unavailable. A job that ended failed is finished. On Format runs, the error's retryable and retry_after_seconds fields say whether resending can succeed and how long to wait first (see Formats errors). Whether a failed job's key may be reused is covered in failed run retry needs a new key.

How should I pace the wait?

Use retry_after_seconds when it is set on a Format run error, and retry-after on a 429. Cap your own attempts; the docs say not to retry runtime_unavailable aggressively. For the rate-limit side of this, see 429 versus 503.