Retry buffer for a 50-clip AI video batch: 95th-percentile spend

For a 50-clip batch where about 70% of takes are usable, plan for 71 takes on average and cover 81 takes to be 95% sure you finish. At $0.50 per five-second H3 Max clip at 768p, that is $35.71 expected and $40.50 for the 95th percentile, a buffer of about 13%.

The usual advice, add 20% for retries, is close to right for a batch of 20 and too generous for a batch of 100. The buffer you need shrinks as the batch grows, and it depends on your keeper rate far more than on the model.

What is the model behind these numbers?

Each take is an independent paid attempt that you either keep or reroll. To finish N keepers you pay for N / p takes on average, where p is the share of takes you keep. The spread is a negative binomial: the number of takes needed to collect N successes. The 95th percentile is the smallest number of takes T for which at least N keepers appear with probability 0.95.

Two Sume billing rules bound the model. A job that fails at the provider releases or refunds its reservation, so a technical failure does not count as a take. A job that completes captures its reserved amount whether or not you like the clip, so every rejected-but-finished take is a real cost. Both come from the Generation admission page; this post only counts the second kind.

How big is the buffer for 50 clips by keeper rate?

The price used is the catalog estimate for Sume Auto, which resolves to MiniMax H3 Max at 768p and 5 seconds: $0.50 per clip on the Sume API pricing page. Swap in your own per-clip price and the dollar columns scale linearly; the take counts do not change.

Does the buffer shrink for bigger batches?

Yes. Holding the keeper rate at 70%, the relative gap between the average and the 95th percentile narrows as N grows, because independent rerolls average out.

How do you set the number in practice?

Measure your keeper rate on a small pilot before you size the wallet, because it moves the answer more than anything else. Ten takes is a weak estimate; if you have fewer than 30 takes of history, use the row one step below your measured rate.

Then fund the 95th-percentile figure, not the expected one, and round up to a clean top-up. Wallet top-ups are a manual dashboard action per the Billing and credits docs, so a batch that runs dry halfway stalls until a person tops up.

• Pilot 10 to 20 takes at the real prompt and model; count the share you would publish.
• Look up your keeper rate in the table and take the 95th-percentile spend.
• Add the largest single reservation you will have in flight at once, since reserved amounts are held before they are captured.
• Stop rerolling a shot after three takes and rewrite the prompt; a prompt change beats a fourth reroll.

What the table does not cover

The model assumes every take costs the same and each keeper decision is independent. A prompt that fails systematically breaks the independence: your keeper rate for that shot is near zero and no buffer saves you. Track spend with the run-scoped totals described on the Usage page instead of summing ledger rows yourself.