Power Lora Stacker

Power Lora Stacker is the sibling of this pack's Power Lora Loader, and the difference is where the work happens. The Loader applies LoRAs to your model and CLIP on the spot. The Stacker doesn't touch a model at all - it collects your LoRA choices into a tidy list and hands it off as a LORA_STACK output, so some other node decides what to do with it.

How it works

The node looks almost identical to the Loader on the surface: you add entries, toggle them on and off, set a single strength or split it into model/clip halves, drag to reorder. But its only socket is an optional lora_stack input, and its single output is lora_stack. What comes out is a plain Python list in the format that stack-based workflows have standardized on:

[("lora_name.safetensors", model_strength, clip_strength), ...]

Only enabled entries make it into the list, and each entry gets converted to a float strength. If everything is off and there's nothing to send, the node returns None rather than an empty list - that's ComfyUI convention, and consumers are expected to handle it. The one genuinely clever part: if you wire an existing LORA_STACK into the input, it gets prepended to whatever you build here. That's how you compose stacks across nodes - build a style stack here, a character stack there, and merge them downstream.

Loader vs Stacker - which one?

If you just want to put three LoRAs on an SDXL checkpoint and render, use the Loader. It's fewer nodes and the model gets the patches applied immediately.

The Stacker earns its keep in two situations. First, when the consuming node is designed for stacks - the pack's README calls out Efficiency Nodes and other stack-based workflows, and anything that accepts a LORA_STACK type. Second, when you want to reuse the same LoRA lineup across several model paths. One Stacker can feed a whole row of loaders, so you change a strength once instead of three times.

One thing the README gets slightly wrong: it describes the Loader as accepting an optional lora_stack input too, but the shipped code doesn't do that - only the Stacker has the stack input, and only the Loader actually applies anything. The two nodes are complementary, not interchangeable. If you want stacks to feed into a plain model, wire Stacker → a stack-aware loader; the stock LoraLoader won't eat a LORA_STACK directly.

Installing it

Same pack, same install:

cd ComfyUI/custom_nodes
git clone https://github.com/hayde0096/Comfyui-EasySettingpipes

Restart ComfyUI, or search "Easy Setting Pipes" in ComfyUI Manager. No extra dependencies, no model files to fetch - the Stacker is pure data plumbing. (Ignore the README's own clone command, which has a broken user-attachments URL; the repo is hayde0096/Comfyui-EasySettingpipes.)

Where people get burned

• The stack is just data. It doesn't carry the checkpoint, so a LORA_STACK on its own renders nothing. If you've built a stack and your workflow produces no image, check that something downstream is actually consuming it.
• Type mismatches on the wire. A stack from this node only connects to sockets typed LORA_STACK. Efficiency-style nodes use that type, but plenty of other loaders don't, and the wire simply won't land.
• Format drift. The (name, model_strength, clip_strength) triple is the community convention, but not every stack consumer reads all three fields. If strengths seem to be ignored, check the target node's docs rather than the stack.

It's a small, honest utility with one job. If your workflows never chain LoRA lineups or share them across model paths, you won't miss it - but when you do need it, it's the clean way to keep "what LoRAs am I using" separate from "where are they applied."