SP_Pipe

If you've ever built a workflow with a model, a CLIP, a VAE, positive and negative conditioning, a latent, and an image all needing to travel together across half the canvas, you know the mess: seven parallel wires, all crossing each other, all needing to be re-dragged every time you insert a node in the middle. SP_Pipe exists to make that mess go away.

What it is

SP_Pipe is a bus node - same idea as Impact Pack's basic_pipe or rgthree's Context nodes, just SP-Nodes' own version of it. Every one of its inputs is optional: sp_pipe, model, clip, vae, positive, negative, latent, image. And every one of those has a matching output. The trick is that sp_pipe itself is both an input and an output, of type SP_PIPE - a bundle type unique to this pack.

Here's how you actually use it. Drop one SP_Pipe node right after your loaders and your first conditioning pass, wire in everything you've got, and take the single sp_pipe output forward instead of seven separate wires. Wherever you need one of those pieces again downstream - say, the VAE for decoding, or the model for a second sampler - drop another SP_Pipe node, feed it the sp_pipe wire, and pull out just the output you need. Because every field is optional on both ends, you can also use a second SP_Pipe to override one piece (swap in a different VAE, say) while everything else passes through untouched, then re-bundle and keep going.

The pieces that matter

You won't usually touch all seven fields on one node - that defeats the point. The two things to remember:

• Feed sp_pipe into the next SP_Pipe node to keep the chain going; feed the loose typed outputs (model, vae, etc.) into whatever regular node actually needs that specific input.
• Anything you don't wire in on a given SP_Pipe node just passes through unchanged from whatever sp_pipe you fed it - you don't need to re-supply the model every time if all you're changing is the latent.

Why bother

This is purely a graph-hygiene tool - it doesn't change what gets computed, just how many wires you have to look at. The payoff scales with workflow size: on a five-node graph it's not worth the extra click, but once you're chaining a sampler, an upscale pass, a detailer and a second sampler, unwinding seven parallel wires every time you insert something in the middle gets old fast. It's the same trade the wider ecosystem has already made peace with - rgthree's Context nodes exist for exactly this reason, and "cable management" is enough of a shared pain point that it has its own recurring threads in r/comfyui.

Installing it

SP_Pipe ships as part of the SP-Nodes pack:

• ComfyUI Manager: search "SP-Nodes", install, restart.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/bananasss00/ComfyUI-SP-Nodes, then restart ComfyUI.

No extra models or heavy dependencies here - it's pure Python plumbing, no downloads required.

Troubleshooting

The one real trap with any bus/pipe pattern: if you rewire an earlier SP_Pipe node and forget that a later one still has an old value locked into one of its optional inputs, that stale value will silently override whatever came down the sp_pipe wire, because an explicitly-wired input always wins over what's riding inside the bundle. If a downstream node is using an unexpected model or VAE, check every SP_Pipe node in the chain for a leftover explicit connection before you assume the bug is somewhere else. Beyond that, since this node is just a container for standard ComfyUI types, it won't itself throw type errors - the usual "expected MODEL, got something else" errors point at whatever fed the pipe, not at SP_Pipe itself.