Duck Text to Conditioning

The built-in CLIP Text Encode is the normal way to turn a prompt into conditioning, but it has one frustrating limitation: its text comes from a widget on the node itself. You can't feed it a string that was built somewhere else in the graph - concatenated tags, a wildcard expansion, a value pulled off a context pipe. Duck Text to Conditioning is the adapter that fixes that: it takes a CLIP and a STRING that arrives on a wire, runs them through ComfyUI's standard text encoder, and hands you conditioning.

The mechanism is exactly the stock encoder under the hood - the source wraps ComfyUI's CLIPTextEncode and calls its encode method with your text. No custom tokenization, no weights reinterpretation, nothing clever. What it adds is that the text input is forceInput, meaning it's a socket you connect to rather than a box you type into. That single change is what makes prompt-assembly pipelines work.

Inputs and output

• clip - a CLIP model (from a checkpoint or CLIP loader).
• text - a STRING input, wired from a text node, a concat node, a wildcard processor, or anything else that outputs text.
• Output CONDITIONING, ready for a KSampler's positive or negative input.

This is the natural downstream of the pack's Duck_Text_Concatenate and DuckTextMultiline: build the string over there, encode it here.

Why it matters for real workflows

Prompt building becomes composable instead of a wall of typing. You can have a base prompt shared across several generations, a per-run variation spliced in with a concat node, and a single encode point - change the variation once and the conditioning changes everywhere it's used. It also plays well with conditional graphs: gate the text with a switch, and the encoding reflects whichever prompt branch won. It's the same CLIP-era caveat as any text encoder, though: on modern LLM-encoded checkpoints (Flux 2, Z-Image, Krea 2) BREAK, per-tag weights, and the 77-token chunk logic mostly don't apply, so treat this as a tool for the CLIP-based models - SD 1.5, SDXL, Illustrious, Pony - where text conditioning still behaves the classic way.

Install

Part of duckcomfy personal nodes. ComfyUI Manager → search "duckcomfy personal nodes", or:

cd ComfyUI/custom_nodes
git clone https://github.com/duckcomfy/duckcomfy_personal_nodes

Restart ComfyUI. No extra pip packages, no model downloads. The node is another plundered one - its source class is WAS_Text_to_Conditioning from the WAS Node Suite - copied in to shrink the dependency surface. Proven behavior, no surprise.

Gotchas

Because text arrives on a wire, an empty string from an upstream node encodes as an empty conditioning - ComfyUI won't error, but you'll get a prompt-less generation. If a branch of your graph can legitimately produce nothing, consider gating the encode with a switch so it isn't fed blanks. And remember the clip input must be a real CLIP: feeding it a null or an unpatched model raises a clear error at runtime, so check your loader wiring first if you see one.