Load Checkpoint (Auto VAE/CLIP)

The chore this deletes

You load a checkpoint, and then you need three more nodes to actually use it. An SD 1.5 model you pulled off CivitAI probably expects vae-ft-mse-840000-ema-pruned, downloaded separately because the checkpoint didn't bake one in - and SDXL mostly bakes its VAE right up until the one fine-tune you care about doesn't. A VAE that doesn't match the checkpoint gives you grey, washed-out output or flat colour, the most common "why does my image look wrong" report there is, and usually misdiagnosed as a prompt or sampler problem for weeks.

Load Checkpoint (Auto VAE/CLIP) folds that bookkeeping into the loader. You pick a checkpoint from one dropdown. A JSON file next to the node decides which external VAE and which text encoder to slot in.

How it decides

Under the hood it's the normal core path - load_checkpoint_guess_config, the same function CheckpointLoaderSimple uses - and then it looks up a rule for the file you picked. The mapping file is model_map.json in the pack's auto_checkpoint/ folder. Copy model_map.example.json to model_map.json and edit:

{
  "@SDXL":  { "vae": "sdxl_vae.safetensors" },
  "@SD15":  { "vae": "vae-ft-mse-840000-ema-pruned.safetensors" },
  "pony/*": { "vae": "sdxl_vae.safetensors" },
  "my_checkpoint.safetensors": {
    "vae":  "sdxl_vae.safetensors",
    "clip": ["clip_l.safetensors", "clip_g.safetensors"]
  }
}

Entries are tried most-specific-first: the exact file name as it appears in the dropdown, then a wildcard pattern (pony/*, shell-style globbing), then the architecture as @SDXL or @SD15. vae names resolve inside models/vae; clip names inside models/text_encoders. The architecture isn't something you guess - it's read off the loaded model's config class, and the four strings the code treats as CLIP-swap-capable are SD15, SD20, SDXL and SDXLRefiner. So run it once on a new model, read the info output (arch=SDXL | match=@SDXL | vae=sdxl_vae.safetensors | clip=checkpoint), and copy whatever arch= says into the map as @ThatString. The same line is printed to the console every run.

Two things about the CLIP half. External CLIP is only honoured on SD1.5, SD2 and SDXL-family checkpoints; elsewhere the node prints a note and keeps the checkpoint's own CLIP, which is usually what you wanted anyway. And two CLIP files means clip_l plus clip_g, loaded as an SDXL pair with STABLE_DIFFUSION clip type - not an arbitrary stack.

What you wire

The only input is ckpt_name, a dropdown of everything in models/checkpoints. There are no widgets beyond that and nothing clever to configure in the graph - the intelligence lives in the JSON.

Four outputs: model, clip, vae - the same three prongs as a core loader, straight into your sampler and text encoders - plus info, a STRING. Don't ignore info. Wire it into a Show Text node and your graph tells you which VAE it actually applied, which turns "did the swap work?" from a guess into a glance. It's also the fastest way to confirm a wildcard rule fired instead of the @ARCH fallback.

One quality-of-life detail most loaders skip: the cache key includes the mapping file's modification time. Edit model_map.json, hit Queue, and it takes effect - no restart.

Install

ComfyUI Manager → search X4Lch3mist → install, then restart. Or by hand:

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

Restart ComfyUI and the nodes appear under the X4Lch3mist category. Nothing to pip install - the pack declares zero Python dependencies and imports only ComfyUI's own modules and torch, which is rarer among node packs than it should be. GPL-3.0.

Where people get burned

No model_map.json is not an error. The node checks for the file, finds nothing, and behaves exactly like a plain checkpoint loader. If your VAE swap appears to do nothing, check the file is really named model_map.json (not .example.json) and sits in auto_checkpoint/, not the pack root.

Wrong folder, hard stop. vae names resolve in models/vae and clip in models/text_encoders, so a VAE dropped into models/checkpoints fails with [AutoCheckpoint] vae: <name> not found. At least the error names the folder.

Mismatched VAE is still mismatched. The node loads the right VAE per model; it can't save you from a wrong mapping. Channel counts differ between architectures, and crossing them gives noise or flat colour rather than a subtly-off image.

Metadata. Filename patterns and metadata panels that use %model% are filled from a "capture list" that packs like Impact Pack register. On first execution this node adds an entry for itself to whichever of those lists it finds, so %model% keeps working after you replace the plain loader - and if no list exists it says so in the console, which is what to check when the model field comes out empty.

It's a checkpoint loader, not a diffusion-model loader. Single-file checkpoints only. Split pipelines - GGUF quants, separate Flux/Wan/Z-Image diffusion weights - are a different flow.

Verdict

This pack has essentially no community footprint yet: new pseudonymous author, no threads, no tutorials. For this node that's survivable, because it's a thin, readable layer over a core function with loud failure modes. It earns its place if you run a mixed library and keep pairing VAEs by hand - an SDXL realism checkpoint, a Pony merge and an SD1.5 model in the same week. If you run one model that bakes its VAE, the core loader plus a VAE Loader is already less setup.