Prompt → Conditioning

If you've ever used ComfyUI's Ollama nodes, you've hit the awkward bit: an LLM hands you a nice juicy prompt as plain text, but your sampler wants CONDITIONING, and somebody has to run that text through CLIP. PromptConditioningConverter exists to be that somebody, both positive and negative at once.

It's the pack's "Prompt → Conditioning" utility, and its whole job is taking a positive string, a negative string, and a clip, and handing back two ready-to-use CONDITIONING outputs. That's it. In the pack's Ollama example workflow it sits right between the LLM's output and the KSampler - the text comes out of OllamaGenerateV2, this node turns it into something the sampler can actually eat.

How it works

There's no magic here, and that's the good news. The node literally calls ComfyUI's built-in CLIPTextEncode twice - once for positive, once for negative - using the CLIP you supply. It's the same encoding you'd get by dragging in two CLIP Text Encode nodes and typing the strings in; this just does it for both polarities in one package and keeps the wiring tidy.

Because it delegates to the stock encoder, it inherits all of that encoder's behavior. Give it an SDXL CLIP and you get SDXL conditioning. Give it Flux's CLIP and you get Flux conditioning. Nothing about this node is model-specific, which is exactly what you want from a bridge utility.

Inputs and outputs

Inputs: positive and negative (both strings, forceInput - wire them in, don't expect to type) and clip.

Outputs:

• positive_conditioning / negative_conditioning - CONDITIONING, wired straight to the sampler's positive and negative ports.

That's the whole surface area. Two in, two out, no config.

Install

Ships in the ComfyUI-RPG-Characters pack. ComfyUI Manager, search RPG-Characters, install, restart. Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/lord-lethris/ComfyUI-RPG-Characters.git

Restart ComfyUI. No requirements.txt, no models to download.

Common issues

• The strings won't type in. Same forceInput story as the rest of the pack - this node exists to convert text from somewhere else, so it only accepts wires. Feed it from an LLM node, the pack's selectors, or a Primitive string.
• Missing clip. The node can't encode without a CLIP from your checkpoint loader. If you're just testing the text path, remember it's still doing real encoding - it needs the model's text encoder wired in.
• "It just redoes what CLIP Text Encode does." Yes. That's the point, and it's not a criticism. It's the one-node convenience version, and for a workflow that already has an LLM in it, one less node to place and connect is one less place to lose a wire.
• Model-family differences. On 2025+ LLM-encoded models, negative prompts and tag weights behave very differently than on SDXL - a prose negative generated by an LLM can be inert or actively counterproductive. If the Ollama path produces mush, the culprit is usually the model's text-encoder behavior (and the negative-instruction trap on the style selector), not this converter.

For the pack's LLM-driven workflow, it's the right tool and it stays out of your way. Just remember it's a convenience wrapper, not a new kind of encoding - plug in the CLIP, feed it strings, and don't expect it to fix a bad prompt for you.