EmAySee Lora Stacker (20 Sequential)

The "I use more than one LoRA" node

Most stacked-LoRA workflows in ComfyUI are a literal chain: LoraLoader → LoraLoader → LoraLoader, three nodes in a row with the strengths buried in each. EmAySee_LoraStacker20 collapses that into one node with twenty LORA_OBJECT slots, each with its own strength_model and strength_clip, applied in a fixed order - slot 1 first, slot 20 last. It takes a model and clip in and hands back the fully-patched pair.

Stacking is standard practice - character + style + detail adapters on top of a base - and the LoRA world has firm opinions on it: LoRAs are architecture-bound (an SDXL adapter does nothing on Flux), and the old 0.5–0.8 strength rule is SDXL-era advice, not a law. What this node adds is a single place to see the whole roster and its weights at once, plus an application order that's explicit rather than emergent from your wiring. That order matters: later slots patch the output of earlier ones, so slot 1 is "base" and slot 20 is "final touch."

How it works

It walks slots 1 through 20, and for each one that has a connected LORA_OBJECT (and non-zero strengths), applies it to the running model/clip with comfy.sd.load_lora_for_models, threading the result into the next slot. Empty slots and 0/0-strength slots are skipped entirely, so a two-LoRA setup works fine in a node that nominally holds twenty.

Inputs

• model (MODEL), clip (CLIP) - the base to patch, threaded through all 20 slots.
• strength_model_1/strength_clip_1 … strength_model_20/strength_clip_20 (FLOAT, −10 to 10, default 1.0) - per-slot strengths.
• lora_1 … lora_20 (LORA_OBJECT, all optional) - the adapters from EmAySee_LoraNameSelector.

Outputs: MODEL and CLIP.

Install

From ComfyUI_EmAySee_CustomNodes:

cd ComfyUI/custom_nodes
git clone https://github.com/EmAySee/ComfyUI_EmAySee_CustomNodes
# restart ComfyUI

Or via ComfyUI Manager → "ComfyUI_EmAySee_CustomNodes". No extra dependencies.

Gotchas

The honest take: twenty slots is overspec'd for almost everyone, and the node is visually enormous because every slot ships with its own pair of strength sliders - most stacks are 3–5 LoRAs, so you'll be scrolling past a lot of empty boxes. That's the trade for having everything in one node. The subtler trap is negative strengths: the range goes down to −10 for a reason (some workflows use negative LoRAs to subtract a style), but if you see a stack "not working," check whether a slot you forgot about is applying a negative weight. And since it's the object pipeline, feed it LORA_OBJECTs from LoraNameSelector - string names and LORA-typed outputs won't connect.