Sora back-catalog re-render: check balance before you submit

Before you queue a Sora back catalog on Sume, compare your balance with the reservation each job needs. The errors guide lists 402 insufficient_credits for a balance that cannot cover the requested generation, and the admission guide says Sume reserves the estimate at submit and rejects before provider work starts. Total the estimates for a wave from the model list, read GET /v1/balance, and submit only what fits.

What happens to the money

The reservation lifecycle is short. At submit, Sume reserves the estimated USD amount. A completed job captures it. A failed job or a failed queue admission releases or refunds the reservation where applicable. The video docs add that the reserved amount is provider list times 1.25 for every model, and that usage.cost on the poll response is the billable amount.

Size the wave from the catalog

Read pricing_skus for each model from GET /v1/videos/models; the price basis differs by model (the example in the docs is a per-1000-video-tokens SKU), so do not hard-code a per-second figure. Compute an estimate per prompt from your duration and resolution, multiply by the number in the wave, and compare with the balance minus a safety margin. If you cannot compute an estimate for a model, submit one job and read what the balance drops by, then scale.

Handle a 402 in the middle of a run

A 402 is not retryable by waiting alone. The admission guide's client behavior is to add funds through your plan, wait for included Gen$, or submit a cheaper request, and it warns not to invent prepaid top-ups. In practice, pause the wave, shorten durations, drop to a lower resolution, or pick a cheaper model for low-value clips. Keep the same Idempotency-Key per prompt so the clips you already paid for are not duplicated when you resume.

Keep a ledger of your own

Write the job id, model and usage.cost for every completed job into a table, and reconcile it with GET /v1/usage, which lists reservations, captures and refunds. A re-render project is exactly when a silent double-submit is expensive, and an idempotent key plus a ledger makes it visible.