Video job concurrency and queueing on Sume: limits and queue_full

Sume admits paid generation jobs queue-first. A submit that is valid, can reserve balance, and fits the workspace's accepted-job capacity becomes a durable job, which starts right away or waits in queued until a concurrency slot opens. Concurrency limits how many jobs are processing, not how many you can submit, so a submit fails with 429 queue_full only when the queue is full too.

Admission rules below are from Sume's Generation admission docs; plan limits come from the plan catalog behind Pricing.

What is the difference between concurrency, queue capacity, and rate limits?

Sume separates four controls that are easy to confuse. Read and status endpoints can have rate limits too; treat those as polling backpressure, not generation concurrency.

How many generation jobs can each plan run at once?

Concurrency is how many generation jobs can run at the same time, and it is plan-only: prepaid top-ups do not raise it. Queue capacity defaults to max(3, concurrency_limit × 5). Accepted job capacity is concurrency_limit + queued_jobs_limit, the maximum number of paid generation jobs that can be processing or queued for the workspace at once. Plans are Free $0, Pro $40 / month, Startup $120 / month, Scale $400 / month.

Admin overrides, reported as limit_source: admin_override, can raise a workspace's effective concurrency_limit; Enterprise uses them for higher contract limits. The dashboard Concurrency tab, exposed as generation_limits.concurrency_limit, is the source of truth; prefer it over any static table.

What does queue-first admission look like?

Do not treat queued as failure. Store the job_id, poll status with exponential backoff, and fetch the result only when the job reports result_ready: true or status: completed.

A workspace with concurrency_limit: 1 can still submit several valid jobs at once. Sume can return all of them as queued while balance and queue capacity are available, and only one should move to processing at a time:

Job A: queued -> processing -> completed
Job B: queued -------------> processing -> completed
Job C: queued ---------------------------> processing -> completed

How do I read the generation_limits snapshot?

Generation submit responses include generation_limits when Sume can compute the workspace admission snapshot; its counts can change right after the response. The example is a Pro workspace with nothing running.

• concurrency_limit is the effective maximum of paid generation jobs that can be processing; plan_concurrency_limit is only the plan default.
• queued_jobs_limit is how many more can wait in queued, and accepted_generation_jobs_limit is the sum of the two.
• queue_capacity_remaining is the remaining queued-job budget plus idle processing seats, before queue_full.
• wave_size_hint is max(1, floor(queue_capacity_remaining * 0.75)): a submission-wave hint only, never a concurrency limit or a width for in-flight work.

{
  "generation_limits": {
    "plan_id": "pro",
    "limit_source": "plan",
    "plan_concurrency_limit": 4,
    "concurrency_limit": 4,
    "queued_jobs_limit": 20,
    "accepted_generation_jobs_limit": 24,
    "active_generation_jobs": 0,
    "queued_generation_jobs": 0,
    "queue_capacity_remaining": 24,
    "wave_size_hint": 18
  }
}

How should I size a batch of submissions?

Use max(0, concurrency_limit - active_generation_jobs - queued_generation_jobs), capped by queue_capacity_remaining, as the budget for new in-flight work. Count each job you submit against that budget until the next live snapshot, and at zero headroom, wait before you submit more.

In the docs' example, a workspace set to concurrency_limit: 100 and queued_jobs_limit: 500 reads wave_size_hint: 450 when idle, yet allows at most 100 new in-flight jobs. With 30 processing and 10 queued, its new in-flight budget is 60.

What should I do after a 429 queue_full?

queue_full means the workspace has used all of its accepted generation capacity. The error details can include a generation_limits snapshot, and Sume releases or refunds the reservation for the failed admission when applicable. Then:

• Stop adding generation work for that workspace.
• Poll existing jobs until at least one reaches a terminal state.
• Cancel queued jobs you no longer need. Cancel succeeds only before generation starts; after that it returns 409 job_generation_already_started.
• Retry with the same idempotency key after capacity opens, and use retry-after when present.

What are the current boundaries of queueing?

The admission docs list these boundaries:

• There is no precise per-job queue position or ETA, only queue counts and remaining accepted capacity.
• sync and subscribe modes can wait up to 30 seconds. After that, keep polling the job id.
• Queue expiration and a client-supplied fail-fast queue length are not currently public API options.