Translate Text With LLM

You've got a prompt in Spanish, or Japanese, or wherever, and the checkpoint you're using just does better on English text. That's the whole reason this node exists: it's a thin wrapper that sends your text to a chat model with a translation instruction already baked in, and hands you back a plain string you can drop straight into a CLIPTextEncode node. Nothing fancier than that - don't mistake it for a dedicated translation model like DeepL or NLLB. It's a general-purpose chat LLM being told, firmly, to only translate and not chat.

How it works

This node and its two siblings in the same pack - Chat With LLM and Generate Stable Diffsution Prompt With LLM - share identical guts. All three send a system message, a user message, and a handful of sampling settings to a chat-completion API and return the text that comes back. The only thing that changes between them is what's pre-loaded into the template_user field.

Here, template_user defaults to a classic "act as a translator" instruction with a {} placeholder in it, something like "act as an English translator... translate the following sentence: '{}'". Whatever you type into prompt gets substituted into that {} before the request goes out. So the actual text you write in prompt is just the raw sentence, not a full instruction - the node builds the instruction for you. Want a different target language, or a looser/stricter translation style? template_user is an editable multiline field, not a locked setting - rewrite it with your own instruction and your own {} placeholder and it works the same way.

Inputs and outputs that matter

• prompt - the text you want translated. This is the only field you touch on a normal run.
• template_user - the instruction wrapper, pre-filled with the translation prompt. Edit this if you want a different language pair or tone.
• model_name - a dropdown of 21 fixed chat models, all in provider/model-name format (mistralai/mistral-7b-instruct:free, nousresearch/nous-hermes-2-mixtral-8x7b-dpo, and so on). That naming convention is OpenRouter's own catalog format, which is a strong tell - though the README never says so outright - that this pack talks to OpenRouter's API rather than OpenAI or Anthropic directly.
• temperature (0–1, default 1) and max_tokens (default 300, up to 2048, or -1 for uncapped) - the usual sampling knobs. For a straight translation you generally want temperature low, not the default of 1, since you're after a faithful rendering, not creative variation.

The single output is text, a plain string. Wire it into CLIPTextEncode's text field, or into whatever downstream node consumes a prompt string.

Worth knowing going in: this LLM has nothing to do with the text encoder inside your image model. It runs before your workflow ever touches the checkpoint - it's just rewriting a string. Whatever encoder your checkpoint uses (CLIP, T5, or a full LLM encoder on 2026-era models) reads the output of this node exactly like it would read text you typed by hand.

Installing it

Through ComfyUI Manager: search comfyui-llm-assistant and install. By hand:

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

Restart ComfyUI. Then - and this is the step the README stops short of explaining - add a config.yaml with your API key. The README's entire installation section is three lines and doesn't say what goes in that file. Given the OpenRouter-shaped model list, the most likely answer is an OpenRouter API key, but you'll want to check the pack's source or an example config before assuming the exact YAML keys it expects.

Common issues

pip install -r requirements.txt needs to run against the same Python that runs ComfyUI - the classic trap on portable/embedded installs, where the system Python gets the dependencies and ComfyUI's own Python never sees them. If the node fails to import at all, that's the first thing to check.

If the node loads fine but every run errors out, that's almost always the missing or malformed config.yaml - no key, no request goes out. And because model_name is a closed dropdown baked in at publish time rather than a free-text field, you can't just type in whatever model is currently free on OpenRouter; several entries on that 21-model list look like 2024-era free-tier names, and providers do retire free models. If one choice errors with something that smells like "model not found," try another from the list rather than assuming your key is bad.