A workflow with an LLM inside does not behave like an ordinary one. A regular node is deterministic: same input, same output. A model is not, and that shapes how you build the process around it.
Two ways to put a model in a workflow
One: an HTTP Request node, where you assemble the request yourself for the API format you need. Two: n8n's built-in AI nodes, where you choose the provider and model from a list and the request body is built for you.
For simple jobs the built-in node is quicker. For anything unusual, such as a particular system prompt, a custom tool schema, or tight control over parameters like temperature, use HTTP Request. It gives you more room and does not depend on whether n8n's developers have exposed the option you need in the node's interface.
An example request body for HTTP Request against the codexkey endpoint:
{
"model": "claude-sonnet-5",
"max_tokens": 500,
"messages": [
{ "role": "user", "content": "={{ $json.customerMessage }}" }
]
}
The x-api-key header with your sk_cdx_... key is set once in n8n credentials and then works in every node of the workflow.
Patterns that pay off
Classifying inbound messages. An email, a form submission or a chat message gets a category, and the workflow branches on it. The model stands in for a hand-written rule that would otherwise sprawl across dozens of conditional nodes.
Extracting fields from free text. Pull the amount, date and item out of a customer email, or the tech stack and years of experience out of a resume. Ask the model to answer strictly in JSON and validate the result in the next node. Free text that nobody checks has no place in automation.
Summarizing before a notification. A long thread is squeezed down to three lines before it reaches Slack or Telegram. Whoever makes the call at the end of the workflow does not have to read the whole history, and gets less noise.
Routing tickets and requests. Classification plus extraction in one request: priority, department and key facts in a single call instead of three nodes in a row.
Error handling: when the model answers badly
The model can return invalid JSON, an answer cut off because max_tokens was too low, or an outright API error. In n8n you handle this with an Error Trigger node or the built-in Continue On Fail option on the request node. One failure then does not halt the workflow for every other item passing through it.
A habit that saves hours of debugging: put a separate validation branch right after the model call. Check the shape of the response in a JavaScript node and move the result forward only if the check passes. An invalid response goes to a log or a separate channel for manual review and never breaks the main path.
Cost per node: a different model for each job
Not every node needs the same model. Sorting text into three categories and writing a marketing email differ a lot in difficulty, so it makes sense to give them different models right in each node's settings.
In practice: keep classification and field extraction on a smaller model, and give the final text a customer will read to a stronger one. In n8n that means changing the model value in the relevant node. The rest of the workflow logic stays as it is.
A second lever is max_tokens sized to the task. A classifier that returns one word does not need a limit of a thousand tokens. The usual mistake is plain: the default got copied from an example, and nobody asked whether the answer is ever 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 one watching. While the key is shared, automation spend cannot be told apart from the team's manual work.
Create a named codexkey key for n8n so you can see automation usage on its own. Choose Premium or Cheap, optionally allow Premium fallback for Cheap, and set an expiry if you need one. Bound loops and retries inside the workflow itself: the dashboard key API does not expose per-key budgets or request throttling.
What to remember
Validate model responses and handle errors. Pick the model and max_tokens for each task, bound loops and retries in the workflow, and track automation spend through a named key.