Power Lora Plus

If you've ever applied the same three LoRAs to two different checkpoints in one workflow, you know the pain: you either duplicate the loader config and pray you remember to edit both, or you rebuild the stack by hand every time. Power Lora Plus is a LoRA stacker in the spirit of rgthree's Power Lora Loader, with one extra party trick - a lora_config output and input that lets a second loader mirror the first live. Edit the master, the follower greys out, copies your rows, and applies the exact same stack at generation time.

That "sync" feature is the entire reason to pick this over rgthree, which is otherwise the better-known node with the battle-tested record. rgthree's Power Lora Loader has been mentioned in hundreds of community threads and even reads trigger words off LoRA files; Power Lora Plus shows 0 impressions on comfy.icu and zero Reddit presence - it's a genuinely new, niche node. But none of the incumbents let you chain a LoRA stack from one loader to another, and if you run parallel model branches (an inpaint model next to your main checkpoint, say), that's exactly the case that bites.

How it works

The node is a thin wrapper around ComfyUI's own LoraLoader. Feed it a model and clip, and it resolves each row against the files in your loras/ folder (exact match, then case-insensitive, then bare basename - so realism.safetensors finds a file buried in ideogram/), then calls load_lora in row order. Only enabled rows with at least one non-zero strength get applied, and the clip strength falls back to the model strength unless you've set it separately.

The clever part is the lora_config string. It's a small JSON blob holding your whole stack - mode plus a list of {on, lora, strength, strengthTwo} rows - and it flows both out and in. When a follower's lora_config input is wired, that input wins over the follower's own saved rows, and because the output always reflects whatever was actually applied, you can pass it down a chain of loaders. Disconnect the wire and the follower goes back to its own saved config.

The inputs that matter

Everything is optional, which is worth knowing: the node happily works as a pure config pipeline with no model attached.

• model / clip - the model and text encoder to apply LoRAs to. Leave them unconnected and you get a valid lora_config out but nothing applied.
• lora_config (STRING) - wire another Power Lora Plus's output here to sync. This is the input that makes the node special.
• loras_data - a hidden STRING widget holding the JSON stack; you edit it through the on-node row editor, not by hand.

Outputs: MODEL and CLIP (the patched versions, wired into your sampler), plus lora_config (STRING/JSON) for the sync trick. The row editor itself gives you add/remove rows, a per-row enable toggle, and a folder-grouped search picker on the LoRA field. One strength or two (model/clip) is a per-node toggle; in Separate mode the left number is the model strength and the right is the clip strength.

Installing

Clone into custom_nodes and restart - there's no requirements.txt and no heavy download, because it leans on ComfyUI's built-in LoraLoader:

cd ComfyUI/custom_nodes
git clone https://github.com/quzopl/comfyui-power-lora-plus.git

Then restart ComfyUI and the node appears under loaders. It's also on ComfyUI Manager if you search "Power Lora Plus".

Where people get burned

The pitfalls here are the ones every LoRA node shares, not anything pack specific. The name-matching is forgiving but not magic - if the file genuinely isn't in your loras/ folder, the row is silently skipped, so a missing LoRA won't error, it'll just quietly not apply. And per the standard LoRA troubleshooting checklist: check the base model matches your LoRA's architecture, add the trigger word, and keep weights in the 0.5–0.8 range before you blame the node. The author (Bart) also ships Ideogram bbox tooling, so if you found this via an Ideogram workflow, the model/clip split and the sync are still the parts worth keeping.