Dictionary Bus
Stuff Your Whole Workflow State Into One Wire
- dict
- model
- clip
- vae
- image
- latent
- list
- DICT_BUS
Once your workflow passes a certain size, the spaghetti of wires becomes the problem. The Dictionary Bus node is Eugene's answer: take the things nearly every graph passes around - a dictionary, the model, the CLIP, the VAE, and optionally an image, latent, or list - and bundle them into a single DICT_BUS connection. One wire carries the state, and the Unpack or Edit node on the far side pulls it apart. It's the same "Context node" philosophy rgthree made famous, just aimed at this pack's dict-based way of working.
How it works
Mechanically it's almost embarrassingly simple: the node sticks its inputs into a Python tuple in a fixed order - dict, model, clip, vae, image, latent, list - and hands that tuple down one wire. Nothing gets loaded, merged, or transformed. The magic is purely organizational: instead of four or seven parallel wires threading across your graph, you get one, and you can reroute it through other nodes (like the loader nodes, which accept a dict_bus input) before it reaches its destination.
The inputs mirror the tuple: dict, model, clip, and vae are required; image, latent, and list are optional. Leave an optional slot empty and it travels as None - the Unpack node hands you back a None that you can either ignore or replace with DictBusEdit.
Why you'd actually use it
Honestly, for a two-node test graph this is overkill - you don't need a bus to carry a model across one screen. Where it earns its keep:
- Loader plumbing. Both LoRA loader nodes accept a
dict_bus, so you can build one bus containing your dictionary and your model/CLIP/VAE, feed it to the loader, and get the whole processed stack back. That's a huge wiring reduction when the same stack feeds multiple branches. - Cleaner branches. When a big workflow forks - sampler here, upscaler there - the bus lets you pass the full state to each branch and let each one edit what it needs without duplicating wires.
Installing it
Same pack as the rest of the Eugene nodes, zero extra dependencies:
cd ComfyUI/custom_nodes
git clone https://github.com/JEONG-JIWOO/ComfyUI_Eugene_Nodes
Restart ComfyUI, or install from ComfyUI Manager (search "Eugene Nodes").
Where people get burned
The classic mistake is expecting the bus to be lazy. All four required inputs must be connected - dict, model, clip, and vae - because the tuple is built in a fixed order and the pack's loader nodes assert all three model components exist when they unpack one. If you only need to ferry a model, this is the wrong tool; it's built for the full stack.
Also worth knowing: DICT_BUS is a pack-specific type. A bus output only connects to other nodes that declare DICT_BUS inputs (the unpack, edit, and loader nodes in this same pack). That's the whole point, but it does mean a bus wire can't be unplugged into stock ComfyUI nodes.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| dict | DICT | — | |
| model | MODEL | — | |
| clip | CLIP | — | |
| vae | VAE | — | |
| imageopt | IMAGE | — | |
| latentopt | LATENT | — | |
| listopt | LIST | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| DICT_BUS | DICT_BUS | — |