Remote Dual CLIP Loader

SDXL runs two text encoders, and that's exactly where its conditioning budget goes: a CLIP-L for the short precise read, a CLIP-G for the rich description, and the final conditioning is the two stacked together. LTX-Video runs an even hungrier pair - T5-XXL plus Gemma-3-12B, where the Gemma alone is a ~22 GB fp16 monster that OOMs consumer cards. If you're offloading your text encoding to a second GPU, you need to offload both of them, together, as one unit. That's what RemoteDualCLIPLoader is: the remote equivalent of ComfyUI's built-in DualCLIPLoader.

You pick two models on the server and get one clip socket out. Everything downstream behaves exactly like a normal dual CLIP - which is the whole trick, because the rest of your graph doesn't need to know the encoding is happening over HTTP.

How it works

Under the hood the node is a wrapper around two single remote connections. It resolves both model names against the server's GET /v1/models list, wraps them in a RemoteDualCLIPConnection, and hands you a single CLIP object. Like the single loader, nothing actually encodes at load time - the connection is lazy, and the encode happens when a text-encode node fires, at which point your prompt goes over the wire and embeddings come back as base64 to be reassembled into CONDITIONING.

clip_skip is applied to both encoders at once, which is worth a moment of caution. On SDXL-class models the penultimate CLIP layer is already the default in both encoders, so setting clip_skip: 2 mostly restates what you have - the setting genuinely changes things on SD 1.x-derived anime models, not on SDXL. Don't expect a quality dial.

Inputs

• server_url - base URL of the Remote Text Encoder server (default http://localhost:8288).
• model_name_1 and model_name_2 - the two encoders. For SDXL that's CLIP-L first, CLIP-G second. For LTX-Video it's T5-XXL first, Gemma-3-12B second. The order matters; the downstream encode nodes assume it.
• clip_skip - applied to both, 1–12, default 1.
• timeout - HTTP timeout in seconds, default 60.
• api_key - only if your server requires auth.

Note there's no custom_model override on this node (the single loader has one) - you pick from the dropdown, so if a model isn't showing up, refresh the model list first.

What the output feeds

The single clip output wires into three different consumers depending on the model family:

• CLIPTextEncodeRemote - encodes the same text with both models. That's the SDXL default behavior.
• CLIPTextEncodeCoupleRemote - SDXL with different text per encoder: a short precise string for CLIP-L, a longer richer one for CLIP-G. This is the one most SDXL people end up on.
• LTXVTextEncodeRemote - the LTX-Video pair, sending T5-XXL and Gemma in a single request.

The node's own docstring also notes it works with any standard ComfyUI CLIPTextEncode, since the connection quacks like a CLIP. Same install story as the rest of the pack: clone https://github.com/rwfsmith/ComfyUI-RemoteTextEncoder into custom_nodes, pip install -r requirements.txt (requests + numpy only on the ComfyUI side), point rte_config.json at the server, restart. Manager users can search ComfyUI-RemoteTextEncoder.

When it's worth it

Two situations, really. You have a second GPU with the VRAM to hold a couple of encoders and want your sampling card free, or you're running LTX-Video on a card where loading Gemma-3-12B locally is the thing making everything OOM. That second one is the strongest argument for this whole pack - the LTX community spent months fighting the Gemma encoder's footprint, and Lightricks themselves eventually shipped nodes to run Gemma through an API or reuse cached encodings. This is the self-hosted version of that idea: the encoder lives on a machine that can afford it, and your generation box never sees it. Prompts stay on your own hardware, which is more than you can say for the third-party "remote text encoder" nodes that caused a minor privacy dust-up in late 2025.