Chat With LLM

This is the plain, unopinionated version of the three LLM nodes in this pack. Translate Text With LLM and Generate Stable Diffsution Prompt With LLM both ship with a pre-written instruction baked into them; Chat With LLM ships with nothing. You type your message into prompt, it goes to a chat model, you get text back. That blankness is the point - it's the general-purpose one you reach for when you want an LLM step in your graph that isn't already locked into "translate this" or "write me an SD prompt."

How it works

Under the hood, ComfyUI custom nodes that wrap remote LLM APIs are common enough that people ask about them regularly - usually to decide between something local (an Ollama-backed node, running a model on your own machine for free but with a real quality gap on instruction-following) and something cloud-hosted like this pack, which trades local compute for whatever a hosted provider charges. This node is squarely the second kind: a network call, not a GPU workload. Nothing in it touches your VRAM.

The request has three parts: a template_system message (the model's persona/instructions), a template_user template that can wrap your prompt inside a {} placeholder, and the prompt itself. Leave template_user empty - its default - and your prompt text goes to the model essentially unwrapped, as a normal chat message. Fill in template_user with your own instruction-plus-{} template and you get the same wrapping behavior the Translate and Generate-Prompt nodes use, just written by you instead of the pack author.

Inputs and outputs that matter

• prompt - your message. With the default blank template_user, this is everything the model sees from you.
• template_system - defaults to "You are an assistant bot." Change this to steer tone or role - a stricter system message is usually the highest-leverage edit you can make here.
• template_user - optional wrapping template with a {} placeholder for prompt. Blank by default, unlike its two sibling nodes.
• model_name - a fixed dropdown of 21 models named in provider/model-name form (nousresearch/nous-capybara-7b:free is the default), which reads like OpenRouter's catalog convention even though the README never names the provider outright.
• temperature (0–1) and max_tokens (default 300, up to 2048, -1 for uncapped) - standard sampling controls.

Output is a single text string - feed it into a Show Text node to read it, a Save Text node to log it, or right back into a prompt field somewhere else in your graph.

Installing it

Through ComfyUI Manager: search comfyui-llm-assistant. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/longgui0318/comfyui-llm-assistant
pip install -r requirements.txt

Restart ComfyUI, then add a config.yaml with an API key - the README's whole install section is three lines and stops right before explaining what that file needs. Given the model list, an OpenRouter key is the reasonable guess, but check the pack's own source before assuming the exact format.

Common issues

Node loads but every run fails: almost always the API key. This node makes a real network request per run, so a missing or wrong config.yaml fails loudly at execution time, not at ComfyUI startup - the node has no way to validate the key until it actually tries to use it.

Because model_name is a closed dropdown rather than free text, you're limited to the 21 baked-in choices, and several of them are older, free-tier model names that hosted providers periodically retire or rename. If a specific model in the list starts erroring where it used to work, that's the likely cause - swap to a different entry rather than troubleshooting your key first.

And the boring one: if pip install -r requirements.txt was run against the wrong Python (very easy to do on a portable ComfyUI install, where the system Python isn't the one ComfyUI actually launches with), the node won't even show up in the node list. Reinstall the requirements using ComfyUI's own embedded Python and restart.