LLS Universal Prompt Encode
Prompt encoding when you refuse to care what model it is
- text_encoder
- positive
- negative
- prompt_info
LLS Simple Prompt Encode (its sibling in this pack) infers the model family from the CLIP you connect. LLS Universal Prompt Encode takes that idea one step further and makes the whole encoding path transparent: it's built to sit after LLS Universal Model Loader, which already resolved SDXL's dual encoders into one CLIP, so this node only ever sees a single text_encoder input and never has to care which family assembled it. Feed it model_info and it doesn't even have to guess - the family metadata comes along for the ride.
If you're building one workflow that you intend to reuse across SD 1.5, SDXL, and FLUX, this is the encoder you want: the wiring never changes, only the checkpoint in the loader does.
How it works
Required inputs are text_encoder (the single CLIP from the Universal Model Loader) and the two prompt boxes. clip_skip defaults to -1. The optional model_info string - the JSON the loader emits - is the key input here: the node reads the resolved model_family straight out of it instead of inferring, which removes the last bit of guesswork.
Then the same family rules as the Simple encoder apply, and this is where the "universal" promise pays off in behavior:
- SD 1.5 - straightforward dual-conditioning encode.
- SDXL - encodes at the family's default 1024×1024 framing, which SDXL conditioning expects.
- SDXL Turbo - weakens (or drops) your negative prompt, because Turbo is distilled and fights strong negatives.
- FLUX - drops the negative entirely (encodes empty) and forces clip skip off, since a T5 isn't a CLIP stack.
If model_info isn't connected, it falls back to inferring the family from the CLIP object itself, which works in most cases. So the input is optional in the literal sense and "recommended" in the practical one: wire it from the loader and you never think about this again.
Outputs
positive and negative CONDITIONING tensors for any sampler, plus a prompt_info JSON that records which family was detected, whether the negative was weakened/ignored, the effective clip skip, and even the guidance value for FLUX. That's mostly diagnostic gold if you're debugging why a prompt behaves differently across models - a single run tells you exactly what the node did with your negative.
Wiring it in
LLS Universal Model Loader → LLS Universal Prompt Encode → LLS Universal Image Generator / any KSampler
Optionally run model_info → model_info between loader and encoder.
Installing
Via ComfyUI Manager, search "LLS-node", or:
cd ComfyUI/custom_nodes
git clone https://github.com/Gin3601/LLS-node
Restart ComfyUI; the node lives under LLS/Conditioning. No requirements.txt - pure ComfyUI core CLIP machinery, nothing to pip install.
Gotchas
- The one thing this node can't do is invent an encoder. Unconnected
text_encodermeans an error, not a silent empty conditioning. The Universal Loader is the intended partner because it's the one that collapses dual encoders into a single CLIP socket. - Remember the negative-prompt behavior difference is intended: on FLUX your negative does nothing here, and that's correct behavior, not a bug. This catches a lot of people who carry SD 1.5 habits into Flux workflows.
- If
prompt_infoever shows a family you didn't expect, the fix is upstream: wire the loader'smodel_infoin (kills inference entirely) or pinmodel_familyon the loader.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| text_encoder | CLIP | — | |
| positive_prompt | STRING | — | |
| negative_prompt | STRING | — | |
| clip_skip | COMBO | -1 | 25 options: , -1, -2, -3, -4, -5, +19 |
| model_infoopt | STRING | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| positive | CONDITIONING | — |
| negative | CONDITIONING | — |
| prompt_info | STRING | — |