Refresh 1,200 SKU video ads before Black Friday: waves by plan
On an empty workspace, 1,200 jobs take 300 submission waves on Free, 67 on Pro and 14 on Scale, using Sume's wave_size_hint of 75% of accepted capacity.
A 1,200-SKU video refresh is a queue-management problem before it is a pricing one. Sume accepts only as many paid generation jobs as concurrency plus queue capacity, and returns 429 queue_full beyond that. On an idle workspace the suggested submission wave is 75% of accepted capacity: 4 on Free, 18 on Pro, 36 on Startup and 90 on Scale, so 1,200 SKUs need 300, 67, 34 and 14 waves.
Capacity by plan
The table uses the docs plan defaults as of 2026-10-08. The effective values come from generation_limits in the API, and the docs say to prefer that field over the static table.
| Plan | Processing | Queue | Accepted | wave_size_hint (empty) | Waves for 1,200 |
|---|---|---|---|---|---|
| Free | 1 | 5 | 6 | 4 | 300 |
| Pro | 4 | 20 | 24 | 18 | 67 |
| Startup | 8 | 40 | 48 | 36 | 34 |
| Scale | 20 | 100 | 120 | 90 | 14 |
| Enterprise | 20 | 100 | 120 | 90 | 14 |
How to use the hint
wave_size_hint is max(1, floor(queue_capacity_remaining x 0.75)). It is a submission hint, not a concurrency limit, and it must not be used to size in-flight work. The point is to leave a quarter of the queue free so that retries and a few urgent jobs still get in.
- Submit one wave, wait for jobs to leave the queue, read capacity again, submit the next.
- On 429 queue_full, wait or cancel queued jobs, then retry with the same Idempotency-Key.
- On 402 insufficient_credits, Sume could not reserve the estimate; submit cheaper requests or wait for balance.
Time, not just count
Waves are limited by how fast jobs finish, not by how fast you submit. If a clip takes a few minutes, Free at 1 concurrent job turns 1,200 clips into a multi-week job. Work back from your last publish date: divide 1,200 by the processing concurrency to get the minimum number of generation rounds, then multiply by your measured clip time. Measure a sample of ten first; the docs show no ETA per job.
A schedule you can defend
Pick a deadline, count the days and decide how many waves per day you can watch. Sixty-seven Pro waves is about a dozen a day over a working week. It is also fine to run the refresh in priority order: top 100 SKUs by revenue first, long tail last, so a stall costs you the tail rather than the bestsellers.
Keep the first wave small, for example 10 jobs, to confirm output quality and spend per clip before you commit the rest.
- Sort SKUs by revenue, and start with the top 100.
- Record every job id with its SKU so that a retry can target a single product.
- Re-read generation_limits before each wave rather than caching it.
Sources
Related posts
More in Developers
- Reserve, capture, refund: a 20-clip batch with 3 failures, 2 cancels
Worked example of how a Sume balance moves across a 20-job batch when 3 jobs fail and 2 are canceled while queued: what is held, captured and released.
- Retry a timed-out Omni Flash submit without paying twice (Node)
Node 18+ code that retries a Gemini Omni Flash 1.1 POST to Sume's /v1/videos on timeout or 429 with one Idempotency-Key, so a retry returns the same job.
- Retry a timed-out POST /v1/videos with one Idempotency-Key, pay once
A Python submit wrapper that retries network errors, 429 and 5xx with a stable Idempotency-Key, so a replay returns the original job instead of a second charge.
- Retry an avatar video submit without paying twice on Sume
Use one Idempotency-Key per paid avatar video submit and poll the job instead of resubmitting after a timeout. A Python example and the rules from Sume docs.
Written by Sume