Free Model & Node Cache

You know the little broom button in ComfyUI's top toolbar - "Free model and node cache"? It exists because after a few generations on a heavy checkpoint, VRAM quietly fills up and the next run just… hangs. The problem was never that the button doesn't work. It's that you have to be there to press it, at the exact moment ComfyUI is most likely to be frozen or mid-queue. VRAM-Hoarder's FreeModelAndNodeCache is that button as a node: drop it inline in a workflow and the cleanup runs itself after every generation - one less thing to remember on long unattended sessions.

What it actually solves

ComfyUI keeps models loaded and memory cached on purpose - reloading a checkpoint is the slow part, so it holds on until something needs the space. Fine for a couple of runs. Across a long session with demanding models (the author's example is large bf16 checkpoints; people hit the same wall with video models like LTX-Video), usage creeps up generation by generation until the next prompt dies with an out-of-memory hang and you're hard-restarting. The community's standard answer has been manual - there are whole threads about remembering to hit the free button between runs. But if you run long queues or ComfyUI headless, there's no one around to click, and that's exactly the gap this node fills.

Why this one over the existing cache nodes

Other packs already ship graph-level cleaners - ComfyUI-Easy-Use's "Clean VRAM used" and "Clear cache all" - and the author's whole pitch is that they're weaker. Those reach into ComfyUI's Python-level model-management objects from inside the graph; in his testing, VRAM still creeps up across runs with big checkpoints until the process hangs. This node instead calls ComfyUI's own REST endpoint, the same POST /api/free the toolbar button fires, so it goes through the server layer that actually owns the model cache. Read the source and that's literally what it does: requests.post to http://<server>/api/free with {"unload_models": true, "free_memory": true}.

Honest read: the difference is plumbing, not magic - same cleanup, but taken through the exact code path the button uses instead of the in-graph one that keeps letting people down. When that weaker route has burned you, "same path as the button" is a fair thing to want.

How it works

The node is a wildcard passthrough: its input and output sockets are the type *, the same mechanism ComfyUI's built-in Reroute uses. It accepts an IMAGE, a LATENT, video frames, anything, and forwards it unchanged - so you splice it into a chain without breaking the wire. Standard home is between VAE Decode and Save Image / Save Video. When ComfyUI executes it, it fires the cleanup and prints a status line to the console. Sitting in front of your Save node, it runs on every full generation; flip enabled off and it degrades to a plain passthrough.

The inputs and outputs that matter

• anything (required, any type) - the pass-through; wire your decoded image or latent in.
• enabled (default true) - master switch. Turn cleanup off without rewiring.
• unload_models (default true) - unload loaded models from VRAM and RAM.
• free_memory (default true) - also free the cached memory pool.

Outputs are anything (passed through unchanged, to your Save node) and status, a string like "Cache cleaned successfully" you can surface or log.

Installing it

Via ComfyUI Manager, search the pack title "ComfyUI Free Model and Node Cache". Or by hand:

cd ComfyUI/custom_nodes/
git clone https://github.com/VRAM-Hoarder/ComfyUI-Free_model_and_node_cache.git

Then restart ComfyUI. Its only dependency is requests, which ComfyUI already has, so there are no heavy installs or model downloads to babysit. The node appears under utils/system as "Free Model & Node Cache".

Common issues and the trade-offs

The main gotcha is the reload cost: unloading every run means the next generation re-reads the checkpoint from disk - negligible on fast NVMe, annoying on slow storage. If you're batching many prompts on the same model, the author's own advice is to only enable the node on the last run of a batch rather than every single one (you can feed enabled from a toggle or primitive).

Second gotcha: the node auto-detects its server address from PromptServer, swapping 0.0.0.0 for 127.0.0.1. If your ComfyUI backend runs on a different machine than the one executing the workflow, that address may be unreachable - the README has you hardcode the host/port in free_cache_node.py in that case. And remember it's an HTTP call back into your own server, so don't firewall the API port and expect it to work.

For long unattended sessions on heavy checkpoints - video or giant bf16 models especially - this is the one to reach for. It's tiny, single-purpose, MIT-licensed, and costs one passthrough node for never babysitting the button again. Worst case you set enabled wrong and it does nothing; best case it's the difference between a 40-run queue that survives and one that hangs at generation 37.