CLIP Router

Two text encoders, one workflow, and every time you want to test the other one you're dragging a wire across the canvas. CLIP Router is the boring fix for that: N CLIP inputs, one CLIP output, and a single integer widget deciding which input is live. That's the entire node.

It's one of three routers in this pack (Model, CLIP, VAE) built from the same template, and CLIP is the plainest of them. Worth knowing because the pack's example workflow uses them together: four parallel sampling branches, A through D, with active_channel as the one dial that swaps the model, the encoder and the VAE for all four at once.

How it works

The schema is two widgets and an output:

• inputcount - INT, 6 to 30, default 6. This is how many CLIP ports the node draws; the tooltip on its sibling says "Click 'Update inputs' to apply," so you set the number and then hit that button. Ports beyond the ones you use just sit there.
• active_channel - INT, 1 to 30, default 1. "Which input to pass through," and it does exactly that.
• Output: a single CLIP.

Mechanically this is the A/B switch shape: a selector plus a set of inputs, and you point the selector at the branch you want. That's different from a fallback switch - rgthree's Any Switch "chooses the first input that is not null/empty" and needs no selector at all. A router never chooses for you. If you wired port 3 to a text encoder and set active_channel to 3, that's what comes out; if you set it to 4 and left 4 empty, you're passing nothing down the line and the complaint will surface at the text encoder, not here. That's the sharp edge of index switches generally, not a bug in this one.

Because the output is typed CLIP rather than a wildcard, this node can only ever route encoders - you can't repurpose it to carry a latent. That's the trade for type safety, and it's the right one.

What you'd wire it into

Encoder out into whichever node wanted the CLIP: a CLIPTextEncode, an IP-Adapter-style node, or a second sampling branch you keep around for comparisons. Change active_channel and ComfyUI re-runs everything downstream, because the cache keys on the node's inputs - so flipping the channel really does re-encode your prompts and re-sample. No stale-context trap here; the thing that makes this safer than a context-bus pipe is that you can see which port is live.

Install

Same pack, same steps:

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

(the README's own clone URL says Rimor/, a typo - use Rimor-dev), or search ComfyUI-CFG-Sculptor in ComfyUI Manager. Dependencies are torch and numpy, no model files, but it wants a recent ComfyUI with comfy_api support since it's written against the newer backend node API.

Should you bother

If you switch encoders once a week, no. If you keep two or three models in one workflow - which is the whole premise of this pack - then yes, and the honest reason is the pairing: a CLIP router on its own is a nicety, but CLIP Router + Model Router + VAE Router together mean one integer changes your entire model stack. The classic failure without them is switching the checkpoint and forgetting the encoder or the VAE, which doesn't error, it just quietly produces nonsense.