Pricing basics · 7 minute read
How AI video API costs are calculated
A useful cost estimate starts with the exact model endpoint and its native billing unit. “Cost per video” alone can hide duration minimums, resolution tiers, audio options, credit conversions, and host-specific pricing.
First identify what is being priced
A video model is the generation system; an API host is the service you send your request to. A model available through two hosts can have different pricing, limits, supported modes, and request formats. Treat each model-and-host combination as its own option. Before estimating, confirm the endpoint supports the requested text-to-video, image-to-video, or video-to-video mode and the desired output settings.
Translate the native billing unit into a comparable estimate
Providers meter usage in different ways. RenderCents keeps the native unit visible and converts supported rates to estimated USD so configurations can be compared on a common basis:
- Per second: rate per billed second × duration × number of generations.
- Per credit: credits per generation × the listed value per credit. Some endpoints also have a minimum credit charge.
- Per generation: fixed price per request × number of requests; duration may still be limited even if it does not change the listed rate.
- Per frame: rate per frame × estimated output frames. The calculator currently uses 24 frames per second for this conversion, so check whether that matches the provider’s billing definition.
- Per pixel: price per megapixel-frame × output pixels × estimated frames. The selected resolution determines the pixel count.
- Token-based: token rate × estimated tokens. This conversion needs a documented token rate or token-per-second assumption.
These are calculation patterns, not a claim that every endpoint uses every unit. The calculator only estimates combinations with a rate and compatible configuration data. If a combination is marked unavailable or unverified, it does not substitute a nearby model’s price.
How scene-based project estimates work
For project runtime, the calculator estimates scene count by rounding the finished duration up to the next whole scene: ceil(final runtime ÷ scene length). It prices each estimated scene at the selected scene duration, multiplies by attempts per scene, then applies the chosen buffer percentage. For example, a 61-second video divided into 5-second scenes needs 13 estimated scenes because the partial final scene still requires a generation request.
A buffer is a planning allowance, not a prediction that every attempt will fail. Use attempts to model deliberate alternate generations; use the buffer for additional uncertainty. Avoid counting the same retries in both inputs.
Why an estimate may differ from an invoice
Provider billing may round duration, enforce minimum charges, charge differently for failed or cancelled requests, or change prices over time. Plans, taxes, discounts, storage, upscaling, and post-processing may also affect the final amount. Currency conversion is for comparison and changes with exchange rates. RenderCents estimates only the selected generation configuration and does not include unrelated service charges unless stated.
Use the source and verification date
Open the linked pricing source beside an estimate and check endpoint name, currency, usage unit, resolution, audio behavior, minimums, and duration limits. The verification date tells you when the listing was last checked; it is not a guarantee the source is unchanged today. Recheck the provider’s current documentation before committing a budget or generating at scale.
In short: choose the actual API host, match all generation options, keep the native unit visible, and treat unavailable rates as unknown rather than free.