Load LoRA (StackInput)

"StackInput" reads like it takes a stack out. It doesn't. This is the node that consumes one: you feed it a normal model and CLIP, plus the LORA_STACK output from a LoRA Stack Container, and it hands back a patched model and clip with every LoRA in that stack applied in order.

It has no widgets - nothing to set here at all. The choices live upstream in the container and this is the application step; paired with LoraStackContainer5 it replaces a ladder of five core LoraLoader nodes, and toggling a LoRA becomes a checkbox instead of a re-wire.

How it works

Two required inputs and one optional:

• model (MODEL) - your checkpoint, from CheckpointLoaderSimple or wherever.
• clip (CLIP) - required, not optional. There's no model-only variant in this pack.
• lora_stack (LORA_STACK, optional) - the list from a container.

Outputs are model and clip, both patched. Wire model into the KSampler and clip into your CLIPTextEncode nodes. Feeding both outputs from here rather than from the checkpoint is what makes the LoRA reach the text encoder too - otherwise your prompt conditioning runs on un-adapted CLIP and the trigger tokens don't mean what they should.

Mechanically it's what core does, in a loop: for each (name, strength_model, strength_clip) entry it loads the file with comfy.utils.load_torch_file(..., safe_load=True) and applies it with comfy.sd.load_lora_for_models, feeding the result of one into the next. Entry order is real order - the upstream container's entries first, then slots 1 through 5. If a stack gives you black frames or NaNs, reordering means shuffling which slot each LoRA sits in.

Leave lora_stack unconnected and the node is a pass-through: model and clip out unchanged. No error, no warning. That's a handy way to wire a graph before deciding on LoRAs, and a great way to spend twenty minutes wondering why your LoRA does nothing.

The clip strength dial is your only "model only" option

Because the clip input is required and the same tuple carries both weights, you can't load a LoRA onto the model while leaving the text encoder untouched - unless you set slotN_strength_clip to 0.0. Do that and the LoRA still patches the model; the CLIP side gets nothing. That's as close as this pack gets to core's LoraLoaderModelOnly, and it's worth doing on LoRAs whose trigger tokens you already have in the prompt.

Install

ComfyUI Manager → Lora Stack Pack / ComfyUI_lora_stack_pack, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/makszlak/ComfyUI_lora_stack_pack

There is nothing else to install: no requirements.txt, an empty dependency list in pyproject.toml, no model files. Both this node and the container appear under loaders/lora_stack, the same menu as core's Load LoRA.

The pack's own example workflow (examples/workflow_basic.json) wires it the obvious way: CheckpointLoaderSimple → this node, then model to the sampler and clip to the text encodes.

Common issues

A stack entry for a missing file doesn't crash - it disappears. If a LoRA in the stack can't be resolved on disk, the node prints [LoraStackPack] LoRA not found, skipping to the console and applies the rest. Same if the container handed it a name that no longer exists after you reorganised your loras folder. So when a LoRA in the stack has visibly no effect, read the ComfyUI console before you touch the weights.

It reloads every LoRA from disk on every run. There's no LoRA cache in this pack; each queue reads and applies all N files again. On a five-LoRA stack of 200 MB files that's real disk churn, visible as a pause before sampling starts. Nothing is wrong.

The wrong architecture is a silent no-op. An SDXL-lineage LoRA on a Flux checkpoint produces a normal-looking image with none of the LoRA in it and no error anywhere. If a stack does nothing at all, check base-model compatibility before rebuilding the graph.

Quantized checkpoints are slower to patch. On GGUF checkpoints each layer has to be dequantized, patched, and requantized as the stack applies, so a five-LoRA stack there costs noticeably more than on a full-precision checkpoint. Budget for it rather than hunting a bug.

Stacked LoRAs and the wrong strengths are two separate problems. Too-high weight - the old 0.5–0.8 advice still holds on a lot of SDXL-era files, while newer bases often want 1.0 and up - looks like "the LoRA is fighting my prompt", not like an error. Change one LoRA weight at a time on a fixed seed, or you'll never learn which one did it.