Load Video Cache

This is the other half of Video Cache, and it's the half that saves you an hour. Load Video Cache picks up a frame cache that's already on disk and hands it back to the graph as a clip. No sampling, no VAE decode, no re-rendering a five-minute H3 run because you closed the tab before you exported a second version.

Why you'd reach for it

Two jobs, really. The first is cheap re-exports: you rendered a clip, saved it as mp4, and now you want a ProRes master, or a GIF, or a different CRF - with this node you swap the save node's settings and re-queue. The frames come off disk a frame at a time, so a clip that would never have fit in RAM as one batch exports fine. The second job is crash insurance. A long render is a long render; if ComfyUI restarts or the job gets killed, a cache written to output is still sitting there and you carry on from it instead of paying for the generation again.

It's the same idea as a checkpoint you can rewind to, except it's pixels instead of a latent, and it costs gigabytes instead of megabytes.

How it works

A cache is a folder holding frames.bin, an optional audio.npy, and cache.wasframes - the JSON manifest that records the frame count, the frame rate, the depth and how the frames were stored. The node's cache widget lists every manifest it can find: up to 500 of them, drawn from ComfyUI's temp and output folders plus any folder you've added under paths.allow_write in the pack's config.yaml. Each entry is named for where it lives, like frame_cache/scene_00001/cache.wasframes [output]. Choose one and the node opens the folder and answers with a clip reader, not a decoded batch - which is exactly why this is memory-cheap.

One neat detail: the node fingerprints the manifest on disk, so if the cache behind a chosen name grows (because something upstream appended more frames to it), the node knows it's looking at stale numbers and reads again.

Inputs and outputs

There are only two inputs, which is the point of the node.

• cache - the dropdown. The only entry while no caches exist is the literal string no frame caches found, and choosing that (or nothing) raises ValueError telling you to write one with Video Cache or H3 Decode Video first.
• delete_after_save - true deletes the cache once a save has written all of it, so the frames get cleaned up behind you instead of piling up in output. Handy for a nightly batch, annoying if you wanted a second export from the same cache.

Out comes video (wire it into Save Video (Advanced) - the node reads the frames one at a time, so a 4K clip is not a memory event), frames, an INT with the cache's frame count, and frame_rate, a FLOAT with its fps. That last one matters: use it to drive the save node's fps if you don't trust your memory about what rate the cache was written at. An IMAGE path that plays back at the wrong speed is a mistake everyone makes once.

Install

ComfyUI Manager, search WAS Node Suite v3, or:

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

ComfyUI 0.14.0+ and Python 3.10+, then restart. v3 installs nothing - no pip run, no build step, no git submodule fetch. If you're coming from WAS Node Suite v2 and bracing for a dependency fight, you're remembering the old pack, which really was notorious for breaking on ComfyUI updates; the v3 install is a clone and a restart.

Common issues

A cache in temp is gone after a restart, and this node will say so. ValueError: cannot find <cache>; it was deleted or moved. Pick another cache. Nothing is wrong with your graph - the folder was in the temp root and ComfyUI cleaned it. Re-write the cache with root set to output next time, or move to a folder declared under paths.allow_write.

The dropdown is stale. The list of caches is built when the node's schema is defined, so a cache you just wrote in this session may not be in the menu until you reload the ComfyUI page. The node's own error message says this: write one, then reload the page so it's listed.

Two nodes, one cache, one of them deleting. If delete_after_save is true on both the loader and the saver, the cache is consumed by whichever gets there first, and the next queue fails with "cannot find". Right now there's no warning for that - keep delete_after_save to the node at the end of the chain.

It's not a video file importer. It reads the pack's own .wasframes caches and nothing else. For an mp4 sitting on disk you want the pack's Load Video (Advanced).