MultiPipe 1.5 In

If you've seen Efficiency Nodes, you've seen the pipe pattern: bundle a bunch of data into one PIPE_LINE object, drag a single fat wire across the canvas, and unpack it on the other side. The af_pipe_in_15 node (displayed as "MultiPipe 1.5 In") is the AegisFlow Utility version of that idea for SD 1.5 - one node that bundles a whole stack into a single pipe output.

What it bundles

Everything an SD 1.5 sampling section typically needs, all as optional inputs: image (IMAGE), mask (MASK), latent (LATENT), model (MODEL), vae (VAE), clip (CLIP), positive (CONDITIONING), negative (CONDITIONING), plus four sizing ints - image_width, image_height, latent_width, latent_height (all default 512). The node packs all twelve into a PIPE_LINE tuple and hands it to the first output, pipe. The pack ships the matching af_pipe_out_15 ("MultiPipe 1.5 Out") to unpack it on the far side, so the pipe's meaning stays consistent.

A quirk worth knowing: the second output is a STRING named discord, and it's just a hardcoded Discord invite link to the author's server. It's a real output - you can wire it to a text display if you want a working invite button, but nobody should build around it. Consider it free trivia.

Why you'd reach for it

Two reasons. If you're building a modular workflow in the Efficiency/pipe style, this gives you one nameable bundle point for the whole SD 1.5 stack - and because every input is optional, it doesn't invite the auto-wiring that can "fix" open sockets with the wrong values. And if you're designing reusable template sections, a pipe-in node is a clean, self-documenting receptor: one slot labeled "pipe" instead of eight loose sockets.

Installing it

Part of the AegisFlow Utility Nodes pack:

cd ComfyUI/custom_nodes
git clone https://github.com/aegis72/aegisflow_utility_nodes

Restart ComfyUI, or find "AegisFlow Utility Nodes" in ComfyUI Manager. No models, no extra dependencies.

Where people get burned

The pipe is only as meaningful as the unpacking node you pair it with - the tuple layout is an internal convention, not a standard, so wire this into af_pipe_out_15 (or another node that expects the same PIPE_LINE shape) rather than assuming any PIPE_LINE consumer understands it. Also, wire at least what you need: an empty pipe containing zeros travels fine, but it won't do anything useful on the other side. If you're on SDXL with a refiner in the stack, the pack's XL variants are the better fit - this one is strictly the SD 1.5 shape.