Dictionary Bus Unpack
The Other End of the Dictionary Bus
- dict_bus
- bus
- dict
- model
- clip
- vae
- image
- latent
- list
If DictBus is the packing side, the Dictionary Bus Unpack node is the arrival gate. It takes a DICT_BUS that was bundled up somewhere upstream and splits it back into its individual parts - dictionary, model, CLIP, VAE, image, latent, and list - so you can wire each one into whatever needs it next. It's the node you put at the end of a bus: the bus carried the state across your graph, and this is where it gets unloaded.
How it works
The bus is just a fixed-order tuple - dict, model, clip, vae, image, latent, list - and Unpack reverses the packing with almost no logic of its own. It takes the single dict_bus input and returns every element as its own output, in that same order. Anything that was left empty when the bus was created comes back as None, so an optional slot that was never filled just yields a dangling None output you can leave unwired.
The one output worth calling out separately is the bus output - the original, untouched DICT_BUS, passed through on the other side. That's your "keep the state flowing" outlet: you can unpack the bus into a branch of the graph, do something with the parts, and still forward the original bus to the next node that wants it. Combined with DictBusEdit for mid-flight changes, this is how you thread the same state through a whole workflow without ever pulling it apart for good.
When you'd reach for it
The pattern is simple: bundle at the start with DictBus, let the bus ride through the graph (maybe through a loader node that consumes it), then Unpack where the real work begins. It's also your escape hatch whenever a node can't take a bus - say you need just the model for a stock sampler, or just the dictionary for a DictTemplate. Unpack, grab the one thing, leave the rest.
It's the least opinionated node in the pack, which is the point. There's no configuration, no options, no surprise behavior - just a required dict_bus input and eight outputs.
Installing it
Same pack, same setup as its siblings:
cd ComfyUI/custom_nodes
git clone https://github.com/JEONG-JIWOO/ComfyUI_Eugene_Nodes
Restart ComfyUI (or ComfyUI Manager → "Eugene Nodes"). No pip dependencies, no model downloads.
Where people get burned
Two small traps. First, the output order matters: the outputs land in the fixed tuple order, so read them left to right as dict, model, clip, vae, image, latent, list - if you expect a different arrangement you'll wire things into the wrong places and get confusing type errors. Second, remember the bus is not magic: any component that was None in the bus is None here, so if a loader downstream asserts on model/CLIP/VAE and you fed a half-empty bus, you'll hit the "required" error at the unpacked end, not the packing end.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| dict_bus | DICT_BUS | — |
Outputs (8)
| Name | Type | Description |
|---|---|---|
| bus | DICT_BUS | — |
| dict | DICT | — |
| model | MODEL | — |
| clip | CLIP | — |
| vae | VAE | — |
| image | IMAGE | — |
| latent | LATENT | — |
| list | LIST | — |