Rate limits and concurrency
The request rate per key and the number of jobs per workspace.
Two separate limits apply.
Request rate, per key
Each key has a request budget per window. Every response tells you where you stand:
Over the budget, the API answers 429 rate_limited with retry-after. Reads (status, result, list) have a larger budget than writes. If you poll many jobs, follow next_poll_after_seconds and spread the calls; one poll per job every few seconds stays far inside the limit.
Jobs in flight, per workspace
A workspace may have a set number of generation jobs queued or running at once. Images and videos share the one cap. On open.sume.com it follows the funds you added in the past 28 days:
| Funds added in 28 days | Jobs in flight |
|---|---|
| $0 | 2 |
| $25 or more | 10 |
| $100 or more | 20 |
| $1,000 or more | 40 |
Your first API key starts you at 4; once your funds reach a higher step, that step applies. Above 40, contact sales. Billing shows your current limit and what unlocks the next step.
The submit response reports where you stand in generation_limits:
| Field | Meaning |
|---|---|
concurrency_limit | Jobs that may run at the same time |
queued_jobs_limit | Jobs that may wait behind them |
accepted_generation_jobs_limit | The two together: the cap on jobs in flight |
accepted_generation_jobs | Jobs in flight now |
queue_capacity_remaining | How many more you can submit now |
A submit past the cap is refused, not queued, and is not charged: it gets 400 concurrency_limit_reached with the cap in the message, for example "Maximum number of concurrent requests (4) has been reached".
Wait for a job to reach a terminal state, then submit the next. A worker pool sized to concurrency_limit keeps you under the cap.
Overload
Under a sudden burst the API may answer 503 database_busy with retry-after. It is short; retry after the delay.
Higher limits
On open.sume.com the cap rises as you add funds, up to 40. For more, contact sales before a planned traffic increase.