🪛 Switch conditioning

Same boolean-switch pattern as the rest of Crystools' switch family, applied to CONDITIONING - the encoded prompt data that flows out of CLIP Text Encode nodes and into your sampler.

Why you'd reach for it

Any time you want to swap between two conditioning sources with a single toggle instead of rewiring: an A/B test between two prompt phrasings, swapping in a debug/override conditioning without disturbing your main setup, or flipping a style variant on and off. Like its siblings, it evaluates lazily - as of a 2025 release, only the branch actually selected by the boolean gets its upstream chain executed, so the conditioning path you didn't pick doesn't cost you a CLIP encode you're not using.

That lazy behavior is worth dwelling on for this specific node, because conditioning is one of the more expensive things to build unnecessarily - a full CLIP Text Encode pass on a prompt you're not even using would be pure waste every single run if the switch evaluated both sides eagerly. Building your prompt A/B tests around this switch instead of, say, a manual reroute means you genuinely only pay for the branch you're testing.

How it works

The boolean routes one of two CONDITIONING inputs straight through to the output - no transformation, no blending, just a clean pick between two fully-formed conditioning objects.

Inputs and outputs

Required: on_true and on_false, both CONDITIONING, and boolean (default true, so on_true passes by default). Output: conditioning.

Installing it

Through ComfyUI Manager, search crystools. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/crystian/ComfyUI-Crystools.git
cd ComfyUI-Crystools
pip install -r requirements.txt

Restart ComfyUI. Nothing extra to install for this node.

Common issues

It's type-locked to CONDITIONING, so feeding it a LATENT or an IMAGE just won't connect - reach for Switch any instead if you need something generic. The subtler trap: conditioning isn't always a single uniform shape - depending on the model, it can bundle an embedding, a pooled output, and extra fields - so both on_true and on_false need to genuinely come from compatible encoders. Mixing conditioning built for two different model families (say, one SDXL-style and one plain SD1.5) on either side of this switch can produce a graph that looks correctly wired and still samples wrong, because the switch itself has no way to validate that the two branches are semantically compatible, only that they're both typed CONDITIONING.

If a sample comes out looking nothing like either prompt you expected, that mismatch is the first thing worth ruling out before you start second-guessing your prompt wording or your sampler settings.