All nodes/AI/LLM

LLM

Language model configuration (provider + model + temperature). Does not run on its own — connects to an AI Agent, LLM Response or Structured Output LLM through their Model port. It is not a step of its own: it has no run input or output.

Try it

When to use it

The LLM node is a model settings card, not a scenario step. It never calls the model itself: its output feeds the Model port of whoever makes the call — LLM Response, an AI Agent or Structured Output LLM. That is why it has no execution ports and never shows up as its own step in the run log: the engine runs it lazily, the first time a consumer needs the model.

How it works

One LLM node can feed several consumers at once — it runs once, and all of them get the same model with the same temperature. If different steps need different models, add separate nodes.

The model list is assembled from three sources: platform models, workspace models (from an integration on a key of your own where the model’s purpose is set to “Chat”) and fallback chains. Which of them appear in the dropdown is chosen under Settings → Models; the same screen shows each model’s rate — quarks per 1000 input and per 1000 output tokens.

Leaving “Max output tokens” empty means the platform ceiling of 8192 tokens. A number typed here wins, including when it is larger: that is how you stop long answers from being cut off.

Common mistakes

• Wiring the edge into an execution port. This node’s only output connects to the consumer’s Model port. A consumer without that edge fails validation, so the graph can be neither deployed nor run.
• Expecting temperature to affect a single step. It travels with the model to everyone connected to this node.
• Swapping the model and assuming behaviour carries over. Providers differ in how they treat strict tool schemas and structured output. After a model change, run the whole scenario, not just the last step.
• Assuming a hand-typed model is free. A slug that is not in the platform catalog is billed at the default rate, not at zero.

Inputs

—

Outputs

Configuration

Ready-made examples using this node

• The agent calls your own scenario as a tool
• Ask your own table in plain words
• A secretary you ask in ordinary words
• A customer books an appointment in the conversation
• A reminder an hour before, and exactly one
• “What's on today”, a list of meetings
• Paste a table into the chat, get a summary
• A chat message is written into the amoCRM deal
• A sales report arrives in Telegram every morning
• Draft, critique, rewrite
• The bot calls a human when it cannot cope
• What your documents are missing collects itself
• Every conversation lands in a table as a summary
• Describe it in words, get a picture
• A request routes itself to the right team
• A plain chat with a model
• A long text edited in pieces
• An email from a customer, an answer from your documents
• A request from the inbox becomes a row in a table
• A morning email about what landed overnight
• A list of only the emails waiting on you
• An urgent email reaches Telegram within the minute
• A digest across a batch of documents
• A recording of a stand-up becomes minutes with tasks
• A chat that remembers the conversation
• One scenario answering in every channel
• An order that lives in a table between runs
• A precise answer from the price list and the policy
• Send a link, get a summary that stays in your base
• A photo of a receipt becomes a line of spending
• “Remind me on Friday”, and on Friday it does
• Reviews sorted by tone and topic
• A second brain: throw thoughts in, ask in your words
• A shopping list the bot keeps for you
• “How much did I spend”, a breakdown by category
• Pulling fields out of text
• A support bot that answers from your documents
• An agent answer in your own format
• A voice message in, a voice answer out
• Three angles on a decision, then a verdict
• Talk it out, get a tidy note
• A form request, parsed and filed
• An agent that searches the web
• The bot on your site can see the cart