CLIP Text Encode (Remote)

Every generation starts the same way: text into a tokenizer, tokens into the text encoder, embeddings out the other side as CONDITIONING. That middle step is the one this pack moves off your machine. CLIPTextEncodeRemote is the remote version of ComfyUI's core CLIPTextEncode - same job, same output type, but the actual encoding happens on a separate GPU server and the result is shipped back over HTTP.

It's the node you wire a RemoteCLIPLoader (or RemoteDualCLIPLoader) into. You type your prompt exactly like you always have, and the only difference you'd notice is a short network round-trip before the sampler starts.

How it works

The node takes the CLIP connection object the loader built for you - which is really a server URL plus a model name, not a loaded model - and does the work the moment the graph runs. It tokenizes your text, sends it to the server's /comfy/encode endpoint, and receives the embeddings back as base64. It decodes those into tensors and assembles the standard ComfyUI conditioning structure: [[cond, {"pooled_output": pooled}]], the exact shape a KSampler expects on its positive and negative inputs.

The error handling tells you where things break: an HTTP error from the server gets surfaced with its status code and body, and a ConnectionError means the server isn't running - you'll see "Cannot reach Remote Text Encoder. Is the server running?" which is the pack's way of saying go check server.py.

Inputs and output

• clip - the CLIP connection from a remote loader. Required.
• text - your prompt, multiline, and it supports dynamic prompts like the stock node.
• max_length - optional, default 77, range 16–4096. This is the one field to actually think about. The tooltip says it plainly: it must match the model's limit. 77 is the CLIP token ceiling, and if your server model is a T5-class encoder with a bigger budget, 77 will truncate your prompt. Raise it to match the encoder; don't expect raising it to beat an encoder's real limit.

Output is one CONDITIONING socket. For a classic SD 1.x graph you'll want two of these nodes - one positive, one negative - each fed from a remote loader, both feeding the KSampler. For SDXL you can feed this node from the dual loader too, which encodes the same text with both CLIP-L and CLIP-G (that's the default SDXL behavior); if you want different text per encoder, that's what CLIPTextEncodeCoupleRemote is for.

Install and the honest gotchas

Install is the pack-wide story: clone https://github.com/rwfsmith/ComfyUI-RemoteTextEncoder into ComfyUI/custom_nodes, pip install -r requirements.txt (just requests and numpy on this side - torch is already a ComfyUI dependency), set the server URL in rte_config.json, restart. Or use ComfyUI Manager and search ComfyUI-RemoteTextEncoder. The server on the encoding machine needs the heavier stack - fastapi, uvicorn, transformers, sentencepiece, protobuf, accelerate, safetensors, plus torch - and models go in server/models/.

Three things bite people:

• The first encode is slow. The server downloads the model from Hugging Face on first request and caches it after. If your first generation hangs for minutes, that's normal - subsequent ones are fast.
• max_length mismatch. Leave it at 77 on a T5 server model and long prompts silently truncate. Set it higher than the encoder supports and you gain nothing. Match the model.
• It's a remote call. If your server box is on the other side of a flaky connection, every encode carries that latency and failure mode. This pack pays for itself on LAN, not across the internet.

Is it worth it for a single-encoder SD 1.x workflow? Marginal - CLIP isn't that heavy. The real payoff is the LTX-Video pair where the Gemma encoder is the biggest single VRAM cost in the graph. For that, see the LTX nodes in this same pack.