VAE Switch (JPS)

Same idea as the rest of this pack's switch family, applied to VAEs: five optional VAE inputs, one integer selector, one VAE output. Whichever numbered input select points at is what gets passed downstream to your decode node.

Why you'd actually keep more than one VAE around

This isn't just a tidiness node. SDXL is the textbook case for needing more than one VAE on hand - the original SDXL VAE has a well-known fp16 stability problem where it can produce black or NaN'd images depending on your precision settings, which is exactly why the fp16-fixed community VAE (commonly distributed as sdxl-vae-fp16-fix) exists and gets swapped in on a lot of setups. If you're maintaining both - the checkpoint's baked-in VAE for one branch, a known-good fixed VAE for another, or comparing two aesthetic-tuned VAEs against each other - this node lets you pick which one a decode step actually uses from a single dial instead of rewiring the decode node's VAE input every time.

How it works

select is a plain integer and it's 1-indexed against the numbered inputs - set it to 1 for vae_1, 3 for vae_3, and so on. You don't need all five wired; only connect the VAEs you're actually switching between and point select at a slot that's live.

The same 1-indexed convention runs through every switch in this pack - Integer, Image, IPA, and this one - which is what makes them composable. If you're building a workflow with a couple of distinct "modes" (say, a fast-preview branch versus a final-quality branch that also needs a different VAE), you can drive several of these switches off the same upstream integer value and flip every one of them at once instead of maintaining separate switches with separate selectors that have to be kept in sync by hand.

A second reason to reach for this beyond SDXL

Even outside the fp16 stability issue, some finetuned checkpoints bake in a VAE that's noticeably softer or more washed-out than the community's preferred standalone file for that architecture - a recurring enough pattern that "which VAE should I actually use with this checkpoint" is a standard question on release threads for new models. Keeping the checkpoint's own VAE in one slot and a known-good alternative in another, switched with one number, is a fast way to A/B that question yourself rather than trusting whatever the checkpoint shipped with.

Installing it

Comes with the pack. ComfyUI Manager: search JPS Custom Nodes for ComfyUI, install, restart. Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/JPS-GER/ComfyUI_JPS-Nodes.git

Restart afterward, and remove any prior install of the pack before installing fresh - the README flags this as the one thing to get right. Nothing to download for this node specifically; it routes whatever VAE objects you feed it from separate VAE Loader nodes elsewhere in the graph.

Where people get tripped up

select pointed at an unwired slot is the standard failure mode across this whole switch family - no error, just a dead output, and it's easy to miss in a large graph. The other thing worth knowing: this switch routes an already-loaded VAE object, it doesn't load anything itself, so you still need a VAE Loader (or your checkpoint's baked-in VAE) feeding each of the numbered inputs before there's anything to switch between.