Send Remote CLIP

Send Remote CLIP is the other half of the pack, and it's the one doing the actual work. Load Remote CLIP is a thin client that forwards prompts; this node is the server. It takes a real CLIP on this machine and serves it to any Loader on the network, so your generation box can stop loading and unloading a 20GB text encoder every time you change a prompt. If that's your bottleneck, this is where you park the encoder.

You run it on the machine holding the model. Wire a CLIP in - straight from a Checkpoint Loader or CLIP Loader - set a port, queue the workflow, and it starts listening. The node keeps serving after the queue run finishes, so your main machine can hammer it with prompt changes all day without the sender touching its queue again. It's an output node: no outputs to wire, it just announces its status in the UI.

How it works

When the node runs, it spins up a threaded TCP socket server that accepts connections, decodes each request (a plain encoding, a LoRA-patched encoding, or a text generation), runs it against the held CLIP, and streams the result back. The worker caches aggressively: an identical prompt and settings return from an embedding cache without re-encoding, and a given LoRA stack is patched once and reused. Requests that carry image, video, or audio inputs skip the cache, since those are never truly identical.

If the connection drops mid-encode, the Loader just reconnects - no harm done. Generation is deliberately not retried, because a retry would kick off a second expensive autoregressive run. A dropped generation surfaces as an error rather than silently running twice.

The inputs

The whole surface is small:

• CLIP (required) - the model to serve.
• listen_port (required, default 8181) - the port to listen on; the Loader must match it.
• bind_host (optional, default 0.0.0.0) - which interface to bind. 0.0.0.0 means all interfaces; a specific address restricts who can reach it.
• auth_token (optional) - require a matching secret from Loaders. Also settable via the REMOTE_CLIP_TOKEN environment variable.

The defaults are sensible; the one you should actually touch is auth_token if the machine is on a shared network, because an unauthenticated 0.0.0.0 bind means anyone on that network can use your model. The node logs a warning when you do exactly that.

Beyond encoding: text generation

Because the remote CLIP is a drop-in for the whole text-encoder interface, generation-capable encoders work too. On the Loader side you can connect it to nodes like Generate Text or Generate LTX2 Prompt, and the prompt, sampling settings, and any image/video/audio inputs get forwarded here, which runs the generation and returns the text. That only works if the served model actually supports generation - a Gemma-class encoder does; a plain encoding-only CLIP will error out. Expect it to be noticeably slower than encoding, since autoregressive decoding runs token by token on the Sender's hardware.

Install & gotchas

Install on both machines, same as its counterpart:

cd ComfyUI/custom_nodes
git clone https://github.com/nyueki/ComfyUI-RemoteCLIPLoader.git

Then restart ComfyUI on both. Port 8181 needs to be open in the Sender's firewall. Don't expose this over the public internet - traffic isn't encrypted, so tunnel it through SSH or a VPN if you must. And mind the version rule: Sender and Loader must match, or requests are rejected with a protocol error rather than quietly misbehaving.