video-generator-client: one async Python client for Seedance, Kling, MiniMax and Wan

What video-generator-client actually solves

Four providers, four authentication schemes, four polling conventions. Seedance uses an API key and a base URL, Kling wants an access key plus a secret key, MiniMax needs an API key and a group ID, and Wan goes through Alibaba DashScope. Writing that four times means four retry policies, four task-status loops and four ways to download an MP4. This package collapses them into one async client under src/video_gen/client.py, with one adapter per provider in src/video_gen/providers/ and a model registry in catalog.py.

The audience is narrow and specific. You are a Python developer who already has paid credentials for at least one of these providers and wants to script generation, batch it, or put a thin local UI in front of it. The README's example commands assume exactly that: you supply keys, the client calls the provider. There is no free tier, no bundled credits and no proxy service sitting in between. If you have no API key, this repository gives you nothing to run.

The architecture: one client, four adapters, one catalog

The layout is conventional and easy to audit. src/video_gen/ holds client.py for the shared async HTTP layer, cli.py for the Typer entry point, web.py for FastAPI, catalog.py for the provider and model registry, static/index.html for the UI, and providers/ plus utils/ for the adapters. Dependencies are httpx for async HTTP, pydantic for models, python-dotenv for credentials, typer and rich for the CLI, and PyJWT, which suggests Kling's authentication involves a signed token. The web extra adds fastapi and uvicorn.

The catalog is the interesting design decision. Model IDs are not hardcoded into each adapter; they live in a registry that the CLI can enumerate with video-gen models wan or video-gen providers. That is why the README can list fourteen model IDs across four providers in one table, from doubao-seedance-2.5 to wan2.5-t2v-preview. The trade-off is that the registry is also the thing most likely to rot. The README's Important section states that provider APIs and model IDs change independently of this SDK, and asks you to treat the provider adapters as integration code that may need updates. A registry makes that update a one-line edit, but it does not make the update happen for you.

Installing video-generator-client and running a first generation

There is no PyPI install documented. The README clones the repository and installs it in editable mode inside a virtual environment, which is the right shape for a tool you may need to patch when a provider changes.

git clone https://github.com/letorig/video-generator-client
cd video-generator-client
python -m venv .venv
source .venv/bin/activate
pip install -e ".[web]"

On Windows the activation line is .venv\Scripts\activate. The [web] extra pulls in FastAPI and uvicorn; if you only want the CLI, the base dependencies are enough.

Credentials go in a .env file copied from .env.example. The keys are provider-specific and you only fill in the ones you use: SEEDANCE_API_KEY, KLING_ACCESS_KEY and KLING_SECRET_KEY, MINIMAX_API_KEY and MINIMAX_GROUP_ID, DASHSCOPE_API_KEY. Two polling knobs sit at the bottom of the same file.

cp .env.example .env
# then edit .env with the credentials for the providers you use

POLL_INTERVAL defaults to 5 seconds and POLL_TIMEOUT to 600 seconds. Those two values decide how long a generation waits before the client gives up, so a slow 30-second clip on a busy provider can hit the timeout before the provider finishes.

The README's own first-run sequence is short. video-gen providers lists what the client knows about, video-gen models wan narrows that to one provider, and generate submits a job.

video-gen providers
video-gen models wan
video-gen generate wan --prompt "A snowy forest at dawn" --model 2.1 --duration 5
video-gen status wan TASK_ID

Note the model flag: it takes 2.1, not wan2.1-t2v. The catalog maps short names to the API model IDs in the table. Output is written to the output folder according to the README, and video-gen status re-checks a task by its ID, which matters because these are asynchronous jobs that outlive the process that submitted them.

The bundled web UI and its in-memory history

video-gen serve starts FastAPI, which serves the HTML from static/index.html and exposes JSON endpoints for provider discovery, generation, task polling and MP4 download. The README is explicit that there is no npm, Node.js or frontend build step: the interface ships inside the Python package. That removes an entire toolchain from the install, and it is the most practical thing about this project.

The server takes host and port flags, and a reload flag for development.

video-gen serve --host 127.0.0.1 --port 8000
video-gen serve --host 0.0.0.0 --port 9000 --reload

The UI covers provider and model selection, text-to-video and image-to-video input, negative prompt, duration, aspect ratio, resolution, live task status polling, video preview and MP4 download. One limitation is stated in the README itself: task history is in-memory for the current server session. Restart the server and the list is gone. The MP4s on disk survive; the task records do not. If you need a durable queue or a shared history across users, this web layer is not it, and binding to 0.0.0.0 exposes generation endpoints that spend your provider credits to anyone who can reach the port.

Where video-generator-client is the wrong tool

The project is integration glue, and the README says the glue may need repair. Provider APIs and model IDs change independently of this SDK. When Kling or MiniMax renames an endpoint, you are the one editing the adapter, because no release cadence is promised. The repository has no releases retrieved, so there is no version history to read for upgrade guidance, and the version in pyproject.toml is 0.7.0.

Second, nothing here generates video. Every call spends credits on a provider account, and the free searches around this package name are aimed at something it does not offer: there is no free tier, no unlimited mode and no local model. Third, the polling model is fixed at the client level. POLL_INTERVAL and POLL_TIMEOUT are global, so a fast 5-second clip and a 30-second one-take share the same 600-second ceiling unless you edit .env. Fourth, the web UI keeps history in memory only, and the CLI and web paths are separate surfaces over the same client rather than a single workflow. If you need job persistence, multi-user accounts or cost tracking, you are building those yourself.

How it compares to calling the vendor SDKs directly

The alternative is the official route: ByteDance's SDK for Seedance, Kuaishou's for Kling, MiniMax's own client, and DashScope's Python package for Wan. That approach gets first-class support for each provider's newest parameters on the day they ship, and it is the right choice if you only ever use one provider. The difference in approach is where the abstraction sits. Vendor SDKs abstract nothing across providers; video-generator-client abstracts the provider boundary itself, at the cost of a lag between a provider change and an adapter update.

A second alternative is a hosted generation platform that wraps several models behind one account and one bill. That removes the credential problem entirely, since you do not hold four sets of keys. It also removes your ability to patch the integration when a model ID moves, which is exactly the control this package gives you. The relevant question is not which is more capable but who maintains the mapping when doubao-seedance-2.5 becomes something else. Here, you do.

Maintenance cost, licence and what to verify

The last push to the repository was on 2026-09-14, three days before this writing, so the project is current rather than abandoned. That is a statement about activity, not about the stability of the provider APIs it wraps.

The MIT licence is permissive: it allows commercial use, modification and redistribution, and requires the licence and copyright notice to be preserved. The repository ships a LICENSE file. Nothing here restricts what you build on top of the client, but the licence covers this code only. Your use of Seedance, Kling, MiniMax and Wan remains governed by each provider's own terms, and those terms are not in this repository. That is a factual boundary, not legal advice.

The upgrade surface is small and identifiable: pyproject.toml pins floors rather than exact versions for httpx, pydantic, typer and the rest, so a fresh pip install -e ".[web]" can pull newer minor versions than the author tested. The dev extra adds pytest, pytest-asyncio and ruff, and the tests directory exists, so you can run the suite before trusting an upgrade. Verify three things first: that video-gen providers reports the providers your .env satisfies, that video-gen models for your chosen provider still lists the model ID you intend to call, and that your POLL_TIMEOUT is long enough for the duration you are requesting.

Editorial conclusion

Adopt it if you already hold API keys for Seedance, Kling, MiniMax or Wan and want one async client plus a local web UI instead of four vendor SDKs. Skip it if you expect a free generator, a hosted service, or a stable abstraction over model IDs: the README warns that provider APIs and model IDs change independently of this SDK, so treat the adapters as integration code you may have to patch. Before committing, clone the repository, run pip install -e ".[web]", run video-gen providers to see which credentials your .env actually satisfies, and check that the model ID you need still appears in video-gen models for that provider.

Frequently asked questions

Official sources

1. Issues
2. letorig/video-generator-client on GitHub
3. License: MIT
4. README