Nodes/LLS-node/LLS Universal Prompt Encode
ComfyUI Node

LLS Universal Prompt Encode

Prompt encoding when you refuse to care what model it is

By Gin3601·Created 3 months ago·Updated 3 months ago· 0
LLS Universal Prompt Encode
  • text_encoder
  • positive
  • negative
  • prompt_info
positive_prompt
negative_prompt
clip_skip-1
model_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_infomodel_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_encoder means 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_info ever shows a family you didn't expect, the fix is upstream: wire the loader's model_info in (kills inference entirely) or pin model_family on the loader.
CategoryLLS/Conditioning

Inputs (5)

NameTypeDefaultDescription
text_encoderCLIP
positive_promptSTRING
negative_promptSTRING
clip_skipCOMBO-125 options: , -1, -2, -3, -4, -5, +19
model_infooptSTRING

Outputs (3)

NameTypeDescription
positiveCONDITIONING
negativeCONDITIONING
prompt_infoSTRING