Metering
Quotas, rate limits, and cost safety
The product page defines the package unit, included quantity, key lifetime, request limits, rate, and concurrency. The server enforces those values from the key record; client-supplied values cannot increase them.
Reservation lifecycle
| Event | Quota behavior | What you see |
|---|---|---|
| Request validates and execution can start | Worst-case units and provider cost are reserved atomically. | The request proceeds. |
| Synchronous success | Actual charge settles and unused reservation is released. | usage.charged_units and remaining_units. |
| Asynchronous video accepted | Reservation remains attached to the job. | HTTP 202 with job_id. |
| Confirmed non-chargeable failure | Reservation is released. | A documented error; no quota charge. |
| Chargeable provider attempt | Actual provider-reported units/cost may settle even when output delivery fails. | Stable error; support can reconcile by request_id. |
| Stale execution lease | Cleanup releases it after the safety window. | Temporary conflict or unavailable response. |
Limit types
- Package quota: total purchased units remaining.
- Expiration: the key stops authenticating after the package lifetime even if units remain.
- Rate limit: maximum accepted calls per minute for the key, plus an abuse-protection network limit.
- Concurrency: number of operations allowed in flight simultaneously.
- Input/output limits: token, character, file, duration, MIME, dimensions, voice, language, and format constraints locked by the engine.
- Spend safety: upstream hourly, daily, per-variant, and failure-rate controls can pause execution without exposing provider costs.
Designing your application
Queue bursts in your backend, expose a user-visible pending state, do not launch more work than the concurrency limit, and treat 429 as backpressure. Never create extra keys or change idempotency identifiers to evade controls.