Watching for Kling 4.0 API availability, and what to test on day one

Updated 2026-10-02

Kling 4.0 was announced on 2026-09-28, with reporting pointing to limited testing and a wider release expected in October 2026. As of this page it is not available on any host in the VideoRouter catalog. Rather than refreshing news pages, you can monitor the one signal that actually matters to an API user: does a callable model id appear in a model list? This guide covers which signals are trustworthy, a script that polls for you, and a plan for the first day it works.

Which signals indicate real API availability

In rough order of reliability:

1. The model appears in the router's model list. GET /v1/videos/models returns the live list of valid model slugs for POST /videos, as bare ids with no pricing or capability data. If an id for Kling 4 shows up there, a request using it is accepted. It is unbilled to call.
2. A host publishes a price. A listing with a placeholder or zero rate is not availability. We do not register a model without a confirmed rate we can bill against, so a model can exist on a host for a while before it reaches the router.
3. A host's own model catalog lists it. This is an earlier hint, but hosts sometimes publish pre-release entries whose schemas and pricing later change.
4. Announcements and press. Useful for timing, weak for availability. An app launch is not an API launch, and early access is not general release.

The signal that gates your work is the first one, because it is the one that reflects what you can actually call.

A small poller

This script checks the model list on an interval, looks for an id that looks like a Kling 4 model, and prints an alert when one appears. It does not assume a response shape: it serialises whatever JSON comes back and searches the ids, so it works whether the endpoint returns a plain list or a wrapper object. Verify the output of the endpoint with your own key before relying on it.

import json, re, sys, time, requests

URL = "https://videorouter.sh/api/v1/videos/models"
KEY = "llmr_sk_live_..."
# matches kling-4, kling-v4, kling-4.0, kling/v4... but not kling-v3.0-4k
PATTERN = re.compile(r"kling[-_./ ]*(?:video[-_ ]*)?v?4(?:\.0)?(?![0-9k])", re.I)

def check():
    r = requests.get(URL, headers={"Authorization": f"Bearer {KEY}"}, timeout=20)
    r.raise_for_status()
    text = json.dumps(r.json())
    return sorted(set(m.group(0) for m in PATTERN.finditer(text)))

def alert(found):
    # replace with Slack webhook, email, or pager of your choice
    print("KLING 4 CANDIDATE IDS:", found, file=sys.stderr)

while True:
    try:
        found = check()
        if found:
            alert(found)
            break
    except Exception as e:
        print("poll error:", e, file=sys.stderr)
    time.sleep(3600)  # hourly is plenty

A few notes on this. The regex is deliberately loose, since the real id format is unknown, so treat a match as "go and look", not as proof; open the model page and read the details before testing. It excludes ids like the existing 4K tier of Kling v3.0. Run it as a cron job or a scheduled task rather than a long-lived loop if you prefer. Polling this list does not cost anything, but be a good citizen and keep the interval reasonable.

Also watch the /pricing/ page of this site: it is rebuilt from the live catalog, so a Kling 4 row will appear there once a priced model exists.

Launch-day test plan

When an id appears, run a short, structured evaluation instead of a single demo prompt. Keep it cheap: a handful of short jobs.

1. Read the model page first. Note the exact id, hosts, accepted inputs, resolutions and duration range, and the per-second rate.
2. Smoke test. One short text-to-video request with your key. Confirm the job reaches completed and that the output URL downloads.
3. Duration boundaries. Request your minimum, a mid value, and the largest documented duration. Check that the returned clip length matches what you requested. This tests the reported 30-second claim for real.
4. Input modes. Test start-image generation, and each reference type you rely on. Remember a call takes either start/end images or references, so test them as separate jobs. If a keyframe field exists, test it with two keyframes before ten.
5. Baseline replay. Run the fixed prompt set you saved from Kling 3.0 on the new model at the same resolution and aspect ratio. Review blind.
6. Cost check. Compare the billed charge to the displayed rate on a real job. Billing is once at creation by requested duration; a failed upstream job is not billed.
7. Failure behaviour. Note failure rates and queue times. New models often launch with limited capacity, so keep Kling 3.0 as a failover target.
8. Pin versus unpinned. If several hosts serve it, compare them with the model/host suffix before choosing a default.

Only after those steps change the model id in your configuration. If you followed the approach in the design guide, that is a one-line edit, and you can roll back the same way.

What not to infer from silence

No match in the list means "not callable through VideoRouter today". It does not mean Kling 4.0 is not released elsewhere, and it does not mean it will not arrive. The reverse also holds: a model name on a host's marketing page is not a callable model. Keep the status labels from the comparison page in mind, reported versus confirmed, and update your own notes only when you have run a job.

To get an API key for the poller, sign up here, and see the quickstart for authentication.

Frequently asked questions

Keep reading

• How to Prepare Your Integration for the Kling 4.0 API
• Kling 3 vs Kling 4: What Is Reported vs What Is Confirmed
• Kling 4 Alternatives You Can Call Today (Long Clips, Refs)