JLC Multi Reroute

If you've ever stared at a big ComfyUI graph and thought "I just can't stand messy noodles," you already know why this node exists. JLC Multi Reroute (class JLC_DynamicMultiReroute) is one compact node that hides a stack of up to twenty-four independent reroute lanes. Wire them through it and your canvas stops being a plate of diagonal noodles - without hiding the connections the way wireless Set/Get nodes do. Every path stays visible and traceable; it's just organized into a tidy strip instead of scattered across the graph as twenty separate reroute bubbles.

It's a minor utility in the jlc-comfyui-nodes pack, which is otherwise built around J. L. Córdova's non-recursive ControlNet composition work for Flux-heavy pipelines. But it's the kind of quality-of-life node you don't appreciate until you swap out a hundred reroutes for it.

How it works

Here's the clever part: the Python side of this node is nearly a stub. Look at its class and all you get is one wildcard value_1 input/output pair and a passthrough that returns whatever came in - a defensive fallback. The real implementation is JavaScript (web/jlc_dynamic_multi_reroute.js), and the node is marked isVirtualNode = true.

That matters because it means this node adds no Python execution stage. It doesn't copy tensors, doesn't keep runtime state, and doesn't appear in the actual prompt execution at all. Instead, when you queue a prompt, the frontend exposes each connected output's matching input link through ComfyUI's native virtual-node resolver, and the executable-graph compiler rewires every output straight to its upstream source. Same trick ComfyUI's own reroute uses, so it works across subgraph input boundaries too - the earlier prototype hit a "missing source node" bug there, and the shipped code deliberately avoids resolving the link origin to let the compiler handle it.

The rows manage themselves. The node starts with one pair and grows a trailing spare whenever you use the last one, up to twenty-four. Empty a row on both sides and it disappears, with surviving rows compacting upward while keeping stable internal identities, so your existing links don't get rerouted somewhere else. Each row resolves its own datatype independently - upstream type wins, a concrete downstream target can establish it while wiring backwards - and the socket plus link get recolored to ComfyUI's standard type colors. MODEL, LATENT, CONDITIONING and the rest stay readable at a glance.

The inputs that matter

info_schema shows just one optional value_1 (*, any type) and one matching output. Don't be fooled: that's only the initial row. The other twenty-three inputs and outputs don't exist in the schema because the frontend creates them dynamically as you connect - each is a strict input N → output N passthrough. One output can fan out to several consumers, same as a normal reroute. There's nothing to configure; you just wire it.

Installing it

Through ComfyUI Manager, search jlc-comfyui-nodes (it's also on the ComfyUI Registry as jlc-comfyui-nodes), or do it by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/Damkohler/jlc-comfyui-nodes.git

Then restart ComfyUI. To update later: cd ComfyUI/custom_nodes/jlc-comfyui-nodes && git pull. Good news: no model downloads and no extra pip dependencies - pyproject.toml just wants Python 3.10+ and ComfyUI >=0.2. Nothing heavy to sit through.

Where people get burned

• A row with a consumer but no upstream source is an invalid path. Queue the prompt and ComfyUI reports the error, with the Multi Reroute getting its normal red error frame so you can find it on the canvas. The node deliberately doesn't paint half-wired rows red while you're still building - only after a real prompt-resolution error - so a red frame means an actual broken row, not a work in progress.
• Frontend-virtual nodes are exactly the kind that break in frontend rewrites. The ecosystem's Nodes 2.0 rewrite already broke rgthree's popular reroutes for a chunk of the community, so if ComfyUI ships another big frontend change and this node stops growing rows, check that the extension loaded. If the JS never loads, you're left with the bare single-row passthrough fallback - harmless, but it's a hint the frontend half isn't running.
• It's a reroute, not a context bus. If your problem is that forty wires carry the same model and conditioning everywhere, you want a context/pipe node that bundles values, not more reroutes. Use this when the graph is too big to read; use a context bus when the wire count is the actual problem.

The one-liner: if you live in big wirey Flux workflows, it's a free organizer with no runtime cost. Name is a bit of a mouthful, but the node earns its keep.