h4 - Oxidine
One cable for all your traffic
- input_1
- input_2
- input_3
- input_4
- input_5
- input_6
- input_7
- input_8
- input_9
- input_10
- input_11
- input_12
- input_13
- input_14
- input_15
- input_16
- input_17
- input_18
- input_19
- input_20
- input_21
- input_22
- input_23
- input_24
- input_25
- input_26
- input_27
- input_28
- input_29
- input_30
- input_31
- input_32
- input_33
- input_34
- input_35
- input_36
- input_37
- input_38
- input_39
- input_40
- input_41
- input_42
- input_43
- input_44
- input_45
- input_46
- input_47
- input_48
- input_49
- input_50
- output
Every serious ComfyUI graph eventually becomes spaghetti. Model here, VAE there, a CLIP sneaking around the back - forty wires crisscrossing the canvas until you can't tell what feeds what. h4_Live's answer is Oxidine, an "omniproxy" that bundles a pile of connections into a single cable and hands each consumer the right payload when it asks. The README calls it the ultimate wire-declutter tool, and for once the marketing isn't entirely wrong.
How it works
Oxidine accepts up to 50 any-type inputs (input_1 through input_50) and exposes one any-type output. The magic is in how it handles what flows through: instead of forcing you to pick a type, it figures out what each object is and routes accordingly. Feed it a VAE, and when the downstream node calls for a VAE's operations it gets them. Feed it a MODEL and a CLIP on different inputs, and the same single output line serves both - the proxy dispatches by attribute, so decode routes to the VAE, tokenize/encode routes to the CLIP, and patch_model routes to the MODEL.
The backend has a deliberate design constraint worth respecting: the proxy deliberately does not subclass the core types (list, dict, ModelPatcher, VAE, CLIP). That's not an accident - it's what stops ComfyUI's executor from treating it as a list and mapping over it, which is exactly the kind of type chaos that turns a CLIP into a VAE and produces those wonderful "what is wrong with this graph" errors.
What you actually set
No required inputs, no widgets to configure. You wire things in, it routes them out. The inputs are dynamic and any-type, so there's genuinely nothing to configure - which is the whole point. It's a routing valve, not a settings panel.
When to reach for it
The honest answer: when your canvas looks like a plate of noodles and you want one clean trunk line. It shines in workflows where several branches converge on one consumer - for example, when you're building a reusable subgraph and want to hide the plumbing. The trade-off is legibility in a different direction: a node that carries "everything" makes it harder to see what flows where, so it's a decluttering tool for the canvas, not for your understanding. Keep it for graphs you already understand.
Installing it
It's part of h4_Live:
cd ComfyUI/custom_nodes
git clone https://github.com/m3rr/h4_Live
# restart ComfyUI
or ComfyUI Manager → search "h4_Live." No extra dependencies.
Where it can bite you
Any-type routing is powerful and slightly cursed. If you connect something exotic that the proxy's type detection doesn't recognize, it falls back to a passthrough - usually fine, sometimes not. And because the single output is typed *, ComfyUI's type-checking is doing a lot of trusting; when a downstream node chokes, the error message can be bafflingly generic. Debugging a mis-wired Oxidine is harder than debugging the equivalent direct wires, so don't reach for it until the graph works un-bundled. When you do, it's genuinely the least-spaghetti way to carry a model triple across a big canvas.
Inputs (50)
| Name | Type | Default | Description |
|---|---|---|---|
| input_1opt | * | — | |
| input_2opt | * | — | |
| input_3opt | * | — | |
| input_4opt | * | — | |
| input_5opt | * | — | |
| input_6opt | * | — | |
| input_7opt | * | — | |
| input_8opt | * | — | |
| input_9opt | * | — | |
| input_10opt | * | — | |
| input_11opt | * | — | |
| input_12opt | * | — | |
| input_13opt | * | — | |
| input_14opt | * | — | |
| input_15opt | * | — | |
| input_16opt | * | — | |
| input_17opt | * | — | |
| input_18opt | * | — | |
| input_19opt | * | — | |
| input_20opt | * | — | |
| input_21opt | * | — | |
| input_22opt | * | — | |
| input_23opt | * | — | |
| input_24opt | * | — | |
| input_25opt | * | — | |
| input_26opt | * | — | |
| input_27opt | * | — | |
| input_28opt | * | — | |
| input_29opt | * | — | |
| input_30opt | * | — | |
| input_31opt | * | — | |
| input_32opt | * | — | |
| input_33opt | * | — | |
| input_34opt | * | — | |
| input_35opt | * | — | |
| input_36opt | * | — | |
| input_37opt | * | — | |
| input_38opt | * | — | |
| input_39opt | * | — | |
| input_40opt | * | — | |
| input_41opt | * | — | |
| input_42opt | * | — | |
| input_43opt | * | — | |
| input_44opt | * | — | |
| input_45opt | * | — | |
| input_46opt | * | — | |
| input_47opt | * | — | |
| input_48opt | * | — | |
| input_49opt | * | — | |
| input_50opt | * | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| output | * | — |