LZ CLIP Text Encode

This is the LZNodes take on the most basic node in ComfyUI: a CLIP Text Encode. You've seen a hundred of these. The difference here is a single extra output - the encoded text comes back out as a STRING socket, which is the whole reason this node exists.

What you get

• clip in, one multiline text widget.
• conditioning out - the encoded result, identical in mechanism to ComfyUI's core CLIP Text Encode (tokenize + encode_from_tokens_scheduled).
• text out - the exact string you typed, as a wire you can connect to something else.

That text output is the selling point. In a vanilla graph the prompt text lives only in the widget; if you want it in a filename, a CSV log, an image-metadata injector, or an LZ pipe, you'd normally have to wire up a separate String node and hope it stays in sync. Here the string and the encoding travel together, so your logs can't drift from what actually generated the image.

Why it fits this pack

ComfyUI-LZNodes is a "quality of life" pack that's obsessed with keeping generation parameters visible and logged - see LZAppendLogToCSV, LZSaveImageAndLog, and the lz_pipe plumbing. This node is the prompt source for that whole logging chain. If you're already using the pipe system, feed this node's text output into an LZPipePack's positive_text slot and the params stay honest end to end.

It's also handy if you're converting widgets to inputs: because text is already a socket, you can drive this node from a wildcard picker or a prompt-builder node without reaching for "convert widget to input."

Installing it

cd ComfyUI/custom_nodes
git clone https://github.com/liz-ils/ComfyUI-LZNodes

restart, and it's under MyCustomNodes/Conditioning. ComfyUI Manager: search ComfyUI-LZNodes. No requirements beyond what ComfyUI ships.

Honest take

If you never log prompts or feed strings into other nodes, this buys you nothing over the built-in CLIP Text Encode - it's the same encode under the hood, and you should just use the core node. If you're building a reproducible pipeline that records what it ran, the extra text socket is a small quality-of-life win that quietly removes a whole class of "wait, the log doesn't match the image" moments. For a single-purpose utility node, that's a fair trade.

One behavior to know: the text output always echoes what you typed, not what the model did with it. CLIP tokenizing and weighting are invisible to this node - if you want to see token-level effects you need something like an attention-inspection node, not this. It's a transport node, and it does that job cleanly.