VeniceWAN Text-to-Video

The name is half a lie, so let's clear it up first: VeniceWAN Text-to-Video does not run Wan on your machine. There's no checkpoint to download, no GGUF, no VRAM arithmetic. It's an HTTP client that talks to Venice.ai's Wan 3.0 video endpoint, and when the job finishes, an mp4 appears in ComfyUI/output/VeniceWAN/ as a native ComfyUI VIDEO.

That makes it the answer to a question with no local answer. Alibaba took the numbered Wan series behind an API after 2.2 - 2.5, 2.6 and 2.7 shipped cloud-only, no weights - so Wan 3.0 is a model you call, not one you own. (The open Wan 2.2 weights are still there, Apache 2.0 and permanent, if that's what you wanted.)

Who this is actually for

Two people. The one with no GPU who wants Wan-quality text-to-video in a Comfy graph anyway, and the one with a GPU who wants the hosted model's specific look and would rather pay per call than babysit a 14B pipeline. If neither is you, close the tab and go install Kijai's wrapper.

Two things you accept either way. Your prompt leaves your machine - that's the mechanism, not a bug - and it's metered, so every Queue is a small invoice. Venice's pitch has always been looser moderation under one subscription, which is why people route video through it at all.

How it works

On ComfyUI startup the pack calls Venice's /models?type=video, filters the response down to wan-3-0-* entries whose IDs end in -text-to-video, and reads each model's declared constraints. Those constraints are your controls: whatever durations, resolutions and aspect ratios the API reports for that model become the widgets on the node. That's why the input list looks thin compared to a local t2v setup - the options don't exist until Venice describes them.

When you hit Queue, the node POSTs to /video/queue, then polls /video/retrieve every five seconds (up to an hour), and streams the finished file down to disk before handing it to Comfy as a VideoFromFile. ## The inputs you actually touch

Everything lives inside the model combo. Pick a model and the node grows a prompt box plus that model's duration, resolution, aspect_ratio, and - when the model says audio is configurable - an audio toggle. Change the model and those reset, because they're the new model's options.

Then two fields people misread.

generation_id is not a seed. Per the author's tooltip it's a local cache nonce that never reaches Venice, and there's no seed anywhere in these nodes - so you can't reproduce a clip you liked, only reroll.

resume_job is the good one. Every job prints [VeniceWAN] Job resume token: <32 hex> to the console and saves it locally. If ComfyUI dies, or you cancel mid-poll, or a download flakes, paste that token into resume_job and queue again: the node fetches the existing job and ignores every generation input. No second charge for a clip you already paid for.

The single output is a VIDEO socket. Wire it to Save Video.

Install and the key

ComfyUI Manager → Install via Git URL → https://github.com/nakedfighter3d/ComfyUI-VeniceWAN, then use Settings → VeniceWAN, paste your key and hit Save & connect (that button also refreshes the model list). Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/nakedfighter3d/ComfyUI-VeniceWAN.git
python -m pip install -r ComfyUI-VeniceWAN/requirements.txt

The requirements are aiohttp, numpy and Pillow - you already have all three. There are no model files to fetch. Use ComfyUI's own Python, then restart.

VENICE_API_KEY in the server environment overrides the Settings field, and while it's set the UI refuses to write a key. The pack is careful with the credential, in a category with a real malware scar: the key lands in a locally-permissioned venice.local.json, never in workflow metadata, never at a download host, and errors get redacted.

Where people get burned

Your ComfyUI is too old. These nodes use the V3 backend authoring API (comfy_api.latest, comfy_entrypoint) and need genuine native VIDEO support. On an older build the pack silently doesn't register.

"Venice model discovery unavailable" on the node. Discovery is bounded to 15 seconds at startup and can fail on a flaky network or a bad key; the node's own description carries the reason. Restart after fixing it, or run:

cd ComfyUI/custom_nodes/ComfyUI-VeniceWAN
python diagnose.py

Queueing again after a lost response. A lost queue POST may still have been charged. The pack refuses to retry it for exactly that reason and tells you to check your Venice usage before submitting - believe it, and use resume_job instead.