🎬 Melite Unload (film boundary)

This node looks like a memory-management node and is mostly not one. Its real job is graph ordering, and the failure it prevents is the nastiest kind in video work: a film that stitches together correctly and is completely wrong.

The failure it exists for

Long videos are usually built in windows - generate this stretch, save it, generate the next, save it, concatenate. The moment the concatenation step is a node that reads files off disk instead of consuming tensors, you've introduced a race you can't see. ComfyUI schedules a node as soon as its declared dependencies are satisfied. A file-reading loader has no data dependency on the save that writes the file, so nothing stops it from globbing the output directory a beat too early and quietly picking up the previous run's renders. The stitch succeeds. The film is wrong. You find out after the render.

MeliteUnload is the wire that removes the ambiguity: the loader declares a dependency on this node, and this node declares a dependency on the save's output. Ordering falls out of the graph, not out of timing luck.

How it works

video is a VIDEO input - you wire the passthrough coming off your last window's save. That single edge is what makes everything downstream of this node wait for the save to complete, and it also makes that tensor die here, since nothing consumes it afterwards.

Then it always calls ComfyUI's soft_empty_cache, which releases the CUDA allocator's cached blocks. It does not unload model weights by default. That's deliberate: the next render pays no reload, and the film tail's decode/encode work is CPU-side anyway, so cached weights aren't competing with anything. Tick unload_models and you additionally call unload_all_models for a full wipe - the case where your loader bypasses ComfyUI's own VRAM management and needs an actually-empty GPU.

There's one optional input, after, and it's the clever bit. It accepts a prior boundary's token. Because the token is a constant string, wiring it creates an edge without carrying any data - pure ordering. Chain one boundary per window save and the final token transitively depends on every save in the film. Without the chain, each boundary only orders its own save, and the other windows' writes stay unordered islands your loader can beat.

Inputs and output

video - required, type VIDEO. The save you want to wait for. If you have nothing that emits a VIDEO after your write, there's nothing for this node to hold onto.

unload_models - boolean, off by default. Leave it off unless you know why you need it.

after (optional) - a prior boundary's token. Wire it when you have more than one window. It's never read; it only exists so ComfyUI schedules you behind it.

after - the output, a STRING, always the same constant. Downstream loaders wire it into their after input. It's a scheduling token, not a value - if you find yourself trying to print it, you've misread the node.

Installing it

Same pack, same one-time install:

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/JayDataEngineer/melite-utility-nodes.git

Restart, or grab Melite Utility Nodes in ComfyUI Manager. The pack's requirements.txt lists matplotlib and av - this node uses neither; they're for the plot and decode nodes.

Where it bites

• It's not a VRAM lever. By default nothing is unloaded, and soft_empty_cache only returns cached blocks to the allocator. If you bought this node hoping for "free memory between windows", you got the wrong one - though the default is the right choice for most people, since reloading a 20 GB checkpoint every window costs far more than the cache it frees.
• Skip the after chain and you're back to the race. One boundary per save is the safe pattern. The pack's own write-up cites a stale stitch and a hard no-match failure from exactly this, which is a refreshingly specific bug report for a node's docstring.
• unload_models=True will make your next run slow. That's the point - it's for loaders that fight ComfyUI's allocator. If you tick it and everything gets slower and nothing gets better, untick it.
• Break the wire and the guarantee vanishes. Delete the video edge, or let a loader take the file path directly from somewhere else, and you're back to "probably fine". This node's whole value is that the dependency is explicit, so keep it that way.
• This is a first-party pack; the community won't rescue you. Searching for it turns up effectively nothing outside the repo, so the node's own error strings - which are unusually explicit - are the documentation.