Runway Dev usage exception request vs Sume 429 and 402

Runway Dev's docs mention self-serve tiers and say you can submit an exception request for higher usage, but the text we received did not give rate-limit numbers. On Sume a burst of ad variants is limited by two documented errors: 429 rate_limited, which says wait, and 402 insufficient_credits, which says your workspace balance is below the reserve for the job. Neither needs a support ticket to understand, and both have a fix in your code.

What Runway's page states

On 2026-10-07 the Runway Dev docs home said that usage tiers are self-serve and that you can submit an exception request if you need more. Enterprise customers were described as getting faster support and earliest access to new features. No numbers for requests per minute or credits per second appeared in the text we retrieved, so we cannot compare capacity.

The two Sume errors you will actually hit

The /v1/videos error table lists 429 rate_limited and 402 insufficient_credits. The credits error has a precise cause: Sume reserves the workspace USD balance on submit, priced at the provider list times 1.25 for each model. If the balance is below that reserve, the submit fails before a job exists.

Bulk Format queues add their own wrinkle. A create call spends the write budget and can return 429 with a retry-after header. The docs say to wait the number of seconds in retry-after. Child runs go through ordinary admission, so a child that cannot start (wallet, concurrency or spend cap) becomes a failed item and the rest of the queue continues.

A retry rule for a variant batch

Treat the two errors differently. A 429 is transient: wait and resend the same body with the same Idempotency-Key. A 402 is not transient: no amount of waiting fixes it, so stop the loop, top up, and resubmit only the variants that never got a job id.

The Idempotency-Key header is supported on /v1/videos. Reusing a key with a different body is a 409 conflict, which protects you from accidentally attaching a new prompt to an old variant id.

• 429: sleep for retry-after, resend with the same key.
• 402: halt, check GET /v1/balance, top up, resend only unsent variants.
• 409 conflict: your key was reused with a different body; mint a new key.

What this does and does not tell you

It does not say Sume allows more throughput than Runway. We do not have comparable numbers for Runway, and we do not publish a requests-per-minute figure here. It says that on Sume the failure modes of a burst are documented, machine-readable and fixable in code, so a batch can be written to stop or wait without human review.

Putting the guard in code

A small wrapper keeps the batch honest. Submit variants one at a time, branch on the HTTP status, and record the job id next to your variant id. The sketch below is JavaScript for Node 18 or later and uses only fetch. It sleeps for retry-after on a 429, stops on a 402, and returns the id on a 202.

Keep the loop sequential for the first run so you can see which status shows up. Once you know your batch fits, move to a bulk Format queue, where the server holds the concurrency window for you.

const H = { Authorization: `Bearer ${process.env.SUME_API_KEY}`, 'Content-Type': 'application/json' };
async function submit(variantId, body) {
  for (;;) {
    const r = await fetch('https://api.sume.com/v1/videos', {
      method: 'POST',
      headers: { ...H, 'Idempotency-Key': variantId },
      body: JSON.stringify(body),
    });
    if (r.status === 429) {
      await new Promise((ok) => setTimeout(ok, 1000 * Number(r.headers.get('retry-after') || 5)));
      continue;
    }
    if (r.status === 402) throw new Error(`stop: balance below reserve at ${variantId}`);
    if (r.status !== 202) throw new Error(`${r.status} ${await r.text()}`);
    return (await r.json()).id;
  }
}
submit('hook-a-v1', { model: 'seedance-2', prompt: 'Mug on a desk, steam rising', duration: 5 }).then(console.log);

Budgeting the reserve

Because Sume reserves list times 1.25 on submit, a batch needs at least the sum of the reserves in the wallet at the moment of each submit, not only at the end. Check GET /v1/balance before a burst and compare it with your own estimate per clip, and keep the number of in-flight variants small until you have seen a real usage.cost on a completed job.