Four providers share one asynchronous task interface
Video Generator Client wraps Seedance, Kling, MiniMax/Hailuo, and Wan behind VideoClient. A caller submits a prompt, gets a task reference, checks status, waits with an update callback, cancels where supported, or downloads the finished file. That shape is useful for experiments because provider-specific authentication and request plumbing live in adapters instead of spreading through the application.
The package also exposes the same idea through a Typer CLI and a FastAPI web interface. The browser screen handles text-to-video and image-to-video inputs, negative prompts, duration, aspect ratio, resolution, status polling, preview, and MP4 download. HTML ships inside the Python package, so there is no Node or npm build. The web extra installs the server dependencies separately from the base client.
The README and code disagree on model IDs
The largest problem is visible before any API call. The README advertises newer Seedance 2.5, Kling 3.0, MiniMax H3, and Wan 3.0 options, among others. The checked-in catalog.py exposes a shorter and older mapping, including Seedance 2.0 Mini, Kling 2.1, MiniMax Hailuo-02, and Wan 2.2. The exact strings also differ between the table and code.
Open pull request 2 is titled "Fix duplicated Supported Models heading and align model table with catalog.py." The duplicated heading is still present in the README we fetched, so the pull request has not landed in the reviewed branch. Model APIs change independently of this package, as the author warns. Until documentation and catalog come from one source, verify the actual adapter payload against the provider before spending money on a batch.
What happened when we ran it
Our run at commit 5a1e90f used a fresh Debian container with Python 3.12, 3 CPUs, 8 GB of RAM, no secrets, and no elevated privileges. Installation finished in 41 seconds, pulled 51 packages, and occupied 70 MB. The project itself was only 33 files, about 1,471 lines of source, and 0.1 MB checked out.
The build completed in 7 seconds. Pytest then passed all 4 tests in 9 seconds, with 0 failures. Pip-audit found 0 known vulnerabilities in the installed environment. Those are clean results for the code path we measured. Four tests remain a small safety net for adapters that face four independently changing remote APIs, especially because our sandbox had no provider credentials and did not submit a paid generation job.
Our test method covered installation, packaging, and the repository's supplied tests. It did not compare video quality, measure provider latency, verify advertised resolutions, or confirm that every model ID still works. The repository has a tests directory, but 0 CI workflow files and no Dockerfile. A passing local suite therefore does not show that upstream runs the same checks on each change.
The web server has no application authentication
The default command binds the web server to 127.0.0.1, which is the appropriate starting point. The README also documents binding to 0.0.0.0. In web.py, the generation, task-list, task-status, and download routes have no authentication dependency or session check. Anyone who can reach that port can inspect in-memory task data and submit a generation using the configured provider credentials.
This matters because a generation endpoint can spend real API credit. Keep it on localhost, or put it behind an authenticated reverse proxy and network policy you operate. The task dictionary also lives in process memory and is cleared during shutdown. It is useful for the current browser session, but unsuitable as an audit log, durable queue, or multi-user job database. Downloads are written to a local output directory on demand.
The MCP server exposes one blocking generation tool
The optional mcp extra enables a stdio server named unified-video-gen. It advertises one tool, generate_video, with provider, prompt, model, image URL, duration, and aspect-ratio inputs. Each call creates a client, submits the job, waits until the provider finishes, and returns the result as JSON text. The main README lists the MCP directory but gives no setup example for connecting a host.
That single-tool design is easy to understand, though it drops the separate status and cancellation workflow available in Python. A long provider job keeps the MCP call open until completion or the configured 600-second polling timeout. Since the tool uses the same environment credentials as the client, an agent granted access can trigger paid work. Put budget controls at the provider account and restrict which MCP clients receive the tool.
A 0.7.0 package without releases is still prototype territory
The package metadata says version 0.7.0 and Python 3.9 or newer under the MIT license. GitHub showed 552 stars, 0 open issues, and 2 open pull requests on October 4, 2026. The repository was pushed on October 3, one day earlier. That recent activity is encouraging, but GitHub had no published release, and the project was created only on September 14.
Use a pinned commit and test one cheap request per configured provider before trusting a larger run. Record the submitted provider, model string, prompt, task ID, and final response outside the in-memory UI. The abstraction saves code when comparing providers, but the README mismatch proves that the model catalog can drift faster than the wrapper. For a production pipeline tied to one vendor, the supported provider API remains the safer dependency.