h4 - Dual Clip Text Encode

H4_DualCLIPTextEncode solves one specific, annoying problem: "How do I send my prompt to the sampler and to something else that needs the raw text?" A stock CLIPTextEncode takes text, returns conditioning, and the original string is gone - which is a pain when you also want the prompt logged, fed to a save node's metadata, or used as a display value. This node encodes your text into conditioning and passes the original string out the other side. Two outputs, zero extra wiring.

It's the kind of small utility that lives inside h4_Live's face suite (it's shipped alongside the FaceForge/IdentityEngine code) precisely because the Identity Engine wants both the encoded conditioning and the plaintext prompt for its own bookkeeping. But there's nothing face-specific about it - it works for any workflow where you want the prompt both encoded and in hand.

The inputs

• text - the prompt. Multiline, with dynamic prompts enabled in the source, so wildcard/random syntax gets expanded before encoding.
• clip - the CLIP model to encode with. Comes from your loader.

The outputs

• CONDITIONING - the encoded result, exactly what a sampler eats.
• TEXT_OUT - the original prompt as a string. This is the whole point of the node: the text survives the encode step so it can ride onward as data.

How it works

Under the hood it's the standard ComfyUI encode path: clip.tokenize(text) then encode_from_tokens(tokens, return_pooled=True), packaged into the conditioning list format the samplers expect. Nothing exotic - which is the point. The only real quirk is that if clip is None it raises a clear, friendly error telling you your loader failed to produce a CLIP, which is genuinely helpful for debugging a dead graph.

Installing

Standard h4_Live install: ComfyUI Manager → search "h4_Live", or:

cd ComfyUI/custom_nodes
git clone https://github.com/m3rr/h4_Live

restart. No extra dependencies - it's a thin wrapper over core ComfyUI text encoding.

Where people get burned

Honestly, this node is hard to break, which is refreshing. The main way to trip it up is to feed it a None clip, which it will loudly complain about. Second: remember that TEXT_OUT is the raw string you typed, not the processed one - if dynamic prompts rewrote {red|blue} into a concrete word, TEXT_OUT carries the resolved text but not a trace of the alternatives. If you need the resolved variant for metadata, feed it from a downstream prompt-processing node instead. Minor, but worth knowing if you're using this for saved-image provenance.

For a 99% use case, this is the node you drop in, forget about, and never think about again - which is exactly what a good utility should be.