Merge LoRA Clip
When you'd rather bake than hook
- clip
- lora_bridge
- CLIP
The name is honest: this node takes the LoRA sitting in a LORA_BRIDGE bundle and permanently merges it into your CLIP - the text encoder - at a fixed strength. No runtime toggling, no keyframes, no switching it off later. It's the "old-school" way of applying a LoRA, and for a lot of setups it's still the right one.
Why would you bake instead of hook? Because a baked merge is done once, at graph execution, and then the sampler just runs. There's nothing to evaluate mid-sampling, no hook machinery to keep alive, and the result is identical every time you hit queue. If you have a LoRA you always want at the same strength - your go-to style LoRA at 0.7, say - you don't need the flexibility of PG Nodes' hooks system. You need this: wire it, set the strength, forget it. The main thing you give up is being able to change the strength per-run from a single knob that also drives the UNet path (that's what the hooks nodes are for).
How it works
The node is a thin wrapper around ComfyUI's own comfy_sd.load_lora_for_models(), called with the model side nulled out and your CLIP plus the bridge's LoRA object on the clip side. That's the same code path core ComfyUI's LoraLoader uses, so you're not getting some exotic apply - you're getting the stock merge, just scoped to the text encoder.
It reads the LoRA from a LORA_BRIDGE, not from a file. That's the interesting bit and the thing that trips people up: PG Nodes' LoRA Bridge Loader loads up to four LoRAs once and hands you one bundle object, and every merge/hook node in the pack picks a slot out of it. There's no lora_name dropdown here - you choose a slot (which_lora: lora_1 through lora_4) and the bridge holds the actual weights.
Inputs that matter
clip- your CLIP, straight from your checkpoint loader (or the Unified Loader).lora_bridge- the bundle from aLoRA Bridge Loader. If you don't have one, you'll be staring at an unconnected input and nothing else in the pack will make sense either.which_lora- which of the four bridge slots to merge. Defaults tolora_1.strength_clip- the merge strength, range -100 to 100 with 0.01 steps. The default of 1.0 is full strength; 0.5–0.8 is the usual band for style LoRAs, and negatives invert the LoRA's influence.
The single output is CLIP, wired downstream to your CLIPTextEncode. Set strength_clip to 0 and the node just passes your CLIP through untouched - handy for A/B comparisons without deleting wires.
Install
Part of the PG Nodes pack: ComfyUI Manager → search "PG Nodes" → install → restart. Manual:
cd ComfyUI/custom_nodes
git clone https://github.com/GizmoR13/PG-Nodes
No extra pip dependencies and no model downloads - it reads from the loras and checkpoints folders you already have. Drop a new LoRA file in and you'll need a ComfyUI restart for it to appear in the Bridge Loader's dropdowns, which are built at startup.
Common issues
The classic mistake is forgetting the bridge entirely and hunting for a lora_name input that doesn't exist. If the merge seems to do nothing, check the slot: which_lora defaults to lora_1, so if your file is loaded in slot 2 or 3 the node is happily merging an empty slot (the code swallows errors and prints [PgMergeLoraClipOnly] apply error to the console). Also remember this is destructive - if you later want to try the same LoRA as a non-destructive hook, don't stack both on one path, or you'll get the LoRA twice.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| clip | CLIP | — | |
| lora_bridge | LORA_BRIDGE | — | |
| which_lora | COMBO | lora_1 | 4 options: lora_1, lora_2, lora_3, lora_4 |
| strength_clip | FLOAT | 1.00-100–100 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| CLIP | CLIP | — |