LZ LoRA Stacker (Model Only)

What it is, and when you'd actually want it

Core ComfyUI gives you LoraLoaderModelOnly, which applies exactly one LoRA to a model and nothing else. This node is that idea with a lora_count dial and up to ten slots, plus the LZ pack's pipe plumbing bolted on.

The "Model Only" in the name is the important part. A normal LoRA loader takes both MODEL and CLIP, and patches both - the model weights and the text encoder, so your LoRA's trigger words get their own nudged embeddings. This one takes a MODEL, patches it, and deliberately leaves the text encoder alone. If you're on a Flux-family or DiT workflow where the text encoder is a completely separate file (Krea 2's Qwen3-VL, Anima's own encoder), that's exactly what you want: those diffusion-model LoRAs have no text-encoder keys to land on anyway, so running them through a CLIP pass is wasted work at best and confusing log output at worst. Same story if you just want to stack a style LoRA and a character LoRA without touching how your prompt encodes.

If you do want the CLIP side, the pack's sibling LZLoRAStacker has separate model_weight_i and clip_weight_i per slot and outputs a CLIP too. Pick based on that, not vibes.

How it works

You set lora_count (1–10), and the node's JavaScript hides the slots above that number so the node doesn't sit there ten rows tall. Each visible slot gets a lora_N dropdown, populated straight from your models/loras folder, and a strength_model_N float defaulting to 1.0.

Under the hood it walks the active slots and, for each one, skips it if the dropdown is None, skips it if the strength is exactly 0, and skips it silently if the file isn't on disk anymore. Everything else is applied with ComfyUI's own load_lora_for_models(model, None, lora, strength, 0) - note the None where the CLIP would go. That's the whole trick: no custom math, just the core loading path in a loop.

Two details worth knowing. LoRA weight files are cached per node instance, LRU-capped at 32 files, so re-running the same stack doesn't re-read from disk each queue. And the stacker appends to whatever the incoming pipe already carries, so two stackers in series accumulate rather than replace.

The inputs that matter

• lora_count - the only required input. Whatever number you pick is how many rows you see.
• model or lz_pipe - supply one. The node reads lz_pipe["model"] if the direct input isn't connected, and throws a plain MODEL must be connected directly or provided via lz_pipe error if it has neither.
• lora_N / strength_model_N - the slots themselves. Negative strengths are allowed (down to −10), which subtracts a LoRA's effect; fun, occasionally useful, easy to make ugly.

Outputs are MODEL (the patched model, wire it into your sampler), lz_pipe (updated with the new model and the LoRA list), and two strings: lora_model and lora_weight, comma-joined names and strengths, e.g. style_b.safetensors, char_a.safetensors / 0.7, 0.9. Those strings feed LZPipePack's lora_model/lora_weight inputs and LZSaveImageAndLog, which is how this ends up in your .txt logs. One quirk: the recorded clip weight is copied from the model strength even though no CLIP was touched, so a log line saying 1.0 there is bookkeeping, not evidence.

Install

It ships in ComfyUI-LZNodes. Manager users: search ComfyUI-LZNodes (publisher liz-ils) and install. Manual:

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

No model downloads, no pip heavies - the pack has no requirements.txt, only a pyproject.toml asking for Python ≥ 3.10, and the loader code paths are all ComfyUI built-ins. After restart the node is under MyCustomNodes/Loaders.

Where people get burned

Silent skips. A LoRA you renamed, moved, or deleted stops applying with no error - you get a clean render minus the LoRA. Same for a strength of exactly 0. If a stack "isn't doing anything," check the lora_model output string first; if the name isn't in there, the node never applied it.

Wrong architecture. An SDXL LoRA on a Flux model is a no-op, and this node won't complain about it. Check the LoRA's model page for what it targets; that's the single most common "my LoRA does nothing" cause.

Stacking isn't additive. Two LoRAs at 0.8 don't behave like one at 1.6, and order changes the result - people commonly reorder stacks (larger files earlier) when something goes muddy. On the SDXL lineage, 0.5–0.8 is still the sane starting range; on newer bases like Z-Image, character LoKRs are often run at 1.0 and above because dropping below costs likeness. Don't import one era's defaults into the other.

Frontend widget weirdness. The slot hiding is done by the pack's js/dynamic_lora.js. If it doesn't load on your frontend, you'll just see all ten rows - annoying, not broken. Anything you typed into a hidden slot still gets read.