LTX-Video Text Encode (Remote / T5 + Gemma)

LTX-Video 2.3 reads your prompt through two text encoders at once: T5-XXL, which carries the primary cross-attention signal at a 256-token budget and 4096 dimensions, and Gemma-3-12B, a secondary guidance stream at 512 tokens. Every single generation starts by loading both - and Gemma is the ~22 GB fp16 monster that OOMed half the cards at LTX-2's launch. The whole point of the RemoteTextEncoder pack's LTX path is that neither encoder has to live on your sampling machine. LTXVTextEncodeRemote is the node that turns your prompt into LTX-Video conditioning when both encoders are somewhere else.

It's a drop-in for the stock LTXV text-encode node in the ComfyUI-LTXVideo pack: same conditioning output, same downstream wiring, just computed over HTTP. If you've got a dual loader pointing at a server running T5-XXL and Gemma-3-12B, this is what you plug it into.

How it works

Give it a dual CLIP connection and a prompt, and it makes a single HTTP call to the server's /comfy/encode/ltxv endpoint - both encoders run in one round-trip, which matters, because you don't want two network crossings per prompt. The response carries both embedding streams as base64, and the node reassembles the conditioning structure the LTX-V 2.3 DiT expects:

• T5 provides the main token sequence and pooled_output - the encoder_hidden_states the cross-attention reads.
• Gemma rides along as gemma_embeds and gemma_pooled in the conditioning extras.

It has two additional paths in the code worth knowing about. If you feed it the hybrid LTXVRemoteCLIPLoader connection (remote Gemma, local projection), it uses that node's dedicated encode path and applies the projection locally. If you feed it a plain single-encoder connection, it treats it as a single Gemma encoder and returns standard conditioning. So the node degrades gracefully - but the intended setup is the dual loader.

Inputs

• clip - dual CLIP from RemoteDualCLIPLoader, with T5-XXL as model 1 and Gemma-3-12B as model 2. Order matters; the node assumes it.
• text - the prompt, multiline, dynamic prompts supported.
• t5_max_length - T5 token budget, default 256 (the LTX-Video default). Range 16–4096.
• gemma_max_length - Gemma token budget, default 512 (the LTX-Video default). Range 16–8192.

Output is one conditioning socket, wired into the LTX scheduler/sampler side of your workflow. No max_length-style ambiguity here: the defaults are the model defaults, and LTX likes long prompts anyway - the community's universal advice is that LTX rewards a paragraph over a sentence.

Setup and pitfalls

Pack install is shared across these nodes: 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 ComfyUI Manager, searching ComfyUI-RemoteTextEncoder. The ComfyUI side is just requests plus numpy; the heavy dependency list (transformers, sentencepiece, protobuf, safetensors, fastapi, torch) lives on the server machine, which is where T5-XXL and Gemma-3-12B are loaded and cached.

Real-world traps:

• Model order in the loader. T5 first, Gemma second. Reverse it and the conditioning shapes won't match what the DiT reads.
• First call is slow. The server downloads and loads both encoders on first use; after that they're cached. Your first generation hanging for a while is expected, not broken.
• Token budgets. If you crank gemma_max_length past what the server model's tokenizer supports, you're not gaining recall - you're just padding. The defaults are the right defaults.
• LTX-2 vs 2.3. This node's conditioning layout matches 2.3's dual-encoder read. If you're on plain LTX-2, the projection handling differs (see the LTXVRemoteCLIPLoader article for the local-projection split).

If you run LTX on a card where Gemma is the thing that makes everything OOM, this is the cleanest fix the ecosystem has that isn't "just don't use Gemma." It's niche - you need a second GPU that can hold the encoders - but within that niche it's genuinely well-built.