Flow - Conditioning Auto Switch

A tiny node with a specific job: take whatever conditionings are connected and pass through the first one that actually exists. In a normal workflow that's a nothingburger. In ComfyUI-Flow-Control it's the merge point at the far end of a conditional branch - the thing that collects the output of whichever pipeline the pack's flow logic let run.

It lives in the Flow/clips category and is designed to sit after FlowClipCondition's two outputs. That node fans one CLIP out to an SD15 path and an SDXL path; only the branch matching your checkpoint survives the pack's graph pruning; and this switch is where the surviving branch's conditioning lands before it goes into the sampler.

How it works

The inputs are dynamic - the frontend gives you conditioning_1 and adds more conditioning_N slots as you connect additional wires. At execution it walks its inputs in order and returns the first non-None one as conditioning. If every branch is closed (or nothing is connected), it returns nothing.

The trick is what happens before execution: the pack's flow validation prunes the closed branches' nodes and deletes the inputs that would have fed this node from dead branches. So by the time this runs, there's typically one input left, and "first connected wins" is just the fallback rule for when the pack hasn't done the cleanup for you.

The inputs that matter

There's really one: conditioning_1 (and however many conditioning_N slots you connect). Wire the two FlowClipCondition outputs into it, one branch each. The single output, conditioning, goes to your positive or negative input on FlowKSampler.

Install

Ships inside ComfyUI-Flow-Control:

cd ComfyUI/custom_nodes
git clone https://github.com/krich-cto/ComfyUI-Flow-Control

Restart ComfyUI, or Manager → search "ComfyUI-Flow-Control". It's a pure-logic node; no models, no downloads.

Gotchas

Don't reach for this as a general "any of these" selector outside the Flow system - because the inputs are added dynamically by the UI, a workflow JSON saved with it may load with only conditioning_1, and you'll have to reconnect the extra branches. Also, "first connected" is about input order, so if you're using it without FlowClipCondition, the topmost connected slot always wins and the rest are ignored. For a simple unconditional merge you'd be happier with stock nodes; this one earns its place only in the conditional graph.