Workflows instance limits vs Sume queue headroom: which binds?

The Sume limit is the one to size against: Cloudflare lists 50,000 concurrent Workflows instances, while Sume reports your own concurrency_limit and queue_capacity_remaining in the admission snapshot, and the docs' plan table runs from 1 to 20 concurrent jobs. Size fan-out from the Sume numbers.

Sume behavior is from the Generation admission docs; the Cloudflare limits are from an April 15, 2026 changelog entry, read 2026-09-30.

What are the Workflows limits?

The April 15, 2026 changelog table, for the Workers Paid plan, lists concurrent instances at 50,000 (previously 10,000), instance creation at 300 per second per account (previously 100), and 2 million queued instances per Workflow (previously 1 million). These figures are from that April entry and may have changed since.

How many jobs can I have in flight?

The docs give the budget as max(0, concurrency_limit - active_generation_jobs - queued_generation_jobs), capped by queue_capacity_remaining. Count each job you submit against it until the next snapshot. wave_size_hint is only a submission-wave hint and is never a concurrency limit.

What happens when I go over?

Full concurrency only leaves accepted jobs in queued. Running out of queue room is the separate 429 queue_full. For queue_full, wait for jobs to finish or cancel queued ones, then retry with the same idempotency key. For 429 rate_limited, back off using retry-after when present. Do not resubmit a job that is merely queued.

Where does the snapshot come from?

It is the generation_limits object that generation submit responses include when Sume can compute it, described on the generation admission page. The counts are a snapshot and can change right after the response, so refresh before each wave rather than caching for a run.