Bulk run worst-case spend: items x per-item cap on Sume

A bulk run submits up to 100 items against one Format, with concurrency between 1 and 16 and an optional idempotency_key. What it does not have is a queue-level spend cap: the Bulk runs docs put the cap on each item. That makes the maximum exposure a multiplication, not a setting.

The product ceiling on any one run is $500. A Format that never set a cap defaults to $400, and null means $500.

What can a bulk run authorize in the worst case?

The table multiplies items by the cap each carries. These are ceilings for planning, not predictions: a typical item finishes far below its cap, and the wallet is only charged for what each item generates. The docs describe production live-commerce integrations running with caps around $120.

Why does the wallet matter more than the cap?

Each paid job reserves its estimated price when it is accepted, and a wallet that cannot cover the reserve returns 402 insufficient_credits. So the real limit on a large run is the balance you hold. A $500 wallet and a hundred items with $400 caps is safe because the wallet, not the caps, binds first, and the shortfall shows as 402s on later items rather than overspend.

Plan queue capacity as well. Accepted capacity is 6 on Free, 24 on Pro, 48 on Startup and 120 on Scale and Enterprise, so a 100-item run needs Scale to be accepted in one go; on Pro, the items beyond 24 can get 429 queue_full.

• Size per-item caps from your highest-priced step.
• Hold a wallet balance of at least concurrency x typical reserve.
• Use idempotency_key so a retried submit does not run twice.

A sizing rule

Set the per-item cap to roughly twice your measured typical item cost, then multiply by items and check that the result is a number you would accept losing. If it is not, shrink the batch or the cap. Re-running in batches of 24 on Pro costs nothing extra and gives you a natural checkpoint to read usage between rounds.