Load LoRA for CLIP Only

Here's the catch with the whole remote-CLIP idea: ComfyUI's standard LoRA Loader doesn't work against it. LoRA weights that patch the text encoder are applied inside the encoder, and when your encoder lives on another machine, patching it from the Loader is impossible. So this pack ships its own LoRA loader - and once you've got the two halves talking, it's probably the node you'll touch most.

What it does

LoraLoaderCLIPOnly is a CLIP-only LoRA loader that happens to be remote-aware. Give it a CLIP, pick a LoRA, set a strength, and it hands back a patched CLIP. Nothing fancy so far. The difference shows up when the CLIP you feed it is a remote proxy: instead of patching locally, it forwards the LoRA name and strength to the Sender, which applies them to the actual model. Same result, different place.

That also means it works as a plain local loader. If the CLIP isn't remote, it patches in place like a normal node - one node that behaves correctly either way, depending on what you wire into it.

Where to put it

Two placements, both valid:

• On the Sender, between the Checkpoint or CLIP Loader and the Send Remote CLIP node. The LoRA gets baked in before the encoder starts serving.
• On the Loader, right after Load Remote CLIP. The node detects the remote connection and forwards the patch to the Sender.

The forward-from-the-Loader version is the slicker workflow - you can swap LoRAs without ever touching the sender's graph. But there's a trap: the LoRA file must exist in the Sender's loras folder. The Loader only sends the name and strength, not the weights, so a file that's only on your main machine fails with a "LoRA not found on worker" error.

You can also stack multiple LoraLoaderCLIPOnly nodes and they accumulate - each one adds to the stack the Sender applies, and the Sender's patched-CLIP cache means the whole stack is patched once and reused rather than re-applied per prompt.

Inputs and output

Just three inputs, all required:

• CLIP - the remote (or local) model to patch.
• lora_name - picked from the LoRA list.
• strength_clip - float, default 1.0, range −10 to 10. Negative strengths invert the LoRA's effect on text conditioning; 0 is a clean passthrough.

The single output is the patched CLIP, ready for conditioning or another LoRA node.

The other LoRAs

One thing to keep straight: this node only touches the text side. A LoRA that should affect only image generation (the UNet) doesn't need the remote setup at all - use the standard LoraLoaderModelOnly on the Loader as usual. LoraLoaderCLIPOnly is strictly for weights that change how your prompt is understood.