AppendMessages

AppendMessages is the most boring node in this pack, and that's its job. It takes two message sets and returns one combined set. No API calls, no model, no keys - it's pure data plumbing inside the graph.

You'll want it the moment you start composing conversations from parts. Say you have a standing system message in one branch, a user question from a text node in another, and you want them merged into a single LLLM_MESSAGES stream before it hits a completion node. Or you ran two completion branches and want their message histories joined for the next round. That's this node.

The inputs and output

• existing_messages (LLLM_MESSAGES) - the base conversation, what comes first in the merged result.
• new_messages (LLLM_MESSAGES) - appended after it.

Output: Messages (LLLM_MESSAGES) - the concatenation, in order.

Wire the result into any completion node's messages input, or into AppendMessages again if you're chaining more than two sets together. It composes, which is the whole point of keeping it minimal.

How it fits the pack

The pack's message type (LLLM_MESSAGES) is what flows between completion nodes and utilities like ListToMessages, MessagesToList, ShowMessages, and AppendMessages. This node is the "combine" operation in that family. It doesn't deduplicate, doesn't validate roles, doesn't touch message contents - concatenation and nothing more. If you need to convert a plain list into the message type first, that's ListToMessages; this node assumes you're already holding LLLM_MESSAGES on both inputs.

Installing

It ships with 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 environment keys needed for this one - it never talks to a provider.

Where people get burned

About the only way to trip this up is feeding it the wrong type. Both inputs are LLLM_MESSAGES - if you connect a plain LIST or a STRING, the type system will complain (and if a loose-typed workflow lets it through, the completion node downstream will choke on the malformed messages). Use ListToMessages/MessagesToText for the conversion steps instead of forcing it here. Also worth remembering: order is meaningful, so existing_messages first, new_messages second - the merged conversation is a timeline, and putting your system context after the user messages is how you get a model that forgets its instructions.