Video Cache

A 24fps clip is 24 image tensors per second of runtime. At 1024×1024, float32, that's roughly 150MB a second - fine for four seconds, a problem at a minute, and a hard crash when the sampler hands you the whole batch at once. Video Cache is the pack's answer: instead of accumulating frames in RAM until something saves them, it writes them to a folder on disk as they arrive and hands back a clip object that represents those frames. Nothing downstream has to hold them all at the same time.

Why you'd reach for it

The usual reason people leave ComfyUI for a video editor is that a long render dies at 90% with "out of memory" and no output file. The ecosystem has spent 2025–2026 attacking that from the model side - FramePack's compressed temporal attention windows, LTX-2's longer native clips - but the ceiling is still there, and it's on your side of the graph, not the model's.

Video Cache attacks it from the graph side, so it works with whatever you're generating. The pack's own H3 pipeline writes through a cache, but there's no H3 requirement here: anything that produces an IMAGE batch can dump it to disk.

How it works

A cache is a folder with three files: frames.bin (the pixels), audio.npy (an optional float32 soundtrack) and cache.wasframes, a small JSON manifest that says how many frames there are, at what rate, and at what depth. The frames go out as 8-bit pixel codes, or as half floats when the batch isn't in the 0–1 range and depth is left on auto. The video output is not a tensor bag - it's a reader pointed at that folder, so Save Video (Advanced) pulls one frame at a time off the disk and never asks for the whole clip.

The trick to long renders is append_to. Tape the video output back round to it through the pack's While Loop (or any loop node that carries a value), and each iteration's frames join the same cache: ten 40-frame chunks become one 400-frame clip, with no step ever holding more than 40.

The inputs that matter

• images - the frames to keep, appended after whatever's already in the cache.
• frame_rate - the rate a new cache is written at (24 film, 30 video). A cache you're appending to keeps its own.
• root - temp (wiped when ComfyUI restarts) or output (survives). Pick output if you intend to load the clip again later; temp is for caches you'll save in the same session.
• name - where below root the cache lands. It's numbered per run, so frame_cache/clip gives you frame_cache/clip_00001, then _00002, and so on. That numbering is convenient and also how your disk fills up.
• append_to - the loop-carried value. Leave it empty and you get a fresh cache every run.
• depth - auto, or 16 bit if you're heading for a 10-bit save.
• delete_after_save - see below, it changes when the node runs at all.

The outputs are video (into Save Video (Advanced)) and frames (an INT, how many the cache holds now - genuinely useful as a loop condition).

Install

ComfyUI Manager, search WAS Node Suite v3. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/WASasquatch/was-node-suite-comfyui.git

Needs ComfyUI 0.14.0+ and Python 3.10+. That's the entire install - v3 installs no packages, at any point. If you remember WAS Node Suite from 2023–2024, you remember a different pack: that one dragged in opencv, insightface leftovers and BLIP, and "WAS import failed" after a ComfyUI update was a weekly question on r/comfyui. That class of breakage is gone in v3. First start writes config.yaml under <ComfyUI user dir>/was-node-suite/, where paths.allow_write declares extra write folders if temp and output aren't enough.

Common issues

delete_after_save isn't just cleanup. Set it true and the node re-runs on every queue (the fingerprint is deliberately invalidated) so it can re-decode, and the cached frames are deleted once a save has written all of them. Great for a one-shot render-and-save, terrible if you're looping into the cache or want a second export.

append_to only accepts a cached clip. Wire it a plain video and you get a ValueError telling you so - appending to a real file makes no sense here. Frames added to an existing cache also have to match its size.

The cache is disk, not magic. Raw frames are big - 8-bit 1024×1024 is about 3MB per frame, so a thousand-frame run is a few GB you need free, and per-run numbering means a graph you queue ten times leaves ten caches behind.

Nothing loads a temp cache after a restart. That's the whole difference between the two roots; if the clip is worth keeping, use output and read it back with Load Video Cache.