Module 2: The Agent's Brain: Model and System Prompt
2. Choosing the model: current families in 2026 (and which to avoid)
Description
In this lesson you'll be able to choose, with a cost, latency, and quality criterion — not out of habit or by copying an old tutorial — which model family and tier to connect to your agent's Chat Model node. And you'll be able to recognize, using the July 2026 current table, which models are already retired or about to be, so you don't leave them written into a new flow.
This matters because the most common scenario for a broken agent in production isn't an n8n bug: it's a model ID copied from a video or an article from a year and a half ago. Someone connects gpt-4o or claude-3-5-sonnet-20241022 because that's what they saw in a tutorial, the flow runs fine in testing (the provider hasn't shut it down yet), and weeks later, without warning, the node starts failing with a "model not found" error — right when nobody remembers touching that part of the flow.
Connection to the module: in the previous lesson you saw that the model is one of the agent's required pieces — the decision criterion behind every response. Now it's time to choose which one, specifically, among the families that exist today. You won't connect credentials yet (that's lesson 3) or run anything locally with Ollama (lesson 4) — this lesson is about cloud providers, and about the map you need before touching the node.
The model menu: why there's no such thing as "the best one"
Think of a delivery company with three vehicles available: a big truck, a van, and a bike. The truck can move any load but is slow and expensive per trip; the bike is cheap and fast for short distances, but it can't carry a refrigerator. Nobody uses the truck to deliver an envelope, and nobody tries to move a house on a bike. The choice depends on the load (how complex the task is), the speed you need, and the cost you're willing to pay per trip.
The same thing happens with language models. The three providers you'll use in this guide — Anthropic, OpenAI, and Google — organize their catalog in a way that's nearly identical to that logic: a "frontier" tier (reasons more, costs more, responds slower), a "balance" tier (the one you'll almost always pick by default), and an "economy" tier (fast and cheap for narrow, high-volume tasks). The question you'll ask yourself for every agent isn't "which is the best model?" but "how complex is this agent's task, and how many times a month is it going to run?"
The current families as of July 2026
| Provider | Frontier | Balance (recommended default) | Economy |
|---|---|---|---|
| Anthropic | Claude Opus 4.8 (claude-opus-4-8) | Claude Sonnet 5 (claude-sonnet-5) | Claude Haiku 4.5 (claude-haiku-4-5) |
| OpenAI | GPT-5.6 Sol (gpt-5.6-sol) | GPT-5.6 Terra (gpt-5.6-terra) | GPT-5.6 Luna (gpt-5.6-luna) |
| Gemini 2.5 Pro | Gemini 2.5 Flash | Gemini 2.5 Flash-Lite |
Anthropic also has a fourth tier above frontier — Claude Fable 5 — built for agents that run very long, complex tasks autonomously. For a typical support, sales, or back-office agent built in n8n, you'll rarely need it: the cost per token is noticeably higher than Opus 4.8, and on narrow tasks the quality difference isn't noticeable.
Google has already started moving its catalog to a 3.x generation (Gemini 3.5 Flash, Gemini 3.1 Pro, among others), but several pieces of that generation are still in preview. For a flow headed to production, the default recommendation is still the 2.5 line — it's the one with stable general availability. If you want to experiment with the new generation, go ahead, but don't lock it in yet as the model for a flow you can't afford to have fail.
Legacy and retired: what you shouldn't write into a new flow
"Legacy" isn't the same as "retired." A legacy model still responds if you connect it — the provider hasn't shut down the server — but it's no longer what Anthropic, OpenAI, or Google recommend for new code, and at some point it will get shut down. A retired model simply no longer exists: the node will throw an error when it tries to call it.
| Provider | Legacy (works, but not your starting point) | Retired or about to be (avoid it) |
|---|---|---|
| Anthropic | Opus 4.7, Opus 4.6, Sonnet 4.6, Sonnet 4.5, Opus 4.5 | Opus 4.1 — retires on August 5, 2026, two weeks from today. Any Claude 3.x (Opus 3, Sonnet 3.5, Haiku 3) or Claude 2.x, already out of service. |
| OpenAI | GPT-5.5, GPT-5.4 (and their mini/nano/pro variants) | GPT-4o, GPT-4, GPT-4 Turbo, GPT-3.5 — the entire GPT-4 family and earlier is already out. |
| Gemini 3.x in preview (3.5 Flash, 3.1 Pro) — fine to try, not yet as a production default | Gemini 2.0 Flash, Gemini 2.0 Flash-Lite, and Gemini 3 Pro Preview — Google itself has flagged them for imminent shutdown. Gemini 1.5 and 1.0, already out of service. |
There's a detail about Claude IDs worth flagging because it breaks a common intuition: from generation 4.6 onward, a dateless ID like claude-sonnet-5 is not a pointer that updates itself over time — it's, just like the dated IDs from earlier generations, a fixed, frozen version. "No date in the name" doesn't mean "always the latest version." We'll come back to this in the common mistakes, because it's the most silent cause of a flow ending up running a model nobody remembers pinning.
A note for when you come back to this lesson months from now: this table is a snapshot of July 2026. All three providers update their catalog, prices, and even their tier structure every few months. Before pinning a model in a real flow — or before teaching this module to a new cohort — confirm the current ID against the provider's official models page, not against this table from memory.
Worked example
You're going to build an agent that receives support tickets for an online store and does two things per ticket: classifies urgency (1 to 5) and drafts a short response. Estimated volume: 5,000 tickets a month. It's a narrow task — it doesn't require multi-step reasoning, and nobody's waiting for the response live in front of a customer; it runs in the background.
Step 1 — estimate the task's size. Each ticket averages 150 tokens of text, plus ~300 tokens of system prompt and instructions = 450 input tokens. The output (classification + short draft) averages 120 tokens.
Step 2 — since the task is narrow and high-volume, you compare only each provider's "balance" tier (frontier would mean overpaying for a task that doesn't need it):
| Model | Input price (per MTok) | Output price (per MTok) | Estimated cost / month (5,000 tickets) |
|---|---|---|---|
| Claude Sonnet 5 (launch price, in effect until Aug 31, 2026) | $2 | $10 | 2.25 MTok × $2 + 0.6 MTok × $10 = $10.50 |
| GPT-5.6 Terra | $2.50 | $15 | 2.25 MTok × $2.50 + 0.6 MTok × $15 = $14.63 |
| Gemini 2.5 Flash | $0.30 | $2.50 | 2.25 MTok × $0.30 + 0.6 MTok × $2.50 = $2.18 |
What to expect — interpreted result. For this exact profile (short task, high volume, no user waiting live), Gemini 2.5 Flash comes out 5 to 7 times cheaper than the other two options. That alone doesn't close the decision: the real quality of the classification and the draft has to be confirmed by running all three candidates over a sample of real tickets with the debugging engine you'll use in lesson 7 — cost per token is a filter for building the shortlist, not the only criterion for choosing. If your team already uses Anthropic for other flows and would rather not add a new provider just for this task, Sonnet 5 is still a reasonable choice at $10.50/month; what's ruled out, for this volume and this complexity, is any frontier tier (Opus 4.8, GPT-5.6 Sol, Gemini 2.5 Pro).
Common mistakes
Thinking a dateless ID updates itself. You set claude-sonnet-5 today and assume that if Anthropic improves that model next year, your agent will automatically use it. What happens: that's not how it works — from generation 4.6 on, every ID (dated or not) is a fixed snapshot, so your flow keeps running exactly the same version until you change it, and the day Anthropic retires that snapshot, the flow fails suddenly and with no warning inside n8n. Why it happens: the dateless format was designed to give a stable, easy-to-read name, not to signal "always the latest version" — that distinction isn't obvious if you're coming from other products where "no version number" does mean "the most recent one." How to spot it: periodically check the provider's models page against the ID you have written in the node — if your ID shows up in the legacy or deprecated section, act before the retirement date. How to fix it: schedule a quarterly review of the model configured in each production agent, instead of assuming "no date" means "no maintenance."
Copying a retired model's ID from an old tutorial. A video or article from 2024 shows gpt-4o or claude-3-5-sonnet-20241022 in the Chat Model node, and you copy it as-is because the rest of the tutorial is still valid. What happens: when you run the flow, the node returns a provider error (model not found or no longer supported by that credential) instead of a response — and if the flow runs unattended, the failure can go unnoticed until someone checks the executions. Why it happens: the tutorial's content doesn't expire, but the model names it mentions do — all three providers retire models every few months. How to spot it: the error shows up in n8n's executions panel as soon as you run the flow, with a provider message about the requested model. How to fix it: never pin a model ID without confirming it against this lesson's table or the provider's official docs on the same day you build the flow — the tutorial's name is a reference for which provider to use, not for the exact ID.
Assuming the most expensive model always gives a better result. For a narrow, well-defined task — like classifying and drafting a short reply — it's tempting to connect the frontier tier "to not risk quality." What happens: you pay 4 to 8 times more per token and wait longer per response, without the perceived quality improving noticeably compared to the balance tier or even the economy one. Why it happens: frontier models are optimized for long reasoning and ambiguous multi-step tasks; in a short, narrow task there isn't much room for that extra reasoning margin to apply. How to spot it: run the same task with two or three candidates from different tiers over the same test data batch and compare the actual result, not the model's reputation. How to fix it: if quality is indistinguishable between tiers for your specific task, stick with the cheaper, faster one — reserve the frontier tier for agents where multi-step reasoning actually moves the needle.
Exercises
Exercise 1. You're going to build an agent that summarizes, once a week, the full transcript of a one-hour meeting (lots of context, has to correctly extract decisions and action items) for a small team — about 50 executions a month. Which tier would you pick by default, from any of the three families, and why?
See solution
The frontier tier (Opus 4.8, GPT-5.6 Sol, or Gemini 2.5 Pro) is reasonable here, and unlike the worked example, there's no need to rule it out on cost: volume is low (50 executions/month), so even though the per-token price is the highest in the table, the total monthly spend stays low. Plus the task rewards exactly what the frontier tier does best — holding a lot of context and drawing correct conclusions from a long, loosely structured document, not answering a short question quickly.
Why it works: the criterion isn't "how important is the task?" but the combination of two variables — volume (low, so total cost doesn't explode) and the nature of the task (reasoning over a lot of context, where the frontier tier does perform better). When both point the same way, the choice is clear.
Exercise 2. You inherit an n8n flow with the Chat Model node configured with the ID claude-3-5-sonnet-20241022, copied from a tutorial. What's the problem, and how would you fix it?
See solution
That ID belongs to a Claude generation earlier than 4.x — as of July 2026 it's a model retired long ago (the current line is already on Sonnet 5, with Opus 4.8 and Haiku 4.5 rounding out the rest of the current catalog). The flow is probably already failing, or is going to fail as soon as the provider finishes deactivating that version. The fix is to change the ID to the current one from the equivalent family — claude-sonnet-5 if the task is still "balance" tier — and, before calling it done, confirm against Anthropic's official models page that ID is still active (not legacy, not headed for retirement).
Why it works: a dated ID from an old generation is the most direct signal of "this was copied from a source that never got updated" — the correct step isn't just changing the number, it's verifying the current status before pinning the replacement.
Exercise 3. An FAQ agent for an app answers 20,000 queries a month, averaging 200 input tokens and 60 output tokens per query. Compare the monthly cost between Gemini 2.5 Flash ($0.30 / $2.50 per MTok) and Claude Haiku 4.5 ($1 / $5 per MTok). Which one comes out cheaper?
See solution
Volume: 20,000 × 200 = 4,000,000 input tokens (4 MTok); 20,000 × 60 = 1,200,000 output tokens (1.2 MTok).
Gemini 2.5 Flash: 4 × $0.30 + 1.2 × $2.50 = $1.20 + $3.00 = $4.20/month. Claude Haiku 4.5: 4 × $1 + 1.2 × $5 = $4.00 + $6.00 = $10.00/month.
Gemini 2.5 Flash comes out cheaper for this volume and message-size profile.
Why it works: it's the same mechanics as the worked example — multiply the token volume (in millions) by the price per million, separately for input and output, and add them up. The result changes with every task profile, so the calculation has to be redone per agent, not assumed that one case's winner always wins.
Summary and next step
You now have the July 2026 map: three providers, each with a frontier tier, a balance tier, and an economy tier; a table of what's legacy (works, but isn't your default) and what's retired or about to be; and a method — cost by token volume, latency depending on whether a user is waiting live, quality confirmed on real data — for choosing between them instead of copying a name from a tutorial.
This is the foundation for what's next: in the next lesson you're going to create and connect Anthropic, OpenAI, and Google credentials to the agent's node, so the model you chose here stops being a row in a table and starts actually responding. If your priority is running at zero cost instead of paying per token, lesson 4 shows you the alternative with local models via Ollama.
Before moving on you should be able to: name the frontier, balance, and economy tier of at least two of the three providers; explain why a dateless ID isn't a pointer that updates itself; and, given a use case with its monthly volume, calculate and compare the estimated cost between two candidates.
Resources
- Models overview — Claude Docs — Anthropic's official table of current and legacy models, with IDs, prices, and context window.
- Model deprecations — Claude Docs — retirement dates for each Anthropic model; check it before pinning an ID in production.
- Models — OpenAI Platform — OpenAI's current model catalog, with IDs and capabilities.
- Pricing — Gemini API — price per million tokens for each Gemini model, useful for redoing the worked example's calculation with your own numbers.
- Anthropic Chat Model node — n8n Docs — how the model selector is configured inside the node you'll connect in lesson 3.