Switches, Selectors & Bypass Routing — how the graph chooses a route
A large ComfyUI graph stops looking chaotic once you separate four mechanisms: a group defines a module, bypass includes or excludes it from execution, a selector chooses one route, and a shared control provides one authoritative value to several switches.
543 = 1 drives four switches
In mode 1, node 552 selects its own image1 #829, so output 715 does not participate. In mode 2, both switches select their second input and 715 passes SDXL decode #14 into 552.
Group, Bypass, Selector and Shared Control are different mechanisms
A common mistake in large workflows is to treat every switch as a simple on/off control. In practice, some controls choose a branch, some change node mode, and others only forward a numeric value downstream.
Identify the type of control first; only then interpret the specific 0/1/2 value.
| Mechanism | Primary question | What it changes |
|---|---|---|
| GROUP | What module is this? | Organization and functional boundaries |
| BYPASS | Should this module participate? | Execution state of nodes / group |
| SELECTOR / SWITCH | Which input continues downstream? | Active data route |
| SHARED CONTROL | Where does the value come from? | Authoritative INT / FLOAT / STRING for several consumers |
Four questions that quickly untangle routing
Node 543 is not “just another number” — it is the PEOPLE/PPL master selector
In the Hansen workflow, one linked INT control — node 543 — drives several selectors at once. Changing a single value therefore rebuilds multiple points of the PEOPLE/PPL route in sync.
A stored widget value inside an individual switch is not authoritative when its Input socket is linked to node 543. The authoritative value is upstream in 543.
| Consumer | What it selects | Why it matters |
|---|---|---|
| 459 | Which PPL composite returns to the main pipeline | Defines the final people route before 573 → 67 → 57 |
| 522 | Which mask/image representation enters the alternative branch | Affects the inpaint / preview route |
| 552 | Which people source is used downstream | Mode 1 selects FLUX person 829; the alternative mode uses the second source |
| 715 | Return / downstream source | A nested selector that becomes relevant only when the downstream switch selects its branch |
A selector can be connected without participating in the current route
Node 715 is connected in the graph topology, but in PEOPLE mode 1 the downstream selector 552 chooses its first input — FLUX person 829. The output of 715 therefore exists in topology but does not define the effective runtime route in this mode.
In the alternative mode, downstream selectors move to their second inputs and 715 becomes part of the path that is actually used. This is exactly why topology and the effective runtime map must be read separately.
Bypass answers “should it execute?”; a selector answers “what should continue?”
A selector works at the data-routing level: it chooses one of the available inputs. Bypass works at the execution-state level of a node or group. Both can exist at the same time and solve different problems.
In the official rgthree Fast Groups Bypasser code, the disabled state is mapped to mode 4, explicitly identified as Comfy bypass. The node also exposes Bypass all, Enable all and Toggle all actions.
| Situation | Use |
|---|---|
| Temporarily exclude a heavy module from a run | BYPASS / group bypass |
| Choose an SDXL source or a FLUX source | SELECTOR / SWITCH |
| Use one value to reconfigure several switches | SHARED CONTROL |
| Visually organize related nodes | GROUP |
Fast Groups Bypasser — a control panel for group execution state
Fast Groups Bypasser finds groups in the workflow and creates control toggles for them. This is a useful control-plane layer: instead of manually visiting dozens of nodes, you can enable or bypass entire functional blocks.
This is especially useful in a training graph. BASE CONFIG can expose only clear toggles such as INPUT, MASKS, PPL, SDXL, FLUX and UPSCALE while the internal nodes remain inside their respective groups.
rgthree implementation
FastGroupsBypasser uses LiteGraph.ALWAYS for the enabled state and mode 4 for bypass; exposed actions include Bypass all, Enable all and Toggle all.
When a branch “does not work,” check routing before the model
- Check whether the required group is in bypass.
- Find the selector immediately before the point where the expected result disappears.
- Trace the linked control upstream to its authoritative INT/FLOAT/STRING source.
- Label input1 / input2 with their real sources rather than abstract numbers.
- Check nested selectors: is the upstream switch even selected by the downstream node?
- Only after the route is confirmed should you diagnose sampler, model, prompt or mask.
Why switches can look chaotic
| Reading mistake | Correct interpretation |
|---|---|
| Looking only at the 1/2 number inside the switch | First identify what is physically connected to input1 / input2 |
| Trusting the visible widget value | A linked input can override the stored widget value |
| Assuming a connected branch is active | Connected does not mean selected; determine the effective runtime route |
| Confusing bypass with selector logic | Bypass changes execution state; a selector changes the data route |
| Changing several switches manually | Look for a shared upstream control / single source of truth |
Hansen practice: manually untangle the PEOPLE selector tree
- Find node 543 and record its current effective value.
- Trace its four links to 459, 522, 552 and 715.
- For every selector, write down what is actually connected to the first and second inputs.
- Draw the MODE 1 route and the alternative route separately with arrows.
- Mark which branches are connected but not selected in each mode.
- Then change only the master value and inspect the previews without changing model, prompt or seed.