Kling 4.0 launch-day checklist for an API integration
Kling 4.0 is due in October. A short checklist and a Python script that flags the day a new Kling id appears in the Sume video catalog.

Kling 4.0 has a full launch due in October 2026, so the useful work now is a check that tells you the day a new Kling id shows up in your API catalog, plus a short list of what to re-test. With Sume, the check is one request to GET /v1/videos/models and a comparison against the Kling ids you already know. The script below does that in under 15 lines.
The dates come from Kling's page, read on 2026-10-02: early access since 2026-09-28, full launch in October. The catalog behavior comes from the video generation docs.
How do you detect a new Kling id automatically?
The models endpoint returns each model with its supported resolutions, aspect ratios, durations and frame-image types, so the same call also tells you what the new row accepts. Run this on a schedule:
import os
import requests
known = {"kling-3"}
resp = requests.get(
"https://api.sume.com/v1/videos/models",
headers={"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"},
timeout=30,
)
resp.raise_for_status()
rows = {m["id"]: m for m in resp.json()["data"] if "kling" in m["id"]}
new = sorted(set(rows) - known)
print("new Kling ids:", new or "none")
for model_id in new:
m = rows[model_id]
print(model_id, m["supported_durations"][-1], m["supported_resolutions"], m["supported_aspect_ratios"])What should the checklist cover on the day?
Kling's page lists new limits, and each is a place your code can break:
| Kling states | Check in your code |
|---|---|
| Native 3 to 30 seconds | Do you validate duration against a hard-coded 15? |
| 21:9 alongside standard ratios | Does your ratio dropdown come from the catalog or a fixed list? |
| Up to 10 keyframes | Does your request builder assume two frames (first and last) only? |
| 8,000-token prompts | Do you truncate prompts to an older limit? |
| 4K output | Does your storage and delivery path accept 4K files? |
What do you do before the id appears?
Keep kling-3 as the working id and store the id in config. Collect five real prompts and their current outputs. If you pin a model for every shot, log the exact id per shot so a later comparison is honest. Do not guess the new id: the catalog response is the only name your request will accept.
Does a new id change your cost model?
Possibly. Sume bills the provider list price times 1.25 on every video model, but the list price for a new row is not known until it is added. Estimate nothing until the row and its price show up in the catalog, then re-run your cost sheet with the clip lengths you actually plan to order. A 30-second clip is twice the length of the longest kling-3 clip, so the per-clip total, not the per-second rate, is the number that will surprise a budget.
How often should the check run?
Once a day is enough through October. A scheduled job that prints "none" costs nothing, because the models endpoint is a read. When it prints an id, open the model's row, read its limits, and only then submit a test clip.
Sources
Related posts
More in Developers
- Kling motion control with avatar_id instead of image_url
Sume's Kling 3.0 Motion Control takes image_url or avatar_id/avatar_handle, never both. A ready avatar resolves server-side to its identity still.
- Kling motion control sync mode: a 30-second wait, then poll
Sume's sync and subscribe modes on Kling 3.0 Motion Control wait at most 30 seconds. A clip usually outlasts that, so poll status_url; do not resubmit.
- LangGraph 1.2 node timeout: the Sume video job keeps billing
LangGraph 1.2 adds run_timeout and idle_timeout per node. A timeout stops your node, not the Sume job it started: store the job id and re-poll.
- LangGraph DeltaChannel: keep Sume artifact URLs in state, not video
LangGraph 1.2 DeltaChannel stores only the per-step delta. Even so, keep Sume media out of state: store the artifact URL and job id and fetch bytes when needed.
Written by Sume