FL PixVerse API

This one animates a still image into a short clip by calling PixVerse's cloud, not by running a video model on your own card. That's the whole pitch and it's worth being clear-eyed about it: no local GPU work, no 14GB checkpoint to download, but you're paying PixVerse per generation and you need one of their API keys. If you were hoping to run video locally, this isn't that - reach for a Wan or LTX workflow instead. If you just want a clip and don't want to babysit VRAM, it's a clean shortcut.

What it actually does

You feed it a prompt and (usually) a starting image, it ships that off to PixVerse's image-to-video endpoint, waits, downloads the resulting MP4, and pulls the frames back into ComfyUI as a normal IMAGE tensor. From there you treat it like any other batch of frames - pipe it into a video-combine node, upscale it, whatever. It slots into the graph like a local node; it just happens to do its heavy lifting somewhere else.

There's a second mode: flip use_transition on and give it first_frame_img and last_frame_img, and it generates a clip that morphs from one to the other. That's the more interesting use, honestly - start/end keyframe transitions are fiddly to do well locally.

The inputs that matter

• api_key - required, and it's your PixVerse key. No key, no video.
• image - your start frame for standard image-to-video. (For transition mode, use first_frame_img / last_frame_img instead.)
• prompt / negative_prompt - steer the motion and content.
• quality - 360p, 540p (default), 720p, or 1080p. Higher costs more and takes longer.
• duration - 5 to 8 seconds.
• batch_size - 1 to 5. This fires that many parallel API calls with different seeds, so it's your "give me options" knob. It also multiplies your spend by that many - five clips is five clips' worth of credits.

motion_mode picks normal vs fast motion, nth_frame lets you subsample the returned frames (handy if you only want every 2nd or 3rd frame), and seed is there for reproducibility.

Outputs are frames_1 through frames_5 (one IMAGE batch per clip in your batch - if batch_size is 1, only frames_1 is populated), plus video_urls, a status_msg for when something goes wrong, and credit_balance so you can watch your PixVerse balance tick down. Wire frames_1 into your video encoder.

Installing it

It ships in the Fill-Nodes pack. Easiest path is ComfyUI Manager: open the Manager, search ComfyUI_Fill-Nodes, install, restart. Manual works too:

cd ComfyUI/custom_nodes
git clone https://github.com/filliptm/ComfyUI_Fill-Nodes

then restart ComfyUI. Fill-Nodes is a big pack that pulls in a lot of Python dependencies on first load, so give the console a minute and watch for install errors. Heads up on one bit of theater: the pack prints a giant "Machine Delusions" banner to your terminal on startup. It looks alarming, it is not - it's just the author's splash. Somebody once posted a worried "should we be worried?" thread over it; the scary text was cosmetic plus a note about the pack's Google Drive upload nodes.

Where people get tripped up

• It costs money at PixVerse. This is the big one. The node is free; the generations aren't. batch_size: 5 at 1080p is a real bill.
• Key errors read as node failures. If nothing comes back, check status_msg first - a bad or out-of-credit key surfaces there, not as a Python traceback.
• It's a network call, so it's slow and can time out. PixVerse is doing the generation on their side; a busy queue means a long wait. That's not your machine hanging.
• Nothing runs locally, so none of the usual "wrong VRAM / missing model" advice applies. If it breaks, it's the key, the credits, or PixVerse's API - in that order.