Routing Sandbox: selector, bypass, lazy execution and cache without generative models
The first lab deliberately removes SDXL, FLUX, VAE and model concerns from view. What remains is pure graph logic: two data sources, a selector, one output, Queue Prompt, bypass, and observation of which branch the engine actually requires.
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.
What you should understand hands-on in 10–15 minutes
The goal is not to memorize more node names. The goal is to experience the difference between CONNECTED, SELECTED, REQUIRED and EXECUTED.
After this lab, the large Hansen graph should no longer look like a web of wires, but like a set of branches from which a selector chooses the current runtime route.
Primary question
Not “where does this wire go?”, but “which upstream path is actually required by the selected output right now?”
Why no models
VRAM, samplers and prompt quality should not distract from routing logic.
Build a minimal graph from four functional parts
- Create two easy promptLine nodes and group them as ROUTE A and ROUTE B.
- Set A to ROUTE A · ORIGINAL. Set B to ROUTE B · ORIGINAL.
- Create easy textIndexSwitch and connect A → text0, B → text1.
- Connect the text output to easy showAnything. This is the only output in the lab.
- Start with selector index = 0.
CONNECTED ≠ SELECTED
textIndexSwitch behavior
Index selects one textN input; lazy status requests only the corresponding input.
| Action | Expected output | What this proves |
|---|---|---|
| index = 0 → Queue Prompt | ROUTE A · ORIGINAL | A is selected; B is physically connected but not selected |
| index = 1 → Queue Prompt | ROUTE B · ORIGINAL | The selector changes the effective route without rewiring the graph |
| return index = 0 | ROUTE A · ORIGINAL | Topology did not change; only the control value changed |
CONNECTED ≠ REQUIRED
Keep index = 0. Change only ROUTE B to ROUTE B · CHANGED and press Queue Prompt.
The key observation: the output should still show ROUTE A. Changing an unselected branch does not make it part of the current required path.
REQUIRED does not necessarily mean recomputed from scratch
Without changing index or ROUTE A, press Queue Prompt again. Then change ROUTE A to ROUTE A · CHANGED and run once more.
The point of the experiment is to separate the requirement graph from execution/cache behavior. The same required route can reuse valid intermediate results until an input change invalidates the relevant segment.
What to observe in the UI
Watch which nodes are actually highlighted as executing after changes to the selected and unselected branches; the exact visualization depends on the frontend version.
BYPASS is a separate control axis
Now deliberately put one source node or a test group into bypass and compare that behavior with simply selecting a different index.
A selector answers which input to use. Bypass answers whether a particular node or group should perform its normal processing. These are different states.
After the sandbox, open PEOPLE/PPL and ask the same four questions
- Which branch is CONNECTED?
- Which branch is SELECTED?
- Which branch is REQUIRED by the current output?
- What actually EXECUTED, and what may have come from cache?
| Sandbox | Hansen PEOPLE/PPL |
|---|---|
| index | master / linked selector value |
| ROUTE A / B | FLUX person route / alternate route |
| textIndexSwitch | 459 / 522 / 552 selector family |
| showAnything output | return into downstream / final output |
You pass the lab when you can explain these points without prompts
- Why a connected branch may not contribute to the result.
- Why a selector is not the same as bypass.
- Why left/right screen position does not define execution order.
- Why changing an unselected branch does not necessarily affect the current output.
- Why a repeated Queue Prompt does not imply a full recomputation of the canvas.
- How to find the effective runtime route in a large production workflow.
Progression criterion
Once these six points are clear in the sandbox, move on to Modules & I/O Contracts and then read the Hansen workflow as an engineering graph.