What a $120 run cap covers: avatar clips, captions, images

A $120 generation cap on a Format run covers 43 standard-quality 15-second Avatar 1.0 clips, 32 at plus quality or 14 at max, with a little room left over each time. It would cover 600 standalone caption jobs or 436 Ideogram 4.5 images at high quality. Those counts assume the whole cap goes to one product.

The Formats docs call out $120 because production integrations run with caps around that figure. Here is what it means in units of output.

How does the cap work?

Every Format carries a generation spend cap, and a run can never spend past its own effective cap. A Format that never set one reports the platform default of $400. On the request, generation_spend_cap_usd names this run's own ceiling: a number up to 500 is that number, above the Format's cap is honored rather than clamped, null is the platform maximum of $500, and 0 or anything above 500 returns 400. See Spend caps for the rules.

What counts against the cap is metered generation at the rates on the pricing page, and it counts reserved as well as captured amounts. It excludes the agent's own LLM turn, so the receipt's usage.billable_amount_usd_micros is not the run's total cost.

What does $120 hold at each tier?

The first table converts $120 into whole 15-second Avatar 1.0 clips without a product image, using the per-second rates in the clone's provider-pricing package. The reserve is the full estimate, so counts are rounded down, not up.

What does a realistic run look like?

A run rarely buys one thing. Suppose a run makes 20 plus-quality 15-second clips, captions each of them, and assembles one five-minute Timeline render. That is 20 x $3.675 = $73.50, plus 20 x $0.20 = $4.00, plus five ceil-minutes at $0.10 = $0.50, for $78.00.

That uses 65 percent of the $120 cap and leaves $42.00. The headroom matters: if the run retries a scene or an agent adds clips, the cap stops the run when it would pass $120. A run that ends this way is marked failed, and usage shows how close it got.

Is the cap what I will be charged?

No. The cap is the control you own, and the cost is usage.debited_usd_micros, what the wallet actually deducted for the run and its thread. Held amounts are still open and not spend, and refunded amounts are not spend either. Generation that finished before a cancel or a failure is billed, and a failure in a later step does not refund it.

At create the wallet gate also applies: if the workspace cannot fund the run, you get 402 insufficient_credits and nothing ran. Set the cap to what you can afford to lose on the worst case, and read the receipt after each run. Rates change, so confirm them on the API pricing page before you size the cap.