Wallet needed to fill the Sume job queue, by plan

Filling Pro's 24 accepted job slots with 30-second Standard avatar clips reserves $132.48 up front; Scale's 120 slots reserve $662.40. Free has 6 slots.

5 min readSume
All posts

If you submit a full queue of 30-second Standard avatar clips, the balance needed to reserve them is $132.48 on Pro (24 accepted jobs), $264.96 on Startup (48) and $662.40 on Scale (120). Free accepts 6 jobs, which is $33.12. The queue can hold that many jobs at once, but a submit is refused with 402 insufficient_credits if its estimate cannot be reserved.

What the docs say about the queue

Sume accepts valid jobs as queued while queue capacity remains, and workers move them to processing under the workspace concurrency limit. Accepted job capacity is the concurrency limit plus the queue limit: 6 on Free, 24 on Pro, 48 on Startup and 120 on Scale in the static table. The docs also say to prefer the effective limit shown in the dashboard Concurrency tab, since overrides exist. Balance is checked at submit, before provider work starts.

Wallet to fill every accepted slot with a 30 s Standard avatar clip, computed (read 2026-10-03)
PlanProcessingQueueAccepted jobsReserve at $5.52 each
Free156$33.12
Pro42024$132.48
Startup84048$264.96
Scale20100120$662.40

Reading the table

The reserve column assumes every slot holds a $5.52 job and that each job's hold equals its estimate. Real holds can differ with product images, tier or length, so treat the column as an upper bound for this one job type.

In practice you rarely fill the queue. The number matters when a batch script submits everything at once: if the wallet covers 18 of 24 jobs, jobs 19 onward fail with 402 while the first 18 run. Better to check GET /v1/balance first and submit only what the wallet covers.

Sizing the wallet for a batch

Divide the balance by the per-job estimate and take the floor. A $100 balance covers 18 of these clips; a $50 balance covers 9. Then add the retry reserve on top. Because a job's hold is released on failure and its cost captured on success, the money in play shrinks as jobs finish, so a batch that fails the first submit round can often be resumed after earlier jobs complete.

Top-ups are manual in the dashboard, so size the wallet before a large batch instead of topping up between submits.

  • Read GET /v1/balance before a batch.
  • Submit only floor(balance / estimate) jobs.
  • Handle 402 and 429 queue_full separately; one is money, the other is capacity.
  • Use idempotency keys on every retry.

Other job types change the column

The same table for 5-second H3 Max clips at $0.50 each is $3.00 on Free, $12.00 on Pro, $24.00 on Startup and $60.00 on Scale. Cheap jobs fill a queue for very little money, so on those the limit you hit first is capacity, not balance: a 429 queue_full. On expensive jobs the reverse is true. Know which limit your workload reaches first.

What to do when the wallet falls short

If a 402 arrives mid-batch, stop submitting, record which items were accepted, and top up from the dashboard. Do not retry the failed item in a loop; the same estimate will fail again until the balance changes. When you resume, reuse the idempotency key for exact retries so a request that was in fact accepted is not duplicated, and use a new key only for a changed request. A 409 idempotency_conflict means a key was reused for a different payload.

Sources

Related posts

More in Pricing

All Pricing posts

Written by Sume