LoRA Loader From Weight 🍌

This is the second half of cgem156's split LoRA-loading pattern. LoraLoaderWeightOnly (or LoraMerger) defines which LoRA and how strong - this node is what actually takes that definition and patches it onto a real model. If you only ever use one LoRA at default settings, you'd never need this two-step dance; it exists for workflows that build a LoRA definition once and then apply, merge, or reuse it more than once.

How it fits the pack

The pattern across cgem156's lora_merger nodes is consistent: nodes that produce a LoRA object (LoraLoaderWeightOnly, LoraMerger) are decoupled from the one node that consumes it and actually touches a MODEL. That's this node. It's the equivalent of the "apply" step in a build-then-apply pipeline, and it's what makes merging two LoRAs together (via LoraMerger) actually useful - you build the combined LoRA once, then apply it here.

Inputs and outputs that matter

• lora - a LoRA object, from LoraLoaderWeightOnly or LoraMerger, not a raw file picker.
• model - the model to patch.
• clip_optional - optional CLIP input; supply it if you also want the LoRA's text-encoder weights applied, leave it out if you only care about the UNet side.
• Outputs: MODEL and CLIP, patched and ready to wire into your sampler and text encoder respectively - same shape as the stock LoraLoader node's outputs.

Installing it

ComfyUI Manager → search cgem156-ComfyUI🍌 → install → restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/laksjdjf/cgem156-ComfyUI

then restart ComfyUI. Nothing extra required for this node.

Common issues & troubleshooting

Confusing this with the standard LoRA loader. If you just want "load one LoRA onto one model" with no merging or reuse, the built-in LoraLoader is simpler and does it in a single node. Reach for this one specifically when a LoraLoaderWeightOnly/LoraMerger object is already sitting upstream in your graph.

No lora input available to connect. This node only accepts the pack's own LoRA type - it won't take a filename string or the output of the standard loader. You need LoraLoaderWeightOnly or LoraMerger upstream first.

CLIP output looks unchanged. If you didn't connect anything to clip_optional, the CLIP output likely passes through without the LoRA's text-encoder weights applied - connect your CLIP model to that input if you want the full effect on both halves, not just the UNet.

Architecture mismatch between LoRA and model. Same rule as any LoRA anywhere: it has to match the base model family it was trained for. This node won't catch that for you - a mismatched LoRA typically just does nothing useful or produces garbage rather than erroring cleanly.