100 bulk items: 7 rounds at concurrency 16, 25 rounds at concurrency 4

A Format bulk queue holds up to 100 items and keeps 1 to 16 of them running at once. If every item takes the same time, 100 items need ceil(100 / 16) = 7 rounds at concurrency 16 and ceil(100 / 4) = 25 rounds at concurrency 4. Real items differ in length, so treat the round count as a ceiling on the plan, not a promise of time.

The limits

The queue is a server-side list of ordinary Format runs. Each item is one sandbox, one agent turn and one run receipt. Create returns 202, and the first concurrency items are already in flight on that receipt.

Rounds at each window

With a window of c, the server starts the next queued item the moment a slot frees. The window stays full until fewer than c items remain. For equal-length items that gives ceil(items / c) rounds. The table shows 100 items at four windows.

What the window does not do

A wider window does not change what each item costs. Spend is per run, and each run still passes normal admission: the wallet, workspace generation concurrency and spend caps. The docs say that workspace generation concurrency still applies to the children, so a window of 16 is bounded by your workspace limit. If items fail to start, read that limit first.

The last round is often partial. With 100 items at 16, the seventh round holds 100 - 6 x 16 = 4 items, so 12 slots sit idle. Choosing 10 gives 10 full rounds with no idle slots. Choosing 20 is not allowed. If items are equal in length, a window that divides the item count wastes nothing.

Pick the window from the risk, not the speed

A wide window finishes sooner but exposes more runs to a bad input at once. Concurrency 16 with a broken prompt starts 16 failing runs before you can look at the first. Concurrency 4 starts four. For a first batch, use 4, read the first receipts, and only then queue the remaining items with a wider window. You can split 100 items into a first queue of 8 and a second of 92, each with its own key.

The other limit is on your side. Each running child is a Format run, and the docs state that the workspace generation concurrency still applies. Child runs go through ordinary admission, and the docs say that a child which fails to start makes that item failed while the queue carries on. So a window above what your workspace admits can turn into failed items, not a slower queue. Check the limit before you promise a finish time.

Compute the plan before you submit

This script prints the rounds and the idle slots in the last round for any item count and window. It uses no network.

import math

def plan(items: int, concurrency: int) -> dict:
    if not 1 <= items <= 100:
        raise ValueError("items must be 1 to 100")
    if not 1 <= concurrency <= 16:
        raise ValueError("concurrency must be 1 to 16")
    rounds = math.ceil(items / concurrency)
    last = items - (rounds - 1) * concurrency
    return {"rounds": rounds, "last_round_items": last,
            "idle_in_last_round": concurrency - last}

for c in (1, 4, 8, 10, 16):
    print(c, plan(100, c))