CLIP Text Encode (With Variables)

This is a drop-in replacement for ComfyUI's stock CLIP Text Encode node - same two inputs, same single output - except the text you write here can contain {variable_name} placeholders that get filled in from values set earlier in the graph by the pack's variable nodes (String, Int, Float, Short String). Everything else about it works exactly like the CLIP Text Encode you already know.

Why you'd reach for it

If you've ever built a workflow where the same phrase - a character description, a style, a setting - needs to show up in more than one prompt, you know the annoyance: you either duplicate the text into every text-encode box (and forget one when you update it), or you don't bother and live with an unusually manual editing process. This node is the fix. Set character = "a knight in weathered plate armor" once with a String node upstream, then reference {character} in as many CLIP Text Encode (With Variables) nodes as you want, across as many conditioning branches as you want. Change the value once and every prompt that references it updates on its next run.

It's also handy for template-style workflows you reuse across projects: keep the structure of your prompt fixed in the text box, and only swap the variable values feeding it - much closer to filling in a form than rewriting a prompt from scratch each time.

How it works

Under the hood it's the same job as stock CLIP Text Encode - take text, run it through CLIP, produce a CONDITIONING output that goes on to your sampler. The difference is a substitution pass beforehand: wherever your text contains {variable_name}, it gets swapped for whatever value was registered under that name by an upstream variable node, before that text ever reaches CLIP for encoding. If a placeholder doesn't match anything that was set, it just... doesn't get replaced, so watch for stray {} braces showing up in a generated image's prompt-adherence if you misspell a name.

For the substitution to actually have something to substitute, your variable nodes need to have run before this node executes. That's why the pack's variable nodes are built to sit inline on your CLIP wire - checkpoint's CLIP output routes through each variable node in turn, then into this node's clip input. ComfyUI executes backward from your output nodes, so chaining them this way guarantees the variables are set before this node needs them.

Inputs and outputs

• text - your prompt, multiline, same as stock CLIP Text Encode, plus whatever {variable_name} placeholders you want filled in.
• clip - your CLIP model, ideally arriving here after passing through any variable nodes upstream.

Output: CONDITIONING - wire it straight into your sampler's positive or negative conditioning input, exactly like stock CLIP Text Encode.

Installing it

Through ComfyUI Manager, search "Variables for Comfy UI." Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/yolanother/DTAIComfyVariables

Restart ComfyUI. The README lists ComfyUI itself as the only dependency - no models, no pip packages to chase down.

Common issues

Placeholder never resolves. By far the most common issue: a variable node upstream either wasn't wired into the CLIP chain, or ran with a different variable name than what you typed in your {...} placeholder. Double-check spelling and casing - this is plain string substitution, not fuzzy matching.

It looks identical to stock CLIP Text Encode until it isn't. Because the node shape is the same (text + clip in, conditioning out), it's easy to swap one for the other in a copy-pasted subgraph and not notice - until your placeholders start showing up literally in generations because the stock node has no idea what {character} is supposed to mean.

Shared-namespace collisions. The pack calls these "shared global variables" for a reason - it's a flat namespace across your whole graph. If two different variable nodes register the same name, whichever ran more recently wins, silently, with no warning here.

Thin community footprint. This is a small, low-traffic, single-maintainer pack. If something behaves unexpectedly, you're more likely to resolve it by reading the source than by finding a matching thread out there.