VIV_Subgraph_Outputs

VIV_Subgraph_Outputs is the return statement of a ComfyUI subgraph. Where VIV_Subgraph_Inputs declares what the outside world feeds in, this node declares what your packaged workflow hands back. Anything you connect to it becomes an output on the VIV_Subgraph node that calls the sub-workflow - and, true to this pack's promise, any object type can travel: an image, a latent, a model, a conditioning, even a mix of different types on different slots.

How it works

Like its input counterpart, this node is all frontend magic - the info_schema shows no inputs, no outputs, nothing. Drop it into a sub-workflow and it starts with a single * input. Wire something into that slot and the extension records the source node's type, renames the slot, and adds another * input so you can chain on more returns. One slot per thing you want to return, in order.

At queue time the runner does the reverse of the input node's trick: it loads the sub-workflow, and whatever is sitting in the VIV_Subgraph_Outputs node's inputs becomes the tuple of outputs on the calling VIV_Subgraph node. That's literally the code - the subgraph's result is just tuple(output_node.inputs.values()). No separate executor, no hidden server: the sub-workflow gets expanded into the main graph and this node is the seam where results come back out.

What you actually set

Nothing to configure - this is a wiring node. What matters:

• Slot order: the order you connect things determines the order of the caller's outputs. Connect image first, latent second, and that's how they'll appear.
• Labels: rename the slot or the node to make the caller's outputs readable, same as inputs.

One thing you won't get is previews. The README is upfront: progress bars inside the subgraph show on the caller node, but image previews do not - you see the final output when the whole thing finishes. So if your subgraph is a big multi-step pipeline, don't expect live intermediate images.

Installing it

It's part of vivax3794's ComfyUI-Sub-Nodes. Install via ComfyUI Manager by searching for ComfyUI-Sub-Nodes, or:

cd ComfyUI/custom_nodes
git clone https://github.com/vivax3794/ComfyUI-Sub-Nodes

Then restart ComfyUI. Only dependency is rich, no model downloads. The sub-workflow itself must live in the subnodes/ folder in your ComfyUI root and be saved with the normal Save button (not the API export) for the pack's extra metadata to survive.

Common issues

Same hard rule as the input node: one output node per subgraph. A second one gets auto-removed with a dialog telling you to delete the original if you want to reset. It's an intentional guard, and a slightly annoying one if you habitually duplicate nodes to experiment - you'll be rebuilding your output wiring each time.

And the standing caveat applies here too: the pack is archived and unmaintained, and it was built to fight ComfyUI's frontend quirks rather than embrace them. If you're putting a new workflow together today, ComfyUI's native subgraph feature is the grown-up version of this idea. But when you open an old workflow that uses the pack, this is the node that says "these are the things this black box returns."