$2.00 balance: one 10-second Omni 1080p job, then a 402

With $2.00 in the wallet, one 10-second Omni 1080p job reserves $1.875. A second identical submit gets 402, not 429: balance and queue are separate.

5 min readSume
All posts

A $2.00 balance runs exactly one 10-second Gemini Omni Flash 1.1 job at 1080p, which reserves $1.875. The second identical submit returns 402 insufficient_credits, because only $0.125 remains. That is a balance error, not a queue error, and the fix is different from a 429.

Sume bills Omni at the fal list times 1.25. fal lists 1080p at $0.15 per output second (read 2026-10-07), so Sume charges $0.1875 per second.

Step by step

Each row shows what the wallet can still reserve after the previous submit.

Reserve walkthrough on a $2.00 wallet (read 2026-10-07)
StepRequestReserveAvailable afterResult
1Omni 10 s, 1080p$1.875$0.125Accepted
2Omni 10 s, 1080p$1.875$0.125402 insufficient_credits
3Omni 3 s, 360p$0.1125$0.0125Accepted
4Step 1 failsrefund $1.875$1.8875Hold released

402 and 429 mean different things

402 insufficient_credits is raised at submit when Sume cannot reserve the estimated cost, before provider work starts. 429 queue_full means the workspace has no accepted generation capacity left; the plan limits are Free 6, Pro 24, Startup 48 and Scale 120 accepted jobs. 429 rate_limited is request volume.

The remedies differ. For 402, add funds in the dashboard or submit something cheaper; step 3 shows a 3-second 360p draft still fits in the $0.125 that remains. For queue_full, wait for a job to finish or cancel queued ones, then retry with the same idempotency key.

  • 402: lower the cost or add balance.
  • queue_full: wait or cancel queued jobs.
  • rate_limited: back off and use retry-after.

Topping up and checking the balance

Sume shows the wallet in USD. GET /v1/balance returns the balance for the workspace of your API key, and GET /v1/usage returns the ledger entries: reservations, captures, refunds and top-ups. Both are read-only.

A top-up is a dashboard action. The dashboard can start a Stripe-backed manual credit top-up when billing is configured for the workspace, and the public API has no endpoint that creates one. A script that gets a 402 should therefore stop and report the shortfall, rather than retry.

In this example the shortfall for a second 1080p job is $1.75: the job needs $1.875 and $0.125 remains. Reading the balance before each submit in a loop lets the script compute that number itself and skip the call.

What to do in code

A client that submits video jobs should treat 402 as terminal for that request and 429 as retryable. The 402 body has the code insufficient_credits and a request id that Sume support can use. Do not retry the same request in a loop: nothing changes until the balance does.

A short sequence works well. Read GET /v1/balance, compute the reserve for the request you are about to send, and compare. If the reserve is higher, either lower the resolution or the duration, or stop and ask for a top-up.

Here the options are concrete. Dropping step 2 to 720p for 10 seconds reserves $1.25, which fits in the $0.125 left. Dropping it to 1080p for 4 seconds reserves $0.75, which also fits. Both are lawful Omni requests, since the model accepts 3 to 10 seconds.

Failed jobs return the hold

If step 1 fails, Sume refunds the reserve and the available balance goes back up by $1.875. A success captures the reserve. The ledger records the same three states, reserved, captured and refunded, so you can reconcile the figure afterwards. See the minimum balance for one job for the single-job floor.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume