Akool concurrent videos 2/6/8/20 by plan vs Sume's queue-first limits

Akool's pricing page lists concurrent video limits of 2 on Starter, 6 on Pro, 8 on Pro Max and 20 on Business. Sume's generation concurrency is 1 on Free, 4 on Pro, 8 on Startup and 20 on Scale and Enterprise, and a submit beyond that limit is accepted as queued until the queue itself fills. The numbers look alike, but the two pages describe different things when a limit is reached.

Akool facts are from its pricing page, read 2026-10-03. Sume facts are from Generation admission. The Akool page does not say what happens to a video submitted over the limit, so this post compares only what both pages state. Akool's prices are per seat with an annual-billing equivalent shown, so confirm the monthly figure at checkout.

What do the plan tables say?

Akool lists concurrency alongside price and credits: Starter $12 a month with 2 concurrent videos and 4 concurrent images, Pro $30 with 6 and 8, Pro Max $59 with 8 and 8, and Business $249 with 20 and 24. Enterprise is custom. The page lists maximum video length too, from 15 minutes on Starter to 60 on Business.

Sume splits the question into four controls: generation concurrency, queue capacity, submit rate limits and balance. Only the first is a plan table of running jobs. Prepaid top-ups do not raise it, and an admin override can.

What happens at the limit on the Sume side?

On Sume, concurrency is a dispatch limit, not a submit limit. If a Free workspace with a concurrency of 1 submits six valid jobs, all six can come back queued because queue capacity is 5 and accepted capacity is 6. Workers then move them to processing one at a time. Only when accepted capacity is full does a submit fail, with 429 queue_full.

That changes how you write a batch loop. Treat queued as normal, store each job_id, and poll status with backoff. A 429 queue_full means wait for jobs to finish or cancel queued ones, then retry with the same idempotency key. A 402 insufficient_credits is a separate failure that happens before any provider work starts.

• Read generation_limits on the submit response instead of hard-coding the table.
• Queue capacity defaults to the larger of 3 and five times the concurrency limit.
• A batch of 20 avatar videos on a Pro workspace fits in the 24 accepted slots.

Which number should drive your plan choice?

If you render a few long videos, Akool's maximum-length column matters more than concurrency. If you render many short avatar clips, such as a batch of UGC variants, the useful question is how fast a batch drains and whether the whole batch is accepted at submit. On Sume the answer is plan concurrency for drain speed and accepted capacity for the batch size, and both are on the dashboard Concurrency tab, which the docs call the source of truth.