Module 7: Cost Control Ai In Production And Mcp

4. Choosing current models (July 2026)

Description

By the end of this lesson you'll be able to verify, in five minutes and without depending on anyone warning you, whether the model you have written in your workflows still exists and until when. You'll understand a model's life cycle —active, deprecated with a date, retired— and why it's the only component of your instance that can disappear on an announced schedule. And you'll come out with a criterion for choosing a model by task, instead of using the same one for everything, which is probably the biggest saving you'll find in the module.

This matters for two reasons that are worth not mixing up. The first is about money: between the models of a single provider there are large price differences, and using the most capable model to classify tickets into four categories is like hiring a certified translator to read a traffic light. The second is about continuity: a retired model doesn't degrade, it disappears. The identifier you have written stops existing, the call returns an error, and your production workflow halts. There's no warning in your n8n panel. The warning was on the provider's deprecations page, months earlier, and nobody read it.

Connection to the module: lessons 2 and 3 gave you the instrument and the first guardrail. This lesson touches the second big lever —which model handles the call— and it's also the only lesson in the module that deals with an availability risk, not just a cost one. Lesson 5 takes the third lever: where the model runs. And in the lesson 8 project you'll set up the currency check as a routine, not as a heroic act. A method note that runs through the whole lesson: what you learn here is a procedure, not a list. Any list of models I write today will be stale soon; the procedure to know what today's list is doesn't age.

The component that can disappear

Let's start with what makes a model different from everything else you operate.

Think of your instance's pieces. PostgreSQL 16 will still be PostgreSQL 16 next year. n8n's HTTP Request node doesn't get retired: it's updated, gains fields, and the old workflows keep working. Docker doesn't delete an image you're using. Everything you operate has an implicit property you never think about: it keeps existing.

A language model doesn't have it. Providers publish models, then publish better models, and at some point they announce a date after which the old one stops responding. It's not an accident or a bad practice: keeping old models running costs infrastructure, and the life cycle is explicit and published. What is a bad practice is not reading it.

The cycle has three states and it's worth keeping them separate:

State	What it means	What your workflow does
Active	The model is available and recommended	It works
Deprecated	It still works, but the provider has already announced the date on which it will stop doing so	It works — and you have a written deadline to migrate
Retired	It no longer exists. The identifier returns an error	It fails. Every call, in every execution

The window between "deprecated" and "retired" is your only opportunity, and it's usually months. It's enough time if you find out. The problem isn't that the window is short: it's that nothing in your instance tells you it exists.

Think of it like a driver's license. It doesn't expire all at once on a random Tuesday without warning: the date is printed on the plastic from day one. But if you never look at the plastic, the warning arrives anyway — only in the form of a fine, at the worst possible moment. The provider's deprecations page is the plastic. This module teaches you to look at it with a calendar instead of with a jolt.

What the failure looks like, so you recognize it

When a model is retired, the symptom in n8n is specific and worth recognizing:

All the executions of the workflow that uses it start failing, suddenly and all at once. It's not a gradual degradation.
The error comes from the provider and usually says the model doesn't exist or can't be found — typically a 404 or an unknown-model message.
You didn't change anything. That's the detail that confuses everyone: the workflow has been running identically for months and today it doesn't work.

If you ever see that pattern —total, sudden failure, no deployment involved, with a "model not found" error—, the first hypothesis is a retirement date that arrived. And the first action is to open the provider's deprecations page, not to debug the workflow.

The verification procedure

This is the central part of the lesson and the one that doesn't age. It's five steps, they take less than ten minutes, and they're done with a calendar.

Step 1 — Inventory what you use. You can't verify what you don't know you have. You need a list of all the model identifiers written in your workflows, with the workflow where each one lives.

In a small instance you do it by hand: you open each AI workflow and note the model sub-node. In an instance with 18 workflows like Terra Market's, it's worth automating. If you already instrumented cost_log in lesson 2, you have half the work done, because there you stored the model field:

-- Which models are really in use, and from which workflows
SELECT model,
       workflow_name,
       COUNT(*)        AS calls_last_30d,
       MAX(logged_at)  AS last_seen
FROM cost_log
WHERE logged_at >= now() - interval '30 days'
GROUP BY model, workflow_name
ORDER BY model, calls_last_30d DESC;

That query has an advantage over reviewing the workflows by hand: it tells you which models are in actual use, not which ones are configured. An unpublished workflow has a model configured and consumes nothing; a published one nobody looks at does consume. The list that matters to you is the second.

Step 2 — Open each provider's models page. That's where the list of what exists today is, with the exact identifiers. It's the source of truth; anything else —a blog, a course, your memory— is a copy with a delay.

Step 3 — Open the deprecations page. This is the step almost nobody does and the only one that gives you time to react. Providers keep a separate page where they list which models are deprecated and with what retirement date. It's information with a calendar: it tells you exactly how many months you have.

Provider	Current models	Deprecations and retirements	Prices
Anthropic	Models overview	The same page lists status and retirement dates	Pricing
OpenAI	Models	Deprecations	API pricing
Google (Gemini)	Gemini models	The same page marks versions and their status	Pricing
Local models (Ollama)	ollama.com/library	No forced retirement: the model you downloaded stays on your disk	Zero per token; the cost is the server (lesson 5)

Notice the last row, because it's an important structural difference you'll see again in lesson 5: a local model can't be retired. It's on your disk. It can become obsolete in quality, and its download may stop being available, but the one you already downloaded still responds next year. It's a form of continuity no API gives you, and it's one of the columns of the decision that's coming.

Step 4 — Cross your list with theirs. For each identifier you use, three questions:

1. Does it still exist on the models page?
      No  →  ALREADY BROKEN or about to be. It's urgent.
      Yes →  continue.

2. Does it appear on the deprecations page with a retirement date?
      Yes →  note the date in the team's calendar, with a reminder
             at 60 days. It's not urgent today and it will be.
      No  →  continue.

3. Is it the right model for what that workflow does?
      That's the other half of the lesson, further down.

Step 5 — Write it down somewhere that doesn't depend on your memory. A document, a table, a row in cost_log — wherever, but outside your head. With three columns: workflow, model, known retirement date. That document is what you check next time, and what you hand over to whoever replaces you.

The ritual: how often it's done

A procedure done once isn't a procedure, it's an anecdote. The operational question is the frequency, and it depends on your context:

When	Why
Every quarter, at a minimum	It's the cadence that gives margin to a typical deprecation window of months. Put it in the team's calendar, with an owner
Before each cohort / launch / big billing cycle	If your operation has cycles, hook the review to the cycle. It's the moment when there's attention available
When the provider announces something	Subscribe to the provider's announcements channel. It's free and it's the earliest warning you'll get
When an AI workflow fails suddenly and completely	It's not prevention, it's diagnosis — but it's the first hypothesis to check

And a note from experience: this review is documented as part of an instance's handover. If you operate for a client or for another team, the question "what happens when the provider retires this model?" will be asked of you sooner or later. Having the answer written down, with dates, is the difference between "I've got it under control" and "it hadn't occurred to me."

Worked example: Terra Market's verification sheet

Let's do it in full, with the case.

Step 1. The cost_log query returns:

model                      workflow_name       calls_last_30d
─────────────────────────  ──────────────────  ──────────────
<large-model-id>           reply-draft                 9,240
<large-model-id>           ticket-classify            22,470
<large-model-id>           weekly-report                  12

There's already a finding before opening any page: the three workflows use the same model, and it's the most capable one Terra Market had on hand when it set this up. Nobody chose it by task; it was chosen once and copied. We come back to this in the next section.

Steps 2 and 3. You open the provider's models page and its deprecations page. You note the status.

Step 4. You cross-reference and fill in the table:

Workflow	Model	Exists today?	Retirement announced?	Action
`ticket-classify`	(the one you use)	✔	(whatever the page says)	Evaluate dropping to a smaller model — it's classification
`reply-draft`	(the same)	✔	(whatever the page says)	Keep capability: it generates text the customer sees
`weekly-report`	(the same)	✔	(whatever the page says)	Negligible volume — not a priority

Step 5. That document, with a review date and an owner, is stored alongside the instance's runbook.

What to expect the first time you do this. Two surprises, almost always the same ones. The first: you'll find more distinct models than you thought, because each person who set up a workflow chose whatever they had on hand that day. The second: you'll find at least one with an announced retirement date that nobody knew about. Both are good news — you found out in time, which is exactly the point of the exercise.

Models that no longer exist and still show up in tutorials

It's worth saying it by name, because it's where most people trip up: the internet is full of tutorials that use retired models, and copying from there produces a workflow that won't start.

These are confirmed cases of families that are already retired or superseded. If you see any of them in a tutorial, in a template, or in an inherited workflow, you already know that material is old:

🛑 Anthropic's Claude 3.x family — claude-3-opus-*, claude-3-5-sonnet-*, claude-3-5-haiku-*, claude-3-7-sonnet-*. All retired over the course of 2025 and early 2026. A workflow with any of those identifiers doesn't work today.

🛑 GPT-4 and its variants — gpt-4, gpt-4-turbo, gpt-3.5-turbo. Superseded generation. OpenAI has been retiring batches of models with announced dates — there was a retirement scheduled for July 23, 2026 that affected several identifiers at once. Verify on its deprecations page before using any identifier you've seen in a tutorial.

🛑 Gemini 1.5 — gemini-1.5-pro, gemini-1.5-flash. Superseded generation.

🛑 Llama 2 (llama2 in Ollama) — it still exists as a file if you downloaded it, but it's several generations behind. In a local stack today there's no reason to choose it.

What to use instead. Here comes the honest part of the lesson. I'm going to name only what I can confirm current at the time of writing this, July 2026, and with the warning that you have to verify it the day you use it:

Anthropic, verified as of July 2026: the current line is Claude Opus 4.8 (claude-opus-4-8), Claude Sonnet 5 (claude-sonnet-5), and Claude Haiku 4.5 (claude-haiku-4-5) — from most to least capable and from most to least expensive. Confirm it on the models page before writing it in a workflow.
OpenAI and Google: I'm not going to name concrete identifiers here, and the reason is that I can't confirm them with the same certainty the day you read this, and a wrong identifier in a guide is worse than none. Go to their models pages —linked above— and take the exact identifier from there. It's literally a minute and it's the only reliable datum.
Ollama, for the local path: the sibling guide that sets up the local stack uses llama3.2, mistral, and qwen3 as chat models current as of July 2026, and nomic-embed-text for embeddings. Verify on ollama.com/library what's available when you set it up — the catalog moves fast and there, at least, there's no risk of anything breaking on you for choosing yesterday's.

The rule you take away is this: never copy a model identifier from a course, a blog, or an AI chat. Copy it from the provider's models page, the day you use it. It's the only datum in this whole module that demands verification in the moment, and it's also the cheapest to verify.

Choosing by task, not by habit

Now the other half of the lesson, which is where the money is.

Terra Market uses the same model for all three things. It's normal and it's understandable: the best available was chosen when the first workflow was set up, it worked, and the following ones were built by copying. Nobody made the decision to use it in all three; it's simply that nobody made any decision.

But the three tasks aren't the same task:

Workflow	What it really does	What it demands of the model
`ticket-classify`	Read a text and choose one of four labels	Language comprehension and following a closed instruction. No creativity, no writing, no deep reasoning
`reply-draft`	Write a text a customer will read	Writing, tone, nuance, handling of Spanish. The quality shows and the mistake is visible
`weekly-report`	Summarize metrics in prose for internal use	Writing, but for an internal audience and with a much higher tolerance for error

Classifying is the cheapest task there is. It's closed: there are four possible answers and one is correct. A small, fast model almost always gets it as right as a large one, because the task's ceiling is low — there's no room for the extra capability to show.

Writing for a customer is different. There a worse model produces text that sounds odd, that gets the tone wrong, or that makes Spanish mistakes a Latin American customer notices immediately. It's the task where capability pays for itself.

Think of it like hiring. To check whether a form is complete, you hire someone who can read. To write the reply to a complaint, you hire someone who writes well. Both are good jobs and they're not the same job, and it wouldn't occur to anyone to pay the second salary to do the first. With models it's exactly the same and almost everyone pays the second salary for everything.

The decision, with numbers

The criterion is applied in three steps, and the order matters:

1. Classify each workflow by what it demands. Closed task (classify, extract a datum, decide yes or no) or open task (write, summarize, reason in several steps). Most production workflows are closed and almost nobody notices.

2. Test the smallest model on the closed tasks, against real data. Not against three examples: against a sample of a hundred or two hundred cases where you already know the correct answer. If the small model gets it practically the same, the decision is made.

Minimal comparison protocol

  1. Take 200 real tickets already classified by the current system
     (or by a person — even better).
  2. Run those 200 through the workflow with the current model. Note:
     hits, tokens, cost.
  3. Change ONLY the model sub-node. Nothing else.
  4. Run the same 200. Note the same.
  5. Compare the two tables.

3. Decide with the two columns together. A model that saves a lot and gets it a little less right can be a good deal or a terrible deal, and it depends on what the mistake costs. In Terra Market, a wrongly classified ticket goes to the wrong queue, someone notices it and moves it: it costs minutes. If the same model were used to decide whether to approve an automatic refund, a mistake would cost real money and the calculation would be another.

What to expect from this exercise. In classification, what usually happens is that the small model gets it almost the same and costs a fraction. In writing for customers, what usually happens is that it shows. Both results are useful: the first saves you money, the second gives you the argument to defend the spend where it's actually needed.

And a variant worth keeping in your pocket: the escalation. You classify with the small model; if the small model returns low confidence or an answer outside the valid set, you escalate that case to the large model. You pay the expensive model only in the fraction of hard cases, which is usually small. It's more work to build and at high volumes it pays for itself.

Common mistakes

Copying the model identifier from a tutorial (practical). What happens: someone follows an excellent tutorial from eight months ago, copies the identifier as is, and the workflow returns a model-not-found error. Or worse: it works today because the model is deprecated but alive, and it fails three months from now when the retirement date arrives. Why it happens: the identifier looks like a stable datum, of the same kind as a node name. It's not — it's the only datum in your workflow that has an expiration date. How to detect it: if you didn't take the identifier from the provider's models page today, you don't know whether it's still alive. How to fix it: the provider's page is the only source. And if you inherited workflows from someone else, step 1 of the procedure —inventory what you use— is the first thing you do when you receive them.

Using the most capable model for everything (conceptual). What happens: the best available model is chosen when the first workflow is set up and all the following ones inherit it by copy. Terra Market pays for sophisticated writing capability to choose among four labels, 22,470 times a month. Why it happens: it's not a bad decision, it's a decision that was never made. And "the best" feels like the safe option. How to detect it: group your workflows by model. If they all use the same one, you didn't choose — you inherited. How to fix it: classify each workflow by closed or open task, and test the small model on the closed ones with a real sample of a hundred or two hundred cases. In high-volume classification it's, by far, the biggest saving you'll find in this module.

Changing models without measuring the quality (practical). What happens: someone reads that there's a cheaper model, changes it in production to save, and two weeks later the support team complains that the classifications got worse — without being able to prove it, because nobody measured before. Why it happens: the saving shows immediately on the bill and the quality degradation shows slowly and diffusely. How to detect it: if you don't have a table of "hits with model A" against "hits with model B" over the same sample, you don't know what you changed. How to fix it: the comparison protocol above. Two hundred real cases, same sample, change only the model sub-node. It costs a couple of hours and turns a discussion of feelings into a decision with data.

Not reviewing currency until something breaks (conceptual). What happens: the instance works well for months, nobody looks at any deprecations page, and one random Tuesday all the AI workflows fail at once. The team loses half a day debugging the instance before it occurs to someone that the problem is the provider's. Why it happens: nothing in n8n warns you. The debt is invisible until it comes due. How to detect it: ask yourself when was the last time someone on your team opened your provider's deprecations page. If the answer is "never" or "I don't know," you have the debt. How to fix it: the quarterly ritual, with an owner and in the calendar. And the diagnostic reflex: total and sudden failure of all AI workflows, with no deployment involved, is investigated first on the provider's page.

Writing the model identifier in twenty places (practical). What happens: the migration date arrives and you have to open fourteen workflows to change the same identifier, with the risk of missing one. Why it happens: each workflow was set up separately and the model was chosen inside each sub-node. How to detect it: count how many places you'd have to touch to change models tomorrow. If it's more than three, you have a maintenance problem. How to fix it: centralize. An environment variable read at the start, a sub-workflow that encapsulates the model call, or at least a configuration table with the identifier and a note of where it's used. The exact form depends on your instance and your edition; what doesn't depend is the principle — a datum with an expiration date shouldn't be written in fourteen places.

Exercises

Exercise 1 — Run the procedure. Take your own n8n instance, or one you set up following this guide, and run the five steps of the verification procedure. Deliver the step 4 table filled in, with at least these columns: workflow, model identifier, exists today?, retirement announced and when?, action.

If you don't have an instance on hand, do it with Terra Market's three workflows and the provider you use.

See solution

There's no single answer, and that's the point: the datum has to be yours and from today, not mine and from when I wrote this.

What most people find when doing it for the first time are these three things, and it's worth knowing they're normal:

You find more distinct models than you expected. If more than one person set up workflows, each one chose whatever they had on hand that day. Three or four different identifiers in an instance of fifteen workflows is typical. That's not bad in itself, but it means you have three or four clocks running instead of one.

You find at least one with a retirement date nobody knew about. It's the reason the exercise is done. And the good news is that you now know it with months of margin instead of with an incident.

You find a published workflow that shouldn't be. It's leak 5 from lesson 2, and it shows up on its own when you inventory. It always happens.

The important deliverable isn't the table: it's where you stored it and who its owner is. A table in your downloads folder isn't a procedure. A table in the instance's runbook, with a last-review date and a quarterly reminder in the team's calendar, is.

Why it works: the procedure has no technical difficulty — the difficulty is that nobody does it. Doing it once, in full, with your own workflows, is what turns a reading into a habit. And the first time is the one that produces the most findings.

Exercise 2 — Decide the model by task. Terra Market gives you five AI workflows and their measured profiles. For each one, decide whether the task is closed or open, propose whether a smaller model is a fit or capability is needed, and say what you'd measure before changing.

Workflow	What it does	Monthly volume	Typical input / output
`ticket-classify`	Chooses one of 4 categories	22,470 calls	740 / 35 tokens
`reply-draft`	Drafts a reply for the customer	9,240 calls	1,400 / 380 tokens
`weekly-report`	Summarizes metrics for the team	12 calls	3,200 / 900 tokens
`sentiment-tag`	Tags a ticket as positive, neutral, or negative	22,470 calls	620 / 8 tokens
`refund-decide`	Decides whether a return qualifies automatically	4,800 calls	1,100 / 60 tokens

See solution

Workflow	Task	Proposal	What to measure first
`ticket-classify`	Closed	Smaller model. It's candidate number one: high volume, four possible answers, tiny output	Hits over 200 already-classified tickets, against the current model
`reply-draft`	Open	Keep capability. The output is read by a customer and the mistake is visible	If you still want to try a smaller one: have a person from the support team blind-review 50 drafts from each model and say which they'd use without editing
`weekly-report`	Open, but irrelevant	Don't touch it. 12 calls a month move no needle	Nothing. Optimizing this is time badly spent
`sentiment-tag`	Closed, and the most closed of all	Smaller model, no hesitation. Three possible answers and eight output tokens	Hits over a labeled sample. And a prior question: does this really need a model, or does a simpler classifier suffice?
`refund-decide`	Closed — but with a catch	Careful here	The cost of the mistake, first of all

refund-decide deserves the long explanation, because it's the case that separates good judgment from automatic judgment.

Structurally it's a closed task: yes or no. By the mechanical rule, the small model would apply. But the criterion isn't only how closed the task is: it's what it costs to get it wrong. A wrongly classified ticket goes to the wrong queue and someone moves it — it costs minutes. A wrongly approved return gives someone money; a wrongly rejected one ruins the experience for a legitimate customer and probably generates a complaint.

With that cost of error, the reasonable decision is: test the small model with a large sample and demand a higher hit threshold than in the other cases. And whatever the model, this workflow probably shouldn't decide alone — human review before an irreversible action is exactly what the agents guide covers, and this is the textbook case.

Notice sentiment-tag too: same volume as ticket-classify and an eight-token output. It's the workflow where the large model is most wasted of the five. And the question I left in the last column applies to more cases than one might think: sometimes the optimization isn't changing models, it's realizing a model wasn't needed.

Why it works: the exercise practices the rule —closed or open— and then deliberately breaks it with refund-decide, so the criterion you take away isn't mechanical. The full question is: how closed the task is, how much volume it has, and what the mistake costs. All three together.

Exercise 3 — Design the ritual. You're the one who operates Terra Market's instance. Write the model-currency review procedure you're going to leave for the team, designed to work when you're not there. It has to fit on half a page. Include: how often, who, what exactly is reviewed, where the result is noted, and what's done if a retirement date appears.

See solution

A reference version:

AI model currency review — Terra Market

How often: the first Monday of each quarter. It's in the operations team's calendar as a recurring event with a reminder.

Who: the person on instance duty that week. It's not a specialist's task — the procedure is mechanical on purpose, so anyone on the team can run it.

What's reviewed, in order:

Run the models_in_use query over cost_log (it's stored in the runbook). It returns all the models with real use in the last 30 days and from which workflow.

For each model on that list, open the provider's models page and confirm it's still listed.

Open the provider's deprecations page and look up each of our models. Note any retirement date.

Confirm that no published workflow uses a model that no longer appears on the provider's list.

Where it's noted: in the model-inventory table of the instance's runbook, with the review date and the name of whoever did it. Never in a chat message — it gets lost.

What's done if a retirement date appears:

A migration task is created with a due date 60 days before the retirement date. That margin is to test, not to react.

The proposed replacement model is noted in the same table.

The migration is tested in the development environment with a sample of 200 real cases, comparing hits and cost against the current model, before touching production.

The support team is warned there's going to be a model change, so they watch for quality differences the first 48 hours.

What's done if an AI workflow fails suddenly and completely, with no one having deployed anything: before debugging the instance, open the provider's deprecations page. It's the first hypothesis.

Three decisions in that procedure are worth it.

First: the person on duty, not the specialist. A procedure only the person who wrote it can run is a procedure that stops being run when that person goes on vacation. It's written to be mechanical.

Second: the 60-day margin. It's not "migrate before the retirement date" — it's having the replacement tested and published two months before. The difference matters: migrating with the date on top of you is migrating with no ability to revert.

Third: the warning to the support team. A model change can subtly change the tone or the accuracy, and the people who read those outputs every day notice it before any metric. Warning them turns those people into your best detection system, and it costs one message.

Why it works: the difference between a team that finds out about a retirement with two months of margin and one that finds out with an incident isn't talent, it's that one has this written down and the other doesn't. It's half a page of document that avoids a whole day of chaos, and it's exactly the kind of deliverable expected from someone who operates an instance seriously.

Summary and next step

Now you know that a model is the only component of your instance that can disappear on an announced date. The cycle has three states —active, deprecated with a date, retired— and the window between the second and the third is your only opportunity to migrate without an incident. Nothing in n8n warns you about that window: the warning is on the provider's deprecations page.

You have the five-step procedure that doesn't age: inventory what you really use (with cost_log, not with memory), open the models page, open the deprecations page, cross the two lists with three questions, and write the result somewhere that doesn't depend on your head. With the cadence that turns it into a habit: every quarter, with an owner and in the calendar, plus the diagnostic reflex — a total and sudden failure of all AI workflows, with no deployment involved, is investigated first on the provider's page.

You know which families no longer exist and still show up in tutorials: Claude 3.x, GPT-4 and its variants, Gemini 1.5, Llama 2. And you know the rule that avoids the problem at the root: a model's identifier is copied from the provider's page, the day you use it — never from a course, a blog, or a chat. It's the only datum in this module that demands verification in the moment, and it's the cheapest to verify.

And you take away the criterion that's probably the biggest saving of the module: choosing by task, not by habit. Closed tasks —classify, tag, extract a datum— rarely need the most capable model, and they're usually the highest-volume ones. Open tasks —writing for a customer— are where capability pays for itself. With the protocol to decide it: two hundred real cases, the same sample, changing only the model sub-node, and comparing hits and cost. Plus the nuance that keeps you from applying it mechanically: the third question is always what it costs to get it wrong.

Before moving on you should be able to: explain the three states of a model's life cycle; run the verification procedure on a real instance; recognize the symptom of a retired model; and decide, faced with any workflow, whether its task is closed or open and what that implies for the model.

Lesson 5 takes the third big lever: where the model runs. So far we've assumed the call goes out to a provider's API. There's the alternative of bringing the model onto your own machine, and there the cost per token is zero — but the server isn't, and it costs whether it's busy or not. You'll see the break-even calculation, latency as a hidden cost almost nobody quotes, and what exactly degrades when you choose the small model. You won't set anything up: the setup is already step by step in the sibling guide. You'll decide with numbers.

Resources

Anthropic — Models overview — the list of current models with their exact identifiers, their status, and their retirement dates. It's the source of truth for that family.
OpenAI — Deprecations — the deprecations and retirements page with dates. Step 3 of the procedure is done here for that family.
Google — Gemini models — current models and the status of each version.
Ollama library — the catalog of local models available to download, with their sizes and variants.
Anthropic pricing · OpenAI API pricing · Google Gemini pricing — the current prices, to fill in the constants of lesson 2's cost_log and to compare models when choosing by task.
Chat model sub-nodes — n8n Docs — the sub-nodes where you write the identifier. It's the place you'll touch when you migrate.
Module 2 of this guide — error handling. A retired model produces failures your error branch should catch and notify, instead of letting them pile up silently.

← Previous3. The native AI Agent node in production Next →5. Local models with the AI Starter Kit ($0 per token)