Kling AI v2.6¶
Overview¶
Kling AI v2.6 extends the Kling line with explicit audio toggles metadata, keeping the familiar short-form video workflow while widening the request surface slightly. Kling’s official developer materials present the platform as a next-generation creative API for image and video generation with support for models, callbacks, polling, and motion-oriented controls. For portal readers, the useful mental model is that Kling billing in this codebase is parameter-driven: duration, mode, input type, and model tier all matter.
API base URL¶
Example payload¶
{
"model_name": "kling-v2-6",
"prompt": "A neon-lit drive through a rainy cyberpunk city",
"aspect_ratio": "16:9",
"duration": 5,
"cfg_scale": 0.5,
"mode": "pro",
"generateAudio": true
}
Our Current Pricing¶
Kling video billing is parameter-based. The activity does not wait for a provider usage record; instead it computes cost from duration, mode, resolution, input type, and model multiplier.
Base price per second:
Resolution multipliers:
Input multipliers:
Model multipliers:
kling-v2-5-turbo -> 1.0
kling-v1-6 -> treated operationally like the standard Kling family unless you override it in your own rate card
kling-v2-6 -> 1.0
kling-v3 -> 1.3
kling-video-o1 -> 1.8
unknown -> 1.0
Implemented formula:
raw_cost =
ceil(duration_seconds) *
base_price_per_second(mode) *
resolution_multiplier(resolution) *
input_multiplier(input_type) *
model_multiplier(model)
final_cost_usd = clamp(round(raw_cost, 2), 0.01, 10.00)
A small but important implementation detail is that the current activity path passes 720p into the cost function, so even if the external model can conceptually produce higher output, the repo’s current internal cost path charges as though the request is in the 720p tier unless that code is changed.
To calculate cost safely, derive input_type from the request envelope you persist. A payload with no references is text; one reference frame is usually image; multiple stills become multi-image; source-video driven jobs become video. Then compute the bill line from the normalized request rather than from the polling result. That gives you stable billing even when the provider returns only task status.