FLUX Video Edit [fast]

What you're actually reaching for

This is Kontext for footage. You hand it a clip plus a sentence and it gives you the same clip with the sentence applied - swap the jacket colour, relight the scene, turn the street to snow, restyle the whole thing while keeping the motion. It does not invent a new clip; if you want a clip that never existed, use a text-to-video node instead.

It runs on Runware's cloud, which sounds backwards until you remember that BFL's useful video work never leaves the API - the KB's Black Forest Labs panel tracks the pattern: the frontier stays proprietary, the open piece stays a promise. So there's no local FLUX Video Edit to choose over this one. The node is the door.

The inputs that matter

video is required and it is a STRING, not a video socket - the tooltip says "Video input (UUID or URL)". That's the one that trips everybody: you cannot wire a local MP4 into it. Paste a publicly reachable https URL, or a Runware media UUID you've already uploaded. The only uploader that ships in this pack is Runware Upload Image, and that one is for IMAGE inputs, so hosting the clip somewhere reachable is the practical route in.

The tooltip also owns the whole shape of the output: the result keeps the source's duration, aspect ratio and audio, at 24 fps, and anything above 720p is downscaled to 720p. There is no width, height or duration widget on this node, because there's nothing to set. A four-minute source is a four-minute job.

positivePrompt is the edit instruction. Write it as a change, not a re-description of the scene - "turn the delivery van red, keep the lighting and camera move" beats a paragraph about a van. You're steering an edit, not casting a spell.

Everything else is optional and mostly safe at defaults: numberResults (1–4 variations, each with its own seed), outputFormat (MP4, WEBM, MOV), outputQuality (20–99), settings.safetyTolerance (0–4, default 2 - lower is stricter, higher is more permissive) and the safety group with safety.checkContent and safety.mode (fast or full). The ttl toggle gates ttl_value, which only matters when you're keeping result URLs alive rather than downloading files.

Output: one video, natively typed, so it wires straight into Save Video.

Install

ComfyUI Manager → search Runware → install → restart. Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/Runware/ComfyUI-Runware
pip install -r ComfyUI-Runware/requirements.txt

That pulls runware-sdk>=1.6.5, pillow and soundfile. Nothing else - no checkpoints, no VAE, no 20GB download, and no GPU work on your machine at all. Then create a key at runware.ai/api-keys and set it one of three ways: ComfyUI Settings → Runware API key, the RUNWARE_API_KEY environment variable (wins over the Settings field), or runware auth login once in a terminal.

Watch the node's title bar after a run: this pack prints the cost of the call, and whether a content check flagged anything.

Where people get burned

The output arrives as a file path instead of a VIDEO link. The pack wraps the downloaded file as ComfyUI's native VIDEO type only when your ComfyUI exposes the comfy_api video class; on older builds you get the path string, and Save Video refuses it. The clip is fine - it's saved as runware_<id>.mp4 in your output folder. Update ComfyUI, restart, re-queue.

Errors are short on purpose. The pack swallows the SDK traceback and surfaces one actionable line, e.g. Runware: ... [parameter 'resolution', code ..., HTTP ...]. If you actually want the stack, set RUNWARE_DEBUG=1. And "No Runware API key" means exactly that - nothing is configured anywhere.

Moderation is not a setting you can defeat. settings.safetyTolerance loosens the dial; it doesn't remove it. This is the KB's point about API nodes at full strength - with no local weights there's nothing to fine-tune around, and BFL's own censorship posture is well documented. If the edit you want is one the model refuses, no node in this pack will get it for you.