100 Format items: $40,000 default ceiling, $50,000 null, $500 at $5

A bulk Format queue of 100 items can authorize up to $40,000 of generation if you leave caps alone, $50,000 if every item sends generation_spend_cap_usd: null, and $500 if every item sends 5. Each item is an ordinary Format run, so each carries its own ceiling.

A cap is a ceiling, not a charge. A run bills what it uses. The sums below are the worst case a batch can reach before any wallet check, which is what a cost review should look at.

How an item gets its cap

A bulk item is a Format-run body, and the docs say each item can bind its own output_schema and generation_spend_cap_usd. The rules for a single run apply to every item.

What the queue does and does not limit

So the wallet is the real limit, and the caps are the limit you choose.

• Concurrency is 1 to 16 and the item count is 1 to 100; both are checked at create and return 400 invalid_request if out of range.
• Concurrency limits how many items run at once, not how much they can spend.
• Each child goes through ordinary Format-run admission, including the wallet and workspace generation concurrency, so an empty wallet still stops runs even with high caps.
• If a child fails to start, that item becomes failed and the queue create has already returned 202.

Pick a cap per item from the work

Set the cap to what one correct item should cost, plus a margin. If a typical item is a single image set priced at about $0.50, a cap of $5 gives ten times headroom and makes a runaway loop cost at most $5, not $400. The docs note that production live-commerce integrations run with caps of about $120, and that a single-scene retry on the same thread needs a fraction of that.

Because Sume accepts a number above the Format's own cap and does not clamp it, a per-item value of 450 on a Format whose cap is 120 is allowed. Do not copy a large number from one Format into a bulk body for another.

Check the receipts after the batch

Every receipt shows the effective cap as usage.generation_spend_cap_usd_micros and the actual spend as usage.billable_amount_usd_micros. After a batch, sum the second field across items and compare it with the sum of the first. A queue status of completed only means every item is terminal, so also read counts.failed.

Idempotency matters here too. Mint a fresh Idempotency-Key for each batch, because replaying a spent key returns 202 with the old queue and starts nothing new. If the create failed with a 402 or 503, Sume released the key, so retry with the same one after you fix the cause.