OpenAI API - CLIP Text Encode List

What it is

Text encoders in ComfyUI take one string. This one takes a list of strings and returns a list of conditionings - one complete CONDITIONING object per prompt, in the same order, all from a single shared CLIP model.

It's the last link in the pack's batch chain, and it exists because everything upstream produces lists. Batched Chat Completion hands you twenty rewritten prompts. CLIP Text Encode, core's version, will happily take the whole list and iterate over it, which sounds like it does the same thing - and mostly does, but it gives you core's behaviour rather than this node's. What this one guarantees is that each string is encoded separately, as its own complete conditioning, rather than being treated as one member of a mixed batch, and that they come out in prompt order.

How it works

For each prompt the node does the two-step that core's encoder does internally: tokenize, then encode_from_tokens_scheduled. The scheduled variant matters - it produces the complete conditioning including scheduled entries, i.e. the timing information a checkpoint's text encoder carries, so what comes out is the same object a core CLIP Text Encode would have produced for that string. Twenty prompts, twenty tokenize-and-encode passes, one CLIP model held in memory throughout.

Encoding is CPU-and-GPU work, not an API call, so this node costs nothing and takes as long as twenty encodes take. It does check for interruption between prompts, so a long list is cancellable.

The CLIP input must resolve to exactly one model; wiring something that yields two raises. The prompts input is an execution list, and if anything isn't a string the node refuses rather than coercing.

Inputs and outputs

• CLIP (clip) - required, one shared CLIP model for every prompt. Comes from your checkpoint or a CLIP loader, exactly as core's encoder takes it.
• Prompts (prompts) - a STRING execution list, "such as Responses from Batched Chat Completion; each string is encoded separately." Wire Multiline String to List or the batch node's Responses output here.

Output: Conditioning - a CONDITIONING execution list, one entry per prompt, in the same order.

Where it goes

Feeding a sampler directly works: the sampler takes the conditioning at the corresponding position. Where this node actually shines is the pairing with the batch node's Responses, which closes the loop the pack is built around - a batch of reference images gets written up as prompts by a vision model, and those prompts come back into the graph as conditioning and get sampled, one image in, one image out, order preserved end to end.

The author's own tooltip names a second, more specific destination: connect four prompts in TL/TR/BR/BL order and feed the list to a TileSampler's local_positive input - the tiled workflows where each region of a large canvas carries its own prompt. That's the exact shape this node's list output was designed for: one conditioning per tile, positional, no manual wiring per region.

Install

It ships in the pack. ComfyUI Manager → search OpenAI API or Comfpod, or:

cd ComfyUI/custom_nodes
git clone https://github.com/lany42/comfyui-openai-api
cd comfyui-openai-api
/path/to/ComfyUI/.venv/bin/python -m pip install -r requirements.txt
# restart ComfyUI

Runtime dependencies: the openai SDK v2 (>=2.7.1,<3), numpy and Pillow. The pack needs Python 3.13+ and a ComfyUI new enough to provide comfy_api.latest. With ComfyUI Manager, search the pack title and let it install the dependency - that's the whole job.

Where people get burned

An empty string encodes to nothing useful. If one request in a batch came back blank - a refusal, a failed request, a filter - the corresponding conditioning is the encoding of an empty prompt, and the image at that position comes out as noise or a generic blob. Check the Responses list before you generate; a blank at position seven is the reason image seven is garbage.

Encoder weights versus the model. Prompts written for a Flux-style natural-language encoder and prompts written for a danbooru tag encoder are not interchangeable. This node doesn't translate anything - it encodes exactly the strings you give it with exactly the CLIP you attached, so point your LLM's output contract at the encoder your checkpoint actually uses.

Length explosion. Twenty long prompts is twenty full encodes plus a bigger conditioning payload, and batch-capable nodes downstream will work through all of it. Encode three and confirm the graph behaves before you queue fifty.

Fighting the frontend instead of the node. This is a list-output node; the frontend's auto-connect gesture can't reason about that, and a wire that lands on the wrong socket usually resolves to a type error rather than a wrong result. Check the socket names, not the colours.