CLIP Text Encode Couple (Remote / SDXL)

SDXL doesn't read one prompt. It reads two: CLIP-L, the smaller encoder that's good at short precise descriptions, and CLIP-G, the bigger one that wants the full rich sentence. The default path runs the same text through both. The "couple" pattern is the upgrade - give each encoder the text it's actually good at, short and punchy for CLIP-L, long and detailed for CLIP-G, and let the two halves meet in the conditioning. CLIPTextEncodeCoupleRemote is that node, running the encoding on a remote GPU server instead of your sampling machine.

It's the SDXL-specific member of the ComfyUI-RemoteTextEncoder pack, and it's the one most SDXL people end up on once they try it. If you're already offloading your text encoding, this is where offloading stops being a compromise and starts being a nicer prompt workflow than the local default.

How it works

The node takes the dual CLIP connection from RemoteDualCLIPLoader and sends two separate encodes over the wire: text_l to CLIP-L (without a pooled output) and text_g to CLIP-G (with one). Then it does the SDXL assembly locally: pad the shorter embedding sequence up to the length of the longer, concatenate the two along the hidden-dimension axis so you get [1, T, D_l + D_g], and take the pooled output from CLIP-G alone. That combined tensor is exactly the layout the SDXL UNet's cross-attention expects - which is the whole point, you get byte-identical conditioning to what the local SDXL text encoder produces, just computed elsewhere.

The tooltip on the loader tells you the one ordering constraint that matters: model 1 must be CLIP-L, model 2 must be CLIP-G. Swap them and the node silently produces garbage-shaped conditioning.

Inputs and output

Three inputs, no knobs to tune:

• clip - the dual CLIP from RemoteDualCLIPLoader (CLIP-L as model 1, CLIP-G as model 2).
• text_l - the prompt for CLIP-L. The author's framing: the short, precise description. Tags and key subjects.
• text_g - the prompt for CLIP-G: the full, rich description. This is the one doing most of the scene-setting.

No max_length here - unlike CLIPTextEncodeRemote, this node is fixed at the SDXL 77-token-per-encoder budget, which is what SDXL expects. Output is a single CONDITIONING socket feeding the KSampler's positive (and you'll use a second copy of the node for the negative).

The README's SDXL wiring diagram is worth copying: two RemoteCLIPLoader nodes (one for clip-l, one for clip-g) feeding the couple node for the positive, the same two loaders feeding another couple node for the negative. In practice the single RemoteDualCLIPLoader replacing the two singles is cleaner and does the same job.

Setup and traps

Same pack install as the rest: clone https://github.com/rwfsmith/ComfyUI-RemoteTextEncoder into custom_nodes, pip install -r requirements.txt, set the server URL in rte_config.json, restart - or install via ComfyUI Manager (search ComfyUI-RemoteTextEncoder). The ComfyUI side pulls in only requests and numpy; the server (server.py) needs the transformers/safetensors/fastapi stack and a CLIP ViT-L/14 plus CLIP ViT-bigG in server/models/.

Where people get burned: the loader model order (L first, G second), and the assumption that the couple node works with a single-encoder loader - it doesn't, the clip input has to be a dual connection. Also remember clip_skip on the loader applies to both encoders, and on SDXL it mostly restates the penultimate-layer default, so don't expect it to change much.

Honest take: the couple pattern is one of the genuinely nice things about SDXL, and this node gives it to you without loading either encoder locally. For one-GPU setups it's not worth the server overhead; for the two-machine or LTX-heavy crowd, it slots right in.