Spill Clip to Disk

RAM is the quiet killer in local video generation. Generate a handful of clips for a longer sequence and ComfyUI holds every one of them in system memory until the whole graph finishes - and since a sequencer runs last, every clip stays alive at once, waiting for a node that hasn't executed yet. The math from the pack's own source: a 121-frame 1536×896 clip costs roughly 1.86 GiB of decoded image tensors. Chain eight of them into a video and you've silently committed ~15 GB of RAM that no widget ever warned you about.

Spill Clip to Disk is the valve for that. It writes a generated clip to a temporary H.264 MP4 the instant it's ready and hands the next node a file-backed VIDEO reference instead of a wall of tensors. The in-memory clip data is released right after the write, so per-clip RAM stays roughly constant no matter how many clips feed the sequence. It's a one-in, one-out pass-through that lives under video/memory.

The whole node, in full

There is no settings panel to fiddle with. One input, one output:

• video (VIDEO) - the in-memory clip from a CreateVideo node.
• video (VIDEO) - the same clip, now backed by a temp MP4 on disk.

That's it. Under the hood it calls the clip's save_to() with H.264/MP4, deletes the in-memory object, then runs a garbage collect and an empty_cache so the freed memory doesn't just sit there. You wire it between every CreateVideo and the VideoSequencer:

CreateVideo ──► Spill Clip to Disk ──► segment0 ──┐
CreateVideo ──► Spill Clip to Disk ──► segment1 ──┴──► Video Sequencer

Why it matters more than it looks

Video generation is heavy on system RAM, not just VRAM - the KB's own guidance is that Wan 2.2 at higher quants wants 50–80 GB of total memory, and 32 GB is the floor for comfortable use. The classic long-form failure mode is ComfyUI crashing during the stitching/assembly step, which more VRAM does not fix. Spill is the same philosophy as that fix: offload decoded frames to disk before they accumulate, instead of hoping the process survives the peak.

Two honest caveats. First, it's one node per clip - you drop one between each generator and the sequencer, which adds a little graph clutter on big workflows. Second, writing H.264 to disk is a small re-encode per clip, so it trades a couple of seconds of time for every gigabyte of RAM you save. On short runs that's a waste; on a ten-clip continuation workflow it's the difference between a clean render and an out-of-memory crash at the last step.

Install and gotchas

It ships in the same pack as Video Sequencer, so the install is identical: clone into custom_nodes, restart. Needs ComfyUI 0.24+ and FFmpeg on PATH; no pip install, no models.

cd ComfyUI/custom_nodes
git clone https://github.com/Force01/ComfyUI-Sequencer.git
# restart ComfyUI

One thing to internalize before you rely on it: these files are temporary. They live in ComfyUI's temp directory and aren't permanent saved outputs - if you want named, durable clip exports, use Save Video instead. And if you do spill, remember the sequencer downstream still needs FFprobe for anything but a pure cut, so both binaries should be on PATH. Spill buys you headroom, not an excuse to skip checking whether your sequencer actually ran.