Apply LoRA Stack (LoRA Control)

The other three nodes in this pack are shopping lists. Apply LoRA Stack is the one that goes to the shop. Everything upstream - the six-slot stack, the name picker, the folder picker - just builds a list of LoRA filenames and strengths. Nothing is read off disk, nothing touches your model, until this node runs.

That separation is the whole point of the pack, and it's why this is the node you'd reach for even if you already use the stack inside your LoRA loader of choice. You pick LoRAs on one side of the graph, apply them once on the other, and in between you can mute, chain, randomise and reorder without ever rewiring the sampler.

How it works

It walks your stack in order, first to last, and for each entry calls ComfyUI's own comfy.sd.load_lora_for_models - the same function core's Load LoRA node calls. Each row in the stack is a (name, model_strength, clip_strength) triple, and this pack always writes the same value into both, so a stack row has one strength, not two.

The CLIP side is the bit worth understanding. Connect something to clip and the LoRA's text-encoder half gets applied too, at that same strength. Leave clip unconnected and the node passes a clip strength of 0, which makes it behave like core's LoraLoaderModelOnly. That's the author's own framing in the node description - "leave CLIP unconnected for model-only LoRAs" - and it's the right call for LoRAs trained without a text encoder, which is most of them since Flux. It's also where confusion lives: people rebuild a stack as a row of LoraLoaderModelOnly nodes, get different images, and conclude stacking is broken. It isn't. You're just not running the same thing any more.

Weights are loaded through comfy.utils.load_torch_file with safe_load=True and kept in a small in-process cache keyed by file path, pruned after every run down to only what the stack actually used. So a repeat run doesn't re-read a 200MB file off disk, and a long session doesn't slowly hoover up every LoRA you've ever tried.

One honest caveat from the pack's own docs: because the patches get summed in bf16, stack order changes the image slightly. Same LoRAs, same seed, different order - close, not pixel-identical. If you're chasing reproducibility, freeze the order.

Inputs and outputs

• model (required) - your checkpoint or UNET, straight from the loader.
• lora_stack (required, LORA_STACK) - the output of any LoRA Control node, or of Comfyroll/Efficiency stack nodes, since the type is shared.
• clip (optional) - wire it in to apply the CLIP half, leave it out for model-only.

Outputs are model, clip, and loras. The first two go where the base loader's outputs used to go - every sampler, ControlNet and upscaler downstream now sees the patched model, so this node has to sit before them, not beside them. loras is a plain string listing what got applied, formatted like char-Alice:0.8, style-ink:1; the pack's own template wires it into PreviewAny, which is the sane way to keep tabs on a random pick. You can also feed it into a text node for a filename prefix.

Install

The pack is on the Comfy Registry, so any of these work:

# ComfyUI Manager: Custom Nodes Manager → search "LoRA Control"

# or the CLI
comfy node install comfyui-lora-control

# or by hand
cd ComfyUI/custom_nodes
git clone https://github.com/nzkritik/comfyui-lora-control

Restart ComfyUI after. There are no Python dependencies - pyproject.toml lists an empty dependencies array - but it needs ComfyUI 0.3.48 or newer, because it's written against the V3 node API (comfy_api.latest). On an older build the pack loads and the nodes simply don't exist. The pack ships no models; the Z-Image Turbo example workflow it comes with points at z_image_turbo_bf16, qwen_3_4b and ae from Comfy-Org's repo.

Where people get burned

The classic one is stale-model debugging: if you're carrying your model around in a context/pipe bundle from a pack like rgthree, it's easy to unpack a copy that was captured before this node ran and silently sample the base weights. Explicit wires here, and check that the sampler's model input traces back to this node.

Second: the LoRA list in the stack dropdown is every file in models/loras, cross-architecture included. An SDXL LoRA picked on a Z-Image run won't error politely - you get mismatched keys in the console and ugly output. Third: this pack is new and single-author with essentially no Reddit footprint yet, so there's no pile of community bug reports to lean on; if the loras string says it applied a LoRA and the image says otherwise, check the console log line this node prints per LoRA (LoRA Control: applied …) before you blame the sampler.