Unload ReActor Models 🌌 ReActor

ReActor keeps its models - the face analyzer, the swap model, whatever restoration model you've picked - resident in VRAM after it runs, because reloading them from disk every single execution would be painfully slow. That's the right default for a workflow that's just doing a face swap. It's a problem the moment your graph does a swap and then something VRAM-hungry afterward - an upscaler, a video model, a second checkpoint - and ReActor's models are still sitting there eating memory they're not using anymore. This node's entire job is evicting them on command.

How it works

It's a trigger node. Wire any image through its trigger input, and as a side effect - before passing that same image straight back out unchanged - it drops ReActor's currently loaded models from VRAM. Where you place it in the graph is the whole control surface: put it right after your last ReActor node and before the step that needs the memory back, and that's the order it runs in.

The trigger input being typed IMAGE rather than something more literal isn't ReActor being weird - ComfyUI's graph runs off data dependencies, so a node needs something to consume and produce to get scheduled at the right point. The image itself is never touched; it's just the plumbing that gets this node to run where you put it.

The inputs and outputs that matter

There's exactly one input and one output, and that's the entire node:

• trigger (required, IMAGE) - any image. Feed it the output of whatever ran last, typically your face swap or restoration node.
• IMAGE (output) - the same image, unmodified, passed straight through to whatever comes next.

How to install it

ComfyUI Manager: search "ReActor", install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/Gourieff/ComfyUI-ReActor

then run install.bat (Windows) or python install.py (Linux/macOS) inside the cloned folder before restarting ComfyUI. This node needs nothing beyond the base install - it has no models of its own, since its only job is releasing ones another ReActor node already loaded.

Common issues & troubleshooting

You don't actually need this in a simple workflow. It exists specifically for "complex WFs" that chain a face swap into something else memory-hungry, per the pack's own release notes. If your graph is just load image → swap → save, adding this node buys you nothing and just adds a reload cost the next time ReActor runs.

VRAM usage doesn't seem to drop after this node runs. Check what you're measuring it with - tools like nvidia-smi or Task Manager often keep showing memory as allocated even after it's freed, because PyTorch's CUDA allocator caches it for reuse rather than handing it straight back to the OS. That cached memory is available to the next model that asks for it; it isn't a leak.

ReActor is slow the next time it runs later in the same workflow. That's the trade you made. Unloading frees the memory, but the next ReActor node has to reload everything from disk from scratch. Only place this node where the VRAM you free is actually needed downstream - don't sprinkle it between every ReActor node in a graph that uses several in a row.