LLM Text Encode

LLMTextEncode is the node that actually turns an LLM into conditioning in this pack's manual path. It takes the LLM object from LLMLoader (Text Encode), plus your prompt, and emits a real CONDITIONING socket that feeds your sampler exactly like the output of a normal CLIP Text Encode. The difference is the encoder doing the work is whatever language model you loaded - which is the entire point, and also the entire thing that makes it weird.

If you've used the pack's other encoder path, LLMCLIPLoader, think of that one as "load an LLM as if it were a built-in CLIP." This one is "load an LLM and tell me exactly what text you want encoded, and I'll do it, no wrapper." Both feed the conditioning chain; the difference is control versus convenience. This node is for when you want to see and own every piece of the encode - the exact prompt string, the system prompt, the token budget - and not have a CLIP object's machinery in between.

How it works

The mechanics are refreshingly transparent. It builds one string: system_prompt + " <Prompt Start> " + user_prompt, then tokenizes it with max_token_length (64 to 512, default 256), padding to a multiple of 8 and truncating. It runs the encoder with hidden states, takes the penultimate layer (hidden_states[-2]), and masks it with the attention mask so padding tokens contribute nothing. That penultimate-layer choice is the same one SDXL's CLIP already conditions on - nothing exotic, just a proven spot.

The important behavioral detail: this is a fixed-budget encode. The prompt gets truncated to max_token_length, period. There's no auto-chunking, no (word:1.5) weight syntax, no ComfyUI tokenizer trickery - that stuff lives in LLMCLIPLoader's enable_weights, not here. If you feed it a 600-token prompt at 256 max, you lose the tail. So the discipline with this node is to keep your prompt inside the budget, or raise the slider.

The inputs that matter

• LLM - the object from LLMLoader (Text Encode). Get these two right and everything else is tuning.
• user_prompt - your actual prompt, multiline.
• system_prompt - defaults to "You are an assistant designed to generate high-quality images..." - this is real content that goes into the conditioning, so it shapes what the encoder emphasizes.
• max_token_length - the whole token budget, 64–512. Watch this one.

One output: CONDITIONING, wired straight to your sampler's positive input (and, if you want, a second copy with a negative-style system prompt for the negative side).

Installing and gotchas

The install is shared with the whole pack: ComfyUI Manager → search comfyui-ez-llm, or:

cd ComfyUI/custom_nodes
git clone https://github.com/spawner1145/comfyui-ez-llm

Restart, then put a full HuggingFace repo in models/LLM/<name>/ (README example: Qwen3-0.6B-Prompt-Gen-v0.1). Dependencies: transformers + accelerate.

Two things to remember. First, this node encodes - it does not generate. If you want the LLM to write a prompt and then you decide what goes in, that's LLMTextGenerator's job; here you're the writer and the LLM is the encoder. Second, keep the model small. An LLM encoder for prompt conditioning doesn't need to be clever, it needs to be obedient and fit alongside your diffusion model. A 0.6B–3B model leaves the card free for the sampler, and since this node runs the model on every queue, a tiny one keeps iteration fast.