Turning Kling per-second pricing into per-minute budgets

Updated 2026-10-02

Kling is priced per second of generated video, but nobody ships "a second". You ship a 45-second explainer, a batch of 200 five-second product clips, or a monthly allowance per user. Turning a per-second rate into a budget you can defend takes four inputs beyond the rate itself: how many seconds you actually request, how many attempts it takes to get a usable clip, which tier each attempt runs on, and the platform fee. This article gives a method you can paste into a spreadsheet, and the live numbers come from the table below.

Live cost for standard clip lengths

The table shows the cost of 5-second, 10-second and 60-second clips at the cheapest host for each Kling model, generated from the current catalog. A 60-second row is the "per minute" number, but see the next section before using it as a budget, because it assumes every second you pay for ends up in the final cut.

Computed from each model's cheapest current host per resolution tier, before VideoRouter's 2% platform fee. Built 2026-10-02 from live data. Failed upstream jobs are not billed; re-generations are, so multiply by your retry rate.

Rates move. Treat this table as the source of truth and re-check it before quoting a client. The wider cost page has the same data in more detail, and the pricing page shows the cheapest and priciest host per model.

Step 1: separate billed seconds from delivered seconds

Billing happens once, when you create the job, based on the duration you requested. Polling is free and a job that fails upstream is not billed. That has two consequences. First, a requested 10-second clip costs ten seconds even if you trim it to six in the edit. Second, a clip you generate, dislike and discard is still billed, because the job completed.

So the cost of one minute of delivered footage is the per-minute rate multiplied by a waste factor greater than one. The factor has three parts:

• Retry multiplier: average completed generations per accepted clip. If you accept one of every three clips, the multiplier is three.
• Trim overhead: requested seconds divided by used seconds, for example requesting 8 seconds and keeping 6.
• Draft share: the portion of attempts spent on a cheaper tier (next section).

Step 2: model the tier mix

Kling v3.0 comes as three separate model ids, kling-v3.0-std, kling-v3.0-pro and kling-v3.0-4k. A common production pattern is to iterate on Std and only promote approved shots. That means the blended rate is a weighted average of the tier rates, weighted by how many billed seconds each tier consumes, not by how many clips you ship. Drafts dominate billed seconds, which is why the cheap tier's rate matters more than the premium tier's rate for most teams. See the cost-reduction guide for the draft-then-promote workflow.

Step 3: the formula

Define these quantities, all of which you can measure from your own logs:

• D: seconds of delivered footage in the project
• r: average attempts per accepted clip
• t: requested seconds divided by kept seconds
• p_draft, p_final: per-second rates from the live table for the tiers you use

def project_budget(D, r, t, p_draft, p_final):
    # D: delivered seconds; r: attempts per accepted clip; t: requested/kept seconds
    accepted_secs = D * t                     # requested seconds of the accepted takes
    rejected_secs = D * t * (r - 1)           # rejected attempts, run on the draft tier
    return rejected_secs * p_draft + accepted_secs * p_final

# Cost of one delivered minute: project_budget(60, r, t, p_draft, p_final)
# Read p_draft and p_final from the live table; do not hard-code them.

If you ship some Std output directly instead of promoting every approved clip, blend the final rate as s * p_draft + (1 - s) * p_final, where s is the share shipped from the draft tier, before calling the function. The point of writing it as code is that every term is something you can log: attempts per accepted clip, requested versus kept seconds, and which model id each job used.

The platform fee is 2% on image and video usage. If the rate you read from the live table is already the displayed all-in rate, do not add the fee a second time; confirm against the table's labelling on the cost page, then apply it once in your model if the rate you use excludes it.

Step 4: stress-test the three assumptions

Run the calculation at three multipliers (optimistic, expected, pessimistic) and quote the expected figure with the pessimistic one as a cap. Teams that quote only the optimistic case discover the gap on their first invoice.

Per-user and per-month budgets

If you resell generation inside a product, work backwards: pick the maximum seconds per user per month, apply the same multipliers, and set a spend cap on the API key that matches. The API supports a monthly cap per key, and a runaway retry loop is the most expensive bug a video feature can have. Add a client-side limit on retries as well, and never resubmit because a job is slow, since that creates a second billed job.

Check the host spread before you finalise

The same Kling checkpoint can be priced very differently by different hosts. Your budget should name which rate you are using: the cheapest host, the host you pin, or a blend. Unpinned requests route to the cheaper healthy host, and pinning with a suffix such as kling-v3.0-std/novita fixes it. If you pin, use the pinned host's rate in the formula, not the headline cheapest one. When a project quote depends on the rate, set up a key and run a small batch to measure your real retry multiplier before committing. The quickstart covers the first call.

Frequently asked questions

Keep reading

• How to Reduce Your Kling API Cost — Five Practical Levers
• Kling vs Seedance vs Veo Pricing: Compare Per-Second Fairly
• Why Kling API Prices Differ by Provider (and How to Choose)
• Kling v3 Std vs Pro vs 4K: How to Reason About the Price Gap