ListToMessages

The pack speaks its own dialect: LLLM_MESSAGES. If you've built a list of prompts somewhere else in your workflow - from a text loader, a wildcard batch, a CSV node - that list is a plain LIST, and the completion nodes will look at you funny if you hand it to their messages input directly. ListToMessages is the adapter that converts a LIST into the LLLM_MESSAGES structure the LLM nodes expect.

It's a one-trick node and it knows it. One input, one output, no API calls, no keys, no settings. You'll reach for it as the bridge between "data from the rest of ComfyUI" and "data the LLM nodes can consume."

The input and output

• messages (LIST) - the list you want converted.
• Output: Messages (LLLM_MESSAGES) - ready to feed a completion node's messages input, AppendMessages, or any other consumer of the message type.

It pairs naturally with the pack's other conversion utilities (MessagesToList, MessagesToText, TextToMessages) - you'll often see ListToMessages on one side of a node and its inverse on the other, chaining a round-trip through something that only understands plain lists.

How it fits the pack

Under the hood the pack's message format is a list of {role, content} dicts, the standard chat shape. ListToMessages normalizes whatever list you hand it into that shape. Since it's a pure conversion, there's no provider involved - no model input, no prompt input, nothing to configure. If you expected it to turn a list of strings into a batch of separate messages with roles, it doesn't do that job; it's a structural cast, not a semantic transform. The semantic work (assigning roles, building turns) happens in your other nodes.

Installing

It's part of ComfyUI_LiteLLM. ComfyUI Manager, search "ComfyUI_LiteLLM", or:

cd ComfyUI/custom_nodes
git clone https://github.com/Hopping-Mad-Games/ComfyUI_LiteLLM
cd ComfyUI_LiteLLM
pip install -r requirements.txt

Restart, and it's under ETK/LLM/LiteLLM. No API key needed - this node never leaves your machine.

Where people get burned

The usual failure is expecting the list to become the conversation. If you feed it a list of ten prompt strings and then send the output to a completion node, you get whatever that node does with a ten-item message structure - not necessarily ten separate turns with sensible roles. If you actually want to run a batch of prompts, that's LiteLLMCompletionListOfPrompts, not this node. And watch the direction of the data: this converts to the message type. If you've got LLLM_MESSAGES and want a plain LIST (to feed a batch node or a text saver), you want the inverse node, MessagesToList. Getting the two swapped is the one mistake everyone makes at least once, and it produces exactly the kind of "type mismatch" error that sends you searching the docs.