Automation with an LLM inside behaves differently from an ordinary workflow. A regular node is deterministic: the same input gives the same output. A model is not fully deterministic, and that changes how you build the process around it.
How a model enters the workflow
Two paths. First: an HTTP Request node with the request built by hand for the format you need. Second: n8n's built-in AI nodes, where you pick a provider and model from a list and the request body gets assembled for you.
For simple scenarios the built-in node is faster. For anything nonstandard, a specific system prompt, a custom tool schema, or fine control over parameters like temperature, HTTP Request gives you more room and does not depend on whether n8n's developers happened to expose the option you need in the node's UI.
An example request body through HTTP Request against the Claudexia endpoint:
{
"model": "claude-sonnet-4.6",
"max_tokens": 500,
"messages": [
{ "role": "user", "content": "={{ $json.customerMessage }}" }
]
}
The x-api-key header with your sk_cdx_... key is set up once through n8n credentials and reused across every node in the workflow.
Practical patterns
Classifying inbound messages. An email, a form submission, or a chat message gets sorted into a category, and the workflow branches on the result. Here the model replaces a hand-written rule that would otherwise live in dozens of conditional nodes.
Extracting fields from free text. Pull the amount, date, and item out of a customer email; pull the tech stack and years of experience out of a resume. Ask the model to answer strictly as JSON and validate the result in the next node, free text with no downstream check has no place in automation.
Summarizing before a notification. A long email or chat thread gets compressed to three lines before it goes to Slack or Telegram. That cuts the noise for whoever makes the actual decision at the end of the workflow without forcing them to read the whole history.
Routing tickets and requests. A combination of classification and extraction: pull priority, department, and the key facts in one call instead of three sequential nodes.
Handling errors in the workflow
The model can return invalid JSON, a truncated answer because max_tokens was set too low, or an outright API error. In n8n that is handled with an Error Trigger node or the built-in Continue On Fail option on the request node, so one failure does not stop the whole workflow for every item passing through it.
A practice that saves hours of debugging: add a dedicated validation branch right after the model call. Check the response shape in a JavaScript node, and only let the result move forward if that check passes. An invalid response goes to a log or a separate channel for a human to look at, instead of breaking the main path.
Controlling cost per node
Not every node in a workflow needs the same model. Sorting into three categories and generating copy for an outbound email are different in difficulty, and it makes sense to assign each a different model right in that node's settings.
The practical approach: keep classification and field extraction on a smaller model, and reserve a stronger one for the final text a customer will actually see. In n8n that just means changing the model value on a specific node, no rework of the rest of the workflow logic needed.
Another lever: cap max_tokens to what the task needs. A classifier that has to return one word does not need a limit of a thousand tokens, and the usual mistake is copying the default from an example without asking whether the answer is really that long.
A separate key for automation
n8n workflows run on a schedule or a webhook and can fire hundreds of times a day with no human involved. Sharing a key between that and a team's manual work gets messy fast: hard to tell who actually consumed the limit, and hard to cap automation separately from people.
Every Claudexia key carries its own limits and its own usage stats, so it is worth setting up a separate key specifically for n8n. Then you can see exactly what the automation is spending, and if there is an odd spike, a workflow stuck in a loop, say, you can throttle or disable that key without touching the keys real users depend on.
In short
LLMs inside n8n add unpredictability to a place that used to be deterministic logic, so response validation and error handling are mandatory, not optional. Split models across nodes by task difficulty and tune max_tokens per role. A separate key for automation with its own limit removes the guesswork about where a surprise bill came from.