VAE Router

Third of the pack's three routers, same template as the other two: N VAE inputs, one VAE output, one integer picking which is live. Same install, same inputcount / active_channel widgets, same "click Update inputs" mechanic to grow the port count from 6 up to 30.

It looks like the least interesting of the three. It's actually the one guarding the quietest failure in the whole workflow.

Why anyone has more than one VAE

Because the right VAE is the one the checkpoint was trained against, not the one with the best reputation - and that answer has flipped over the last couple of years. On SD 1.5 the VAE was usually a separate file you attached to fix washed-out colour. On modern checkpoints it's baked in, and attaching a foreign one is the mistake, not the fix. Then in 2026 the swap came back for a different reason entirely: people swap decoders to undo over-smoothing a model was deliberately trained into, rather than to add colour.

So a VAE collection is normal again, and it can include files with incompatible latent spaces. Which is exactly why "just point the wire at the right one" is a task worth automating.

How it works

inputcount (INT, 6–30, default 6) sets the ports; active_channel (INT, 1–30, default 1) says which one passes through; the output is a single VAE. It's the indexed-selector switch shape - you choose, it doesn't fall back to the first non-empty port the way rgthree's Any Switch would. Set active_channel to a channel you never wired and you're passing nothing downstream, which will show up as a complaint from the node that consumes it, not from the router.

Where the VAE output goes is broader than people expect. Not just VAEDecode and VAEEncode - this pack's own CFG Sculptor Advanced takes a required vae input and decodes internally, handing you finished IMAGEs. Route your VAE into that node and it's doing the pixel work for every branch of a multi-model comparison at once. That's the actual pitch of these routers: three of them, side by side, and one active_channel per router switches the model stack everywhere.

The failure this prevents

A wrong VAE is the worst kind of bug in ComfyUI: it doesn't error, it just returns an image that's wrong. Grey, washed out, desaturated output means a missing or mismatched decoder - that's the SD 1.5-era signature. Black images and NaN during decode is the other one, historically from running SDXL's VAE in fp16, which is why the fp16-fix VAE exists at all. And every encode/decode round trip costs a little quality regardless of which VAE you picked, so the goal isn't "more VAE," it's "the correct one, chosen deliberately."

Which is the honest argument for the router over manual rewiring: not that it's convenient, but that switching the checkpoint and forgetting the VAE produces a silently wrong image, and a labelled channel you flip is much harder to forget than a wire.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Rimor-dev/ComfyUI-CFG-Sculptor
# restart ComfyUI

Use Rimor-dev - the README's clone line has Rimor/ in it, which is a typo. Or install through ComfyUI Manager by searching ComfyUI-CFG-Sculptor. torch and numpy only; no model files ship with the pack, and your VAE files still live in ComfyUI/models/vae/ where every other loader expects them. Needs a current ComfyUI with comfy_api support, since the pack is written against the newer backend node API.

Keep it in lockstep

The one thing to internalise: the VAE router, the Model Router and the CLIP Router have to be moved together. Three separate active_channel widgets on three separate nodes is a stack that can disagree with itself, and when it does, only the VAE failure is loud enough to notice - the wrong encoder gives you worse conditioning, and the wrong CFG range gives you a burned image you'll blame on your prompt. If you only install one of the three, install the VAE one. If you install all three, make a habit of changing all three.