T5 Text Encode

Quick disambiguation before anything else, because the name invites confusion: if you're running Flux or SD3 with the built-in DualCLIPLoader, you don't need this node - ComfyUI's core CLIPTextEncode already handles T5 for you there. This node is for the older wave of models that use T5 as a genuinely separate object type, not folded into a CLIP wrapper - PixArt chief among them, since it uses T5 instead of CLIP entirely rather than alongside it.

That's actually the interesting story here: T5 as a text encoder predates the current LLM-encoder era by a couple of years. Long before Qwen3 and Mistral-3 became the go-to encoders for 2026's models, PixArt was already betting that a language-model-style encoder beats CLIP's contrastive embeddings for actually following instructions - and the results backed that up. This node is what lets you run that older, still-legitimate architecture choice.

Inputs. Two, both required. text is a standard multiline prompt field. T5 is the loaded T5 encoder object, which comes from this pack's dedicated T5 loader (ExtraModels/T5 in the node menu) - not from a CLIP loader of any kind.

Output. CONDITIONING, feeding straight into PixArtResolutionCond (if you're on PixArt) and then your KSampler, exactly like conditioning normally flows.

The sibling node you should know about. This pack also ships PixArt T5 Text Encode [Reference], and the author's own README is refreshingly blunt about the difference: the reference node is a direct port of PixArt's original implementation and therefore doesn't support prompt weighting syntax, while this node - T5 Text Encode - does support weights, "but I can't attest to the correctness of the implementation." So: use this one if you want (word:1.4)-style emphasis in your prompts and are fine with a not-fully-verified weighting implementation; use the Reference node if you want to match PixArt's original behavior exactly.

The part that actually costs you something: loading T5 itself. Unquantized and run on CPU, T5 uses roughly 22GB of system RAM - a real number, not an exaggeration, and it's why people default to running it on CPU rather than trying to squeeze it onto a GPU alongside the diffusion model. Loaded in 4-bit (bnb4bit) mode, it drops to about 6GB of VRAM, which makes it usable on 12GB cards, but with a catch: bitsandbytes can't temporarily offload 4-bit weights to system RAM the way normal VRAM management does, so it just sits there in VRAM permanently once loaded (switching workflows should still release it as expected). Older Pascal cards - 1080ti, P40 - reportedly have trouble with 4-bit specifically; if you hit weirdness, the README's advice is to fall back to cpu. Got a second GPU? Point T5 at cuda:1 and it stops competing with your primary card's VRAM entirely.

Installing the pack. Search "Extra Models for ComfyUI" in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/city96/ComfyUI_ExtraModels

then pip install -r requirements.txt in your venv. The T5 side specifically may need a transformers upgrade and the spiece package for the tokenizer - the README calls this out explicitly, and it's the most common reason people hit a tokenizer error on first run. Windows users on 4-bit mode may also need a newer bitsandbytes: python -m pip install bitsandbytes.

One more knob worth knowing. If VRAM is tight regardless of which mode you pick, the Force/Set CLIP Device node from this same pack (despite the CLIP-sounding name, it works on more than just CLIP objects in practice) is the community's go-to way to manually shove an encoder off the GPU when automatic memory management isn't cutting it.