LZ LoRA Stacker

LoRA stacking in vanilla ComfyUI means chaining LoraLoader nodes end to end - fine for two, a drag for five, a crime against your graph for ten. LZ LoRA Stacker gives you ten slots, each with its own model weight and CLIP weight, all in one node. Pick your LoRAs, set the strengths, and one node applies them in order.

How it works

Each slot has three widgets: lora_1 … lora_10 (dropdowns populated from your models/loras folder), model_weight_N, and clip_weight_N. The node walks slots 1→10, skips anything set to "None" (and skips slots where both weights are 0), and applies each via ComfyUI's own load_lora_for_models(). Order matters - later slots apply on top of earlier ones, exactly like chaining vanilla loaders.

Two details make it nicer than hand-chaining:

• It accepts either a model + clip pair or an lz_pipe (or both, with direct sockets taking priority). So you can hang it straight off a checkpoint loader or splice it into a pipe chain, and it hands back an updated lz_pipe with the stacked lora_name and lora_strength recorded in it.
• Built-in caching. Loaded .safetensors weights are kept in memory keyed by file path, so re-running with the same stack skips re-reading the files. First run of a big stack pays the read cost; every run after that is faster. (It's per-node-instance state, so a brand-new copy of the node re-reads - no cross-node global cache.)

Outputs are MODEL, CLIP, and the updated lz_pipe. Both MODEL and CLIP come out because a LoRA usually patches both - that's why every slot has separate model and clip strengths, and why you can push a LoRA's CLIP weight to zero if it's a style-only patch that should leave text encoding alone.

The honest take on stacking many LoRAs

More is not automatically better. Stacking ten LoRAs at 1.0 usually fights - the pack knows this, hence per-slot weights. The realistic use is a handful of genre/style LoRAs at 0.4–0.8 each, or one big recipe you've tuned once and want to keep as a single node. And note this is the general LoRA stacker: if you're on Anima, its LoRA ecosystem works fine through this too, since load_lora_for_models is architecture-agnostic.

Installing it

cd ComfyUI/custom_nodes
git clone https://github.com/liz-ils/ComfyUI-LZNodes

restart, MyCustomNodes/Loaders. ComfyUI Manager: search ComfyUI-LZNodes. No extra dependencies - no requirements.txt in the pack.

Where people get burned

• Negative model weights are legal (range −10 to 10) - a negative model_weight inverts a LoRA's contribution, which is sometimes intentional (style suppression) and sometimes a paste error that ruins output. Check your signs.
• Zero-weight slots are skipped entirely, so a slot at model 0 / clip 0 is silently dead - that's by design, but it means you can't use 0 to "disable the CLIP half" of a LoRA; you need clip_weight 0 while model_weight stays nonzero.
• The stacker raises an error if neither model/clip nor lz_pipe provides a model - connect one or the other.
• A LoRA trained for SDXL won't patch Anima usefully (different architecture), and vice versa. This node won't stop you; it'll just produce garbage that looks like a successful run.

It's one of the better "condense the common workflow" nodes in this pack, and the one I'd reach for before the manual chain - especially once your recipe list exceeds three LoRAs.