Akool concurrent video generations: 2, 6, 8, 20, vs Sume's queue

Akool's pricing page lists concurrent generations of 2 video and 4 image on Starter, 6 and 8 on Pro, 8 and 8 on Pro Max and 20 and 24 on Business. Sume treats concurrency as a dispatch limit rather than a submit limit: extra valid jobs are accepted as queued, and a 429 queue_full comes back only when concurrency and queue capacity are both full.

The Akool numbers

As the page words it, per seat on yearly billing.

How Sume behaves instead

The generation admission guide says paid generation is queue-first: a job starts at once or waits in queued until a workspace slot frees up. Workers then move queued jobs to processing under the workspace concurrency guard. The errors guide adds that full concurrency alone is not an error.

So a batch of 30 avatar submits does not fail on the eleventh. It queues. The cost is time, not an error you must handle, as long as queue capacity remains.

What to build

For a batch, submit with an Idempotency-Key per job, so a retry after a timeout cannot bill twice, and poll or use a webhook. Handle 429 rate_limited with backoff and the retry-after header when present. Handle 429 queue_full by pausing submissions until a queued or processing job finishes.

I have not read published queue-depth numbers by plan, so measure your own batch: submit ten 4-second clips on standard, which is $7.36 in total, and time them from queued to complete. That tells you the real throughput you can plan around.

Budget and queues together

Queued jobs still reserve credit when they are accepted, per the errors guide's description of 402 insufficient_credits. A large batch needs the balance to cover it up front, so top up before you submit, not while the queue drains.

If a job fails, read its status and error before you resubmit with the same Idempotency-Key. A key reused with a changed body returns a conflict rather than a second bill.