Checkpoint Loader v4 (Pipe)

Most ComfyUI loaders make you pick: either you load a full checkpoint, or you load a diffusion model plus separate CLIP files. The v4 loader is the one that shrugs and does both, and hands the result out as an RvTools "pipe" - one wire that carries model, clip and VAE down the graph together. If you build workflows that need to run a classic SD checkpoint one day and a Flux-style UNet + T5 setup the next, this is the node that stops you rebuilding the loading half of the graph each time.

What it actually does

Under the hood it's two loaders with a single face. The load_unet_checkpoint toggle decides which path you're on:

• Checkpoint path (load_unet_checkpoint off): pick a ckpt_name and it loads the whole thing with load_checkpoint_guess_config, pulling out the baked-in CLIP and VAE.
• UNet path (load_unet_checkpoint on): pick a unet_name from your diffusion_models folder and it loads just the UNet with load_diffusion_model. That's the Flux/SD3 flow. On this path the VAE is not baked - if you leave vae_name on "Baked VAE" the node refuses with "Select a VAE File", so grab a real .safetensors from your VAE folder.

The weight_dtype menu is where this gets interesting: default, fp8_e4m3fn, fp8_e4m3fn_fast, fp8_e5m2. Those are the quantized weights options that get threaded into the model loading as torch.float8_e4m3fn / float8_e5m2 dtypes. On a 24 GB card you usually don't need them, but for Flux on 16 GB or less, fp8 is the difference between "it runs" and "CUDA out of memory". fp8_e4m3fn_fast is the one people reach for when the standard fp8 feels sluggish.

The inputs that matter

• ckpt_name / unet_name - pick exactly one, matching the load_unet_checkpoint switch. Pick neither and it errors; mix them up wrong and it tells you, helpfully, what combination it expected.
• clip_type_ - defaults to flux, with ~25 options from sd3 and sdxl through ltxv, wan, hunyuan_video and cosmos. This maps to ComfyUI's CLIPType enum, which tells the loader how to construct the text encoder for that architecture. Getting this wrong on an SDXL model is a classic source of silent garbage.
• clip_name1–clip_name4 - used when baked_clip is off. It'll load one, two, three or four CLIP files depending on how many you fill in. Flux needs both the T5 and CLIP-L, which is exactly why this loader exists.
• baked_clip / enable_clip_layer / stop_at_clip_layer - whether to reuse the checkpoint's baked-in CLIP, and whether to apply clip-skip-style layer stopping (default −2).

The single pipe output carries model, clip, VAE, then width/height/batch placeholders (8, 8, 1) and the model + VAE names. It wires straight into RvTools pipe passers and the out-nodes that split a pipe back into individual wires.

Install and the elephant in the room

cd ComfyUI/custom_nodes
git clone https://github.com/r-vage/ComfyUI-RvTools_v2
# restart ComfyUI

Or use ComfyUI Manager, search "ComfyUI-RvTools_v2", and install from there. The pack needs no model downloads of its own - it just needs the checkpoints/UNets/VAEs you already have. Dependencies are the usual suspects: torch, numpy, Pillow, opencv-python, piexif, pilgram.

The elephant: the README leads with a warning that this pack is no longer maintained and has been superseded by ComfyUI_Eclipse, which includes most of the same nodes. If you're starting fresh, that's worth reading before you invest in a pipe-based workflow. If you're loading an existing workflow that references this node, it'll keep working - it's just frozen, not broken. Where people get burned: this is v2, and the original ComfyUI-RvTools repo vanished from GitHub in early 2025, leaving workflows that depended on it unable to install - the community thread on it (r/comfyui) is full of people copying the folder between installs to recover. v2's renamed classes are what keeps those workflows alive today.