Bulk run concurrency 3 with 8 items: what the 202 receipt shows
With concurrency 3 and 8 items, the Sume 202 shows three running and five queued. Item 3 starts when item 0 finishes. Here is how the window and counts behave.

With concurrency: 3 and 8 items, the 202 receipt shows three items running and five queued, and counts.total is 8. When item 0 completes, item 3 starts at once, so the window stays at three until fewer than three items remain. This is a server-side queue, not client fan-out.
What the receipt fields mean
Create fills the window already. counts has total, queued, running, completed, failed and canceled, and items holds one row per item in submitted order with index, status, run_id and error. A queued item has run_id: null.
| Field | Value |
|---|---|
| status | running |
| counts.total | 8 |
| counts.running | 3 |
| counts.queued | 5 |
| items[0..2].run_id | arun_ ids |
| items[3..7].run_id | null |
What can make the window smaller than you asked
completed, failed and canceled children are terminal and free a slot. Children still pass ordinary Format-run admission: wallet, workspace generation concurrency and spend caps. If a child fails to start, that item is failed and the window refills from the queued items.
- Concurrency is capped at 16, and your workspace's generation concurrency can hold fewer runs in flight.
- A child that the API claimed but has no
run_idyet still counts asrunning. - The docs say the window never goes above
concurrency, even if a poll fires more than once.
Polling the same queue
Poll GET /v1/format-run-queues/{id} and watch counts. In a healthy run, running stays at three while queued falls by one each time an item reaches a terminal state, and completed plus failed plus canceled rises to eight.
When all eight are terminal the queue status is completed and finished_at is set. Then read counts.failed, and fetch each child's receipt from its run_id for the media.
Poll the queue status URL rather than guessing from the create response. The counts and per-item statuses there are what tell you how far the batch has drained, and an item's run_id lets you cancel or read a single child.
Treat the concurrency setting as a pacing choice, not a speed guarantee. Test it on a small queue first, then raise it when you are satisfied with how your own downstream steps cope.
Tradeoff
A higher concurrency finishes sooner but spends faster and presses on your receiver and wallet. For a first batch, pick a small window, watch counts, and raise it once a pilot of three rows behaves.
Sources
Related posts
More in Formats
- Bulk run has no empty item: skip sheet rows without a finished script
A Sume bulk item must name at least one of instruction, input, previous_run_id or attachments. Filter unfinished sheet rows on your side before you send.
- One dead image URL fails the whole 100-item Sume bulk create
Sume fetches every attachment at create time, so one broken image URL in a bulk body fails the create before any queue exists. Check URLs first.
- Commit several Sume Format files in one PUT: a change set
PUT a files list to a Sume Format's contents URL and it is one commit with one version bump. Files you do not name stay as they are. Existing paths need a sha.
- Create a Sume Format over the API: auto_init and the first package sha
POST /v1/formats with auto_init (default true) commits a minimal SKILL.md and returns package_sha, contents_url and vanity_invoke_url. Keep all three.
Written by Sume