Double CLIP Encode

Every standard generation graph has the same boring step: take your positive text and your negative text and turn them into conditioning, via two separate CLIP Text Encode nodes. DoubleCLIPEncode folds that into one node - one clip input, two text boxes, two conditioning outputs. It's a papercut fix: nothing revolutionary, but it removes a wire and a node from every workflow you'll ever build.

How it works

Under the hood it does exactly what two CLIP Text Encode nodes would do. It tokenizes both strings with the CLIP model, encodes each, and - the part worth caring about - it encodes with the pooled-output option enabled. That pooled encoding matters for SDXL-family models, where the pooled text embedding is used as an additional conditioning input. By preserving it, this node keeps SDXL conditioning correct rather than dropping the pooled signal the way a naive reimplementation would.

The inputs that matter

• positive - the prompt you want. Multiline, and it's set up to accept dynamic prompts, so you can drop in {prompt} style syntax from a dynamic-prompts workflow.
• negative - same shape, same treatment. Multiline.
• clip - the CLIP model from your checkpoint loader or CLIPLoader. The tooltip in the node spells it out: "The CLIP model used for encoding the text."

Outputs are positive and negative conditioning, ready to feed a sampler - or this pack's zsqsampler / controlnetStack_2, which is where the pairing starts to feel tidy: encode both sides in one node, run ControlNets in the next.

Where it saves you

It's not just fewer nodes - it's fewer chances to miswire. The classic mistake is connecting the positive text into the negative encode or vice versa, which produces "the model thinks your negative is the subject," and the image comes out wrong in a way that's hard to diagnose. One node with clearly labeled text boxes kills that failure mode. It's also a cleaner starting point for dynamic-prompt work, since both boxes accept the same syntax.

The honest take

This is a quality-of-life node, and it's a good one - but it's only worth reaching for if you're building graphs from scratch or reworking a template. Existing workflows already have their two encode nodes wired; swapping them in saves little unless you're also adopting the pack's zsqsampler and ControlNet stack, at which point the whole pack starts to feel like one cohesive pipeline rather than a grab bag.

Installing it

Ships in windfancy/zsq_prompt - search "zsq_prompt" in ComfyUI Manager, install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/windfancy/zsq_prompt

then restart. The pack installs heavy requirements this node doesn't need - it's pure ComfyUI CLIP machinery. And if Manager flags zsq_prompt as "conflicting," that's the pack's generic class names colliding in the manager's index; the community's advice is to ignore it unless you're genuinely running the other pack too.

Verdict

A two-for-one CLIP encode with the SDXL pooled-output detail done right. Unassuming, correct, and quietly handy once you adopt the pack.