CLIP Text Encode (OreX)

Every SD 1.5/SDXL workflow is built on the same handshake: CLIP Text Encode turns your prompt into conditioning, the sampler does the rest. CLIP Text Encode (OreX) is a drop-in for that node with one useful addition - it accepts extra dynamic string inputs and concatenates them into the prompt. If you've ever wanted to compose a prompt from parts (a subject node + a style node + a quality suffix) without wrestling string nodes, this is a tidy way to do it.

How it works

At its core it's a thin wrapper around ComfyUI's own CLIPTextEncode - same text + clip in, same CONDITIONING out, same behavior. The trick is the FlexibleOptionalInputType: the node accepts an open-ended set of optional inputs whose names start with string (string1, string2, ...). When you wire any of them, the node collects them in order, joins them with commas, and appends the main text field. So a LoRA's trigger words, a character description, and a style tag can each come from different parts of the graph and still land in one prompt without you hand-assembling a string.

The result is deterministic and visible: it also outputs PROMPT - the final concatenated string - alongside the CONDITIONING, which is genuinely handy for debugging "why does this look different than I typed?" cases.

Inputs that matter

• text - the main prompt text; supports dynamic prompts (the {seed}/{prompt} wildcard style) since it passes through the core node.
• clip - your CLIP model, as always.
• Optional string1, string2, ... - dynamic parts, prepended in order before the main text. The names don't have to be contiguous; the node sorts them numerically.

Install

ComfyUI Manager (search "comfyui-OreX") or:

cd ComfyUI/custom_nodes
git clone https://github.com/orex2121/comfyui-OreX

Restart. No extra dependencies - it imports the core CLIPTextEncode, so this is ComfyUI-internal.

The honest caveat

This is a CLIP text encoder, which means it's for the SD 1.5 / SDXL / Flux-using-CLIP family of conditioning. It's not for the modern T5/Qwen text-encode paths used by Flux and Wan - those don't produce a CONDITIONING through CLIPTextEncode, so don't reach for this node on a Flux checkpoint. And one naming quirk: it's the "Cip" node, typo and all - that's how it registers in the node menu. For SD-style workflows the dynamic string mixing is a genuine convenience, but if you just need a plain encoder, the core node and this one are interchangeable.