CLIP exText Encode

Core ComfyUI's CLIP Text Encode node has a text box on the node itself. To feed it from another node you have to right-click the widget and convert it to an input - a step beginners forget and veterans are tired of doing. This node is the version where the text is an input from the start. The display name is "CLIP exText Encode" - the author's typo, kept, so that's what you'll search for.

Why you'd reach for it

Any time your prompt text comes from somewhere else, this is the frictionless option. The README's own framing is spot on: it "works best when used with wildcard selectors and other dynamic output nodes for creating rich and dynamic prompts." Wildcard packs, prompt-randomizer nodes, CSV-driven prompt generators - they all output a STRING on a wire, and this node is the cleanest place to hand that string to a CLIP model and get conditioning out. You also get it for free by installing the pack, so it saves you the right-click conversion on every dynamic-prompt workflow you build.

How it works

It's the same encoding path as the core node: the text is tokenized by the CLIP model, then encode_from_tokens turns the tokens into a conditioning. The one real difference is forceInput on both clip and text, which tells ComfyUI these values always come in on wires - there's no text box to trip over. Both inputs are required, so it won't run until both wires are connected.

Inputs and outputs

• clip - a CLIP model, from your checkpoint or clip loader.
• text - the STRING prompt coming from your wildcard/randomizer/whatever node.
• CONDITIONING - the output; wire it into the positive or negative input of a sampler.

Installing it

Part of "quadmoon's ComfyUI nodes" by traugdor. ComfyUI Manager: search the pack title, or use Install via GIT URL with https://github.com/traugdor/ComfyUI-quadMoons-nodes.git. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/traugdor/ComfyUI-quadMoons-nodes.git

Restart ComfyUI. No model downloads, no extra dependencies.

Common issues

The one thing that catches people: because the text input is forced, you can't type a prompt into this node at all - there's no widget. If you expected a text box, you grabbed the wrong node; use the core CLIP Text Encode for hand-typed prompts and this one for wired-in text. Otherwise it behaves exactly like the standard encoder, which means all the usual rules apply: negative prompts go to the negative input, and the CLIP model has to match your checkpoint (SD1.5's CLIP for SD1.5 checkpoints, and so on).