JLC Multi Get

JLC Multi Get is the read side of a wireless channel. Somewhere else in your graph a JLC Multi Set (or a plain KJNodes SetNode) publishes a value under a name; you type that name into this node and it hands you the value - no wire stretched across the canvas, no reroute chain, no trying to remember which of thirty threads connects to what.

The pitch: if you've got a value that's needed in two far corners of a workflow - a reference image, a conditioning, a seed that has to reach three samplers in a multi-stage Flux pipeline - the "clean graph" answer used to be reroutes or rgthree-style Context nodes that still physically carry the link. Wireless Set/Get is the other school, the one the community settled on after the "Anything Anywhere" extension got a well-earned "please stop" thread for breaking workflows and leaking state between runs. This is that idea, but done through ComfyUI's graph-level virtual-node protocol instead of a runtime registry - which is exactly the bit that kept the old approach honest.

How it works

The Python side of this node is a stub: one wildcard output, no inputs, and a function that just raises an error if it ever actually runs. That's deliberate. All the real behavior lives in the web/jlc_dynamic_multi_set_get.js frontend extension, which resolves each Get row to a real upstream graph link before the prompt is submitted. The backend never sees a "value registry" - there isn't one. The value travels over an actual link that the frontend materialized for you.

Why that matters: no stale state across runs, and no execution-order coupling. A wireless node that stores values in memory can hand you last run's result if the producing side never executed; this design can't, because by the time ComfyUI executes, the wire is just a wire.

It's also why the failure mode is loud rather than silent. If the web extension didn't load, running the node throws: JLC Multi Get is a frontend virtual node. Its web extension did not resolve this node before prompt submission. Annoying, but far better than quietly returning garbage.

What you actually set

The node itself has no inputs - it's a pure source, and its output value_1 is a wildcard (*), meaning it carries whatever type the channel holds: IMAGE, MASK, LATENT, CONDITIONING, INT, you name it. Up to 24 rows, each an independently named channel. Get rows don't take free-form text; they show a dropdown of available Set channels, and each selection binds to the Set row's stable identity rather than its name string - so if you rename a Set channel, Gets already pointing at it follow along instead of silently unlinking.

One compatibility note worth knowing: JLC Multi Get can read ordinary KJNodes SetNode channels when KJNodes is installed, but the reverse is not supported - a KJ GetNode can't resolve JLC Multi Set rows. So you can point this at an existing KJ workflow's Sets, but don't wire a JLC Set into a KJ Get and expect it to light up.

Install

It ships in the jlc-comfyui-nodes pack by J. L. Córdova. ComfyUI Manager can find it as "jlc-comfyui-nodes" (also on the ComfyUI Registry), or:

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

Then restart ComfyUI. There's no requirements.txt - no Python deps beyond ComfyUI core, which keeps install honest.

If it misbehaves

• The "web extension did not resolve" error - the JS didn't load. Restart ComfyUI, and make sure you cloned into custom_nodes/jlc-comfyui-nodes with the web/ folder intact.
• An empty or None Get - no Set is publishing that channel name, or you're selecting a channel with no connected source. Check the Set side actually has a value wired into its row.
• It does nothing when KJNodes is missing - expected; it only reads KJ Set channels when that pack is installed. The JLC pair works fully standalone.

It's a small node that solves a specific, real annoyance: the 200-node workflow that's unreadable because every far-flung value needed a physical wire. Reach for it when reroutes start looking like a maze.