Bus Node (Dynamic)

A generation pipeline needs a model, a CLIP, a VAE, and positive and negative conditioning - five wires that have to run from your loaders all the way to the sampler. On a big workflow that's forty wires of spaghetti that all have to stay in sync. The context-bus idea, which several packs converged on independently, is to bundle those five onto one wire and unpack them where you need them. Bus Node (Dynamic) is WAS Node Suite's take, and its party trick is that it carries named extras on the same bundle - arbitrary values you can update partway down the line.

It lives under WAS Suite/Utilities. The optional bus input takes an incoming bundle from either this node or the plain Bus Node; the model, clip, vae, positive, and negative inputs each replace that member of the bundle when connected, and let it pass through unchanged when disconnected. The bus output carries everything, and separate model/clip/vae/positive/negative outputs hand you the members one at a time so you can wire the bus into the middle of an existing graph without changing your sampler wiring.

The extras: what makes it "Dynamic"

The plain Bus Node bundles the five standard members. This one adds up to 16 named extra slots (slot0, slot1, …) via the autogrowing slots input, and an unpack_slot number that picks which extra comes out on the slot output. So you can throw a seed, a width, a prompt, or whatever else onto the bus and have it travel alongside the model. Three outputs make the extras inspectable: slot (the value unpack_slot names), slot_names (the names of every extra on the bus, as an array - run it through Text List to Text to see what's riding along), and slot_count.

Two behaviours are worth knowing. First, a slot input with the same name as an extra already on the incoming bus replaces it - so a chain of these nodes can update a value partway along, the same way replacing model mid-chain does. Second, unpack_slot pointing past the end gives you nothing rather than an error, so a bus that hasn't been filled yet still runs - chain another Bus Node (Dynamic) to take a second extra off.

Where the bus pattern earns its keep

The context-bus design trades explicit wires for legibility: when a workflow is big enough that twelve wires × twenty nodes is unreadable, one bus wire makes the graph something you can actually look at. Load once, bundle, carry it down one tube, unpack at the sampler. The failure mode is the mirror image of the cure - with one wire you can't see which version of model is inside it, so the classic bug is unpacking a model from a bus assembled before the node that loaded your LoRA, and silently running base weights. Keep values on explicit wires where you're actively iterating; reach for the bus when the wire count is the actual problem.

The honest note on lock-in: WAS's BUS type is this pack's own, so a workflow that adopts it is married to WAS Node Suite. It reads and writes the same BUS as the plain Bus Node, but it won't talk to rgthree's Context or another pack's pipe - every suite invented its own, and they don't interoperate.

Installing

Part of WAS Node Suite v3 (WASasquatch/was-node-suite-comfyui), WASasquatch's MIT pack - going since 2023, over a million downloads. This node needs nothing beyond the pack: no packages, no models. It does require ComfyUI 0.14.0+, as the whole v3 suite is written against ComfyUI's newer node backend.

Via ComfyUI Manager, search WAS Node Suite v3, or clone it:

cd ComfyUI/custom_nodes
git clone https://github.com/WASasquatch/was-node-suite-comfyui

Restart ComfyUI and it appears under WAS Suite/Utilities. Missing from the menu after install? Update ComfyUI - that's the whole fix list for this one.