integrations.llm
LLM (integrations.llm)
One node for every model provider. Pick a provider (Anthropic, OpenAI, Gemini, Mistral, Groq, OpenRouter, or Custom), pick a model from the live dropdown, write a prompt — the node normalizes the rest.
Parameters
| Parameter | Type | Default | Description |
|---|---|---|---|
provider | select | anthropic | The API dialect and base URL come from the provider registry; only Custom exposes a base_url field. |
model | select | — | Live list from the provider's /models, newest first. Free text works too. |
system | expression | — | System prompt. |
prompt | expression | — | The user message, evaluated per item. |
history | expression | — | (advanced) A list of {role, content} turns inserted before the prompt — feed {{ $json.history }} from a Chat trigger directly. |
max_tokens | number | (provider default) | (advanced) Output cap. |
temperature | number | (provider default) | (advanced) |
json_mode | boolean | false | (advanced) Ask for JSON and parse it — see below. |
attachments | list | [] | (advanced) $binary field names to send along (images; PDFs on Anthropic). |
Credential: an llm credential holding the API key. The key never appears
in errors or output.
Output
One item per input item:
{ "text": "…", "usage": { "input_tokens": 12, "output_tokens": 48 },
"parsed_json": { "…": "…" } }
parsed_json appears only in json_mode: the reply is fence-stripped and
parsed; unparseable JSON fails the node with the offending text in the error.
On OpenAI-dialect providers json_mode also sets response_format.
Attachments
- Images work everywhere (native blocks on Anthropic, data-URI parts on the chat/completions dialect).
- PDFs are Anthropic-only — the chat/completions dialect has no native PDF input; the node fails with a clear pointer instead of silently degrading.
- A single field name (not a list) is accepted; a named-but-missing binary field is a clear error.
Quirks & tips
- History turns are filtered to
user/assistant— system/meta turns a chat trigger may carry are dropped rather than sent (providers reject them mid-conversation). - History must be a real list of
{role, content}— anything else is a clear error, listing what was received. - Items are processed sequentially, one API call each; usage is per item. For big batches mind the provider rate limits.
- A named provider is pinned to its registry URL — a stale
base_urlleft over from an earlier config can't hijack it. - Provider errors surface the HTTP status and the provider's message, never the key.
Related
- Chat trigger — supplies
message+historyin exactly this shape. - Respond to Chat — close the loop.
- Code — post-process
parsed_json.