LoRA Stack (LoRA Control)

This is the boring one, and I mean that as a compliment. Six slots, each with a LoRA dropdown, an on/off toggle and a strength. No magic. It's the node you use when you already know which LoRAs you want and just don't want eight Load LoRA nodes strung across the canvas.

It's also the node that makes the rest of the pack usable: the pickers bolt onto its output, and the whole thing gets applied once, downstream, by Apply LoRA Stack.

How it works

Each slot is on_N, lora_N, strength_N. A slot contributes to the output only if all three line up: on_N is true, lora_N isn't None, and strength_N isn't 0. Entries are appended in slot order, and if you wire something into the optional lora_stack input, that stack comes first and your six slots are added after it.

The output type is LORA_STACK - the same (name, model_strength, clip_strength) list that Comfyroll's and Efficiency's stack nodes emit, which is why the pack's nodes chain with each other in any order and with those packs too. Nothing is loaded here. It's a list, held as a list, until something applies it. That's what lets you mute a slot mid-session and get a different image without the model being re-read.

Because each row carries one strength that gets written to both the model and CLIP side, this node is closer to a row of core Load LoRA nodes than to LoraLoaderModelOnly. Worth knowing before you compare it against a hand-built chain and wonder why the images differ - they're not the same operation.

Six is a hard ceiling; chain two of these if you need more. And there's a real consequence to the order: the pack's docs say the patches are summed in bf16, so the same LoRAs in a different order produce a very slightly different image. Close enough to ignore while you're experimenting, not close enough to ignore when you're reproducing a render you liked.

enabled is the whole-node power switch: off passes the incoming stack through untouched, so you can A/B your entire LoRA setup without unlinking anything.

Inputs and outputs

• enabled - node-level bypass.
• on_1 … on_6, lora_1 … lora_6, strength_1 … strength_6 - the slots. Strengths run -10 to 10 in 0.01 steps, and negative values are legal and do something. That's a fiddling tool, not a first resort.
• lora_stack (optional) - chain another stack in front.

Outputs: lora_stack for Apply LoRA Stack (required there) or any other stack consumer, and loras, a string of what the stack contains, formatted like char-Alice:0.8, style-ink:1. Wire it to a PreviewAny the moment you start muting slots, because "which combination was this" gets hard fast.

One detail you'll notice in that string: a slot at strength 0 doesn't appear at all. Zero doesn't mute the row, it deletes it from the list. Same end result, but if you expected to see the LoRA listed at 0 while you tuned, you won't.

Install

# ComfyUI Manager: Custom Nodes Manager → search "LoRA Control"
comfy node install comfyui-lora-control
cd ComfyUI/custom_nodes && git clone https://github.com/nzkritik/comfyui-lora-control

Restart after installing. Zero Python dependencies - but it needs ComfyUI 0.3.48 or newer, since the pack is written against the V3 node API. It ships no models of its own.

Should you use this or Power Lora Loader?

If you want one node that stacks LoRAs and tells you the trigger words, rgthree's Power Lora Loader is the incumbent for good reason - it's the single most-named component in that pack, and its right-click info dialog pulls trained words and example images off CivitAI and keeps them locally. This node does none of that. What it gives you is a clean LORA_STACK you can hand around, toggle, randomise or chain, which Power Lora Loader doesn't produce.

Common issues

A LoRA you just added isn't in the dropdown. The combo is built from ComfyUI's LoRA file list when the node schema is defined, i.e. at startup, so a new file needs a node-definitions refresh or a restart. This is how every LoRA combo behaves, not something specific to this pack.

A slot does nothing. Check all three widgets: on_N, lora_N set to a real file rather than None, and a non-zero strength. The default on_1 = true with lora_1 = None is the most common non-event in the node.

Wrong-architecture LoRAs are all in the same list, with no warning. Picking a Pony LoRA on an SDXL model, or a Z-Image LoRA on anything else, gets you mismatched keys in the console and bad output rather than a clean refusal - troubleshooting.md's "LoRA not working" checklist is the right next stop, and the first item on it is base-model compatibility.

Stacking itself is the risk on newer models. Multi-LoRA stacking on Z-Image Turbo has a reputation for quality collapse, and some LoRAs need a strength above 1.0 when a Base-trained adapter runs on Turbo. Start at 0.7 and go up - the 1.0 default is a starting point, not a recommendation.