Converting credit and subscription video pricing into cost per second

Updated 2026-10-02

Video generation is sold in three shapes: a per-second rate on a pay-as-you-go API, a bundle of credits where each generation burns a variable number of credits, and a monthly subscription that includes an allowance. The pricing pages for each look cheap in isolation. They cannot be compared until you convert all three into one unit, and the right unit is cost per delivered second, not cost per credit and not cost per month.

The target metric

Define one number you will compute for every option:

cost_per_delivered_second = total_spend / seconds_you_actually_keep

Everything below is about getting an honest numerator and an honest denominator for each pricing shape. A per-second API gives you the numerator almost for free. Credits and subscriptions require work.

Shape 1: per-second, pay as you go

A per-second API bills rate x requested_seconds per job, plus any platform fee. VideoRouter bills once at job creation from the requested duration, polling is free, and a job that fails upstream is not billed. The live table below shows current figures for the models this site tracks:

Per second, before VideoRouter's 2% platform fee. For tiered models each row compares the resolution tier with the widest host-to-host gap. Built 2026-10-02 from the live catalog.

For this shape, cost_per_delivered_second = rate x f x R x T, where f is one plus the platform fee, R is your retry multiplier (generations per accepted clip) and T is trim overhead (requested seconds divided by kept seconds). There is no unused balance to worry about beyond what you chose to top up.

Shape 2: credit bundles

Credit systems add an exchange rate and, usually, a second table: how many credits each action costs. To convert, you need three numbers from the provider's own documentation, not from a marketing page:

1. Price per credit: bundle price divided by credits in the bundle. If there are several bundle sizes, use the size you would really buy, because the largest bundle is rarely the one you start with.
2. Credits per generation: look up the exact model, resolution, duration and mode you will use. Credit tables often differ by resolution and by whether audio or an image input is included.
3. Seconds per generation: the duration that credit cost buys, including any fixed minimum.

price_per_credit      = bundle_price / bundle_credits
cost_per_generation   = credits_per_generation x price_per_credit
cost_per_second       = cost_per_generation / seconds_per_generation

Then apply the same R and T factors as for a per-second API. Two adjustments are specific to credits. If credits expire, divide by the fraction you expect to actually spend before expiry: a bundle you only use half of costs double per credit. If failed generations still burn credits, R must count them; if they are refunded, it should not. Read the refund wording rather than assuming either.

Shape 3: subscriptions with an allowance

A subscription is a credit bundle with a recurring fee and a use-it-or-lose-it deadline. The conversion is the same, with two more questions: does the allowance roll over, and what happens when you exceed it (overage priced at a different credit rate, or a forced upgrade)? The effective rate depends on utilisation:

effective_cost_per_second = plan_fee / seconds_generated_this_month
                            (if you stay within the allowance)

This is the number that surprises people. A plan is cheap per second only in the months you consume most of it. In a slow month the same plan can cost far more per delivered second than a pay-as-you-go rate you never have to pre-commit to. If your demand is spiky, compute the effective rate for your lowest-volume month, not the average.

A symbolic worked example

Suppose a credit plan lists C credits for P in fees, and your target generation costs g credits and yields s seconds. Then:

cost_per_second_credit = (P / C) x g / s

pay-as-you-go           = rate x f
break-even condition    : (P / C) x g / s  <  rate x f

Rearranged, the plan only wins when (P / C) x g / s is lower than the per-second rate including the fee, after you multiply the plan's side by its own utilisation penalty 1 / u (where u is the fraction of the allowance you really consume). Plug your own numbers into the calculator for the per-second side, and keep the credit side in a spreadsheet using the formulas above. Both sides should use the same R and T unless the provider genuinely differs on retries.

Things that make the comparison unfair

• Different resolution or duration. A credit price quoted for a short low-resolution clip is not comparable to a per-second rate at a higher tier. Match both.
• Watermarks, queue priority and commercial-use terms. Cheaper plans often differ here. These do not appear in the unit price but can disqualify a plan for your use.
• API access. Some plans are for a web app only. If you need to call it from code, confirm programmatic access is included before you do the maths.
• Model availability. A credit price for one model does not tell you what the model you need costs. Convert the exact model.

A short checklist

1. Write down the exact model, resolution, duration and mode.
2. Compute price per credit from the bundle you would really buy.
3. Find credits per generation for that exact configuration.
4. Divide to get cost per generated second; apply 1/u if credits or plan fees can go unused.
5. Apply R and T from your own logs, the same for every option.
6. Compare against rate x f x R x T from the live cost page.

For the budget side of the same question, see how to estimate your video API budget and hidden costs in video APIs. To check the pay-as-you-go side with a real request, create a key and run a short job with a spend cap.

Frequently asked questions

Keep reading

• How AI Video API Pricing Works — Per-Second, Per-Tier, Per-Host
• Cheapest Video Generation API: How to Find It for Your Workload
• Video API Pricing by Resolution: 480p to 4K Per-Second Costs
• How to Estimate Your AI Video API Budget, Step by Step