Org workspace concurrency floor of 10: the queue and wave that follow

Sume docs say that org workspaces have a processing concurrency floor of 10. If the default queue formula applies to that effective limit, the queue holds 50 jobs, the accepted capacity is 60, and an empty workspace shows a wave_size_hint of 45. Treat that as arithmetic from the documented formulas, and confirm it against generation_limits in a real submit response.

Where the floor comes from

The Generation admission page lists the plan defaults: Free 1, Pro 4, Startup 8, Scale 20, Enterprise 20. It then adds that org workspaces have a floor of 10. A Startup org workspace, which would default to 8, is therefore described as running with at least 10. Enterprise has a default of 20, and higher contract limits use admin overrides.

Concurrency is plan-only. Prepaid top-ups do not raise it. Admin overrides can raise the effective concurrency_limit, and the response then reports limit_source: admin_override.

The arithmetic

The docs define the default queue capacity as max(3, concurrency_limit x 5). They define accepted capacity as concurrency plus queue, and the hint as max(1, floor(queue_capacity_remaining * 0.75)).

What to hard-code, and what not to

Do not hard-code 10, 50, or 60. The docs tell you to prefer the effective field over their static table, and an override changes every derived number. Read concurrency_limit, queued_jobs_limit, and queue_capacity_remaining from generation_limits on each submit response.

Do not use plan_concurrency_limit to size work when limit_source is admin_override. It is the plan default, not the effective cap. The override post shows the two fields side by side.

A quick way to see your own numbers

Submit one cheap, valid job and read the generation_limits object from the response. The counts are a snapshot and change as workers claim jobs and as other clients submit. If the object is missing, Sume could not compute the snapshot for that response, and the docs say to refresh before you pick a width.

Where the floor shows up

The floor matters when you size a worker pool. A pool sized to the Pro value of 4 would leave capacity unused on an org workspace, and a pool sized to 60 accepted jobs would be right. The figures above are derived from the documented formulas, not read from a live workspace, so confirm them with the generation_limits object on a real submit response.

Concurrency is a dispatch limit. A submit beyond it is not rejected; it waits in the queue. The rejection is 429 queue_full, and it happens only when concurrency plus queue is exhausted. That is why pacing by accepted capacity, not by concurrency, is the pattern that avoids both idle workers and 429s.