Recommended models

There are thousands of models you could point AI_MODEL at. Most of them will not work for this course, and the reason comes down to a single capability.

The one hard requirement: tool calling

An agent is a model that can ask your application to run something on its behalf. It doesn't run anything itself.

It returns a structured request saying, in effect, "call get_weather with the city set to Oslo, then tell me what came back." Your code runs the function and hands the result back.

That structured request is tool calling, and a model without it can't be turned into an agent however the surrounding code is written. It isn't a question of the model being weaker or slower. The message shape the whole course depends on isn't there at all.

Beyond tool calling, the course leans on two related behaviors as it goes: filling in a tool's arguments exactly as its schema defines them, and following an instruction about whether a tool must be used or must not be. Models vary in how reliably they do these, which is why the shortlist below exists.

If something breaks later, suspect the model

This is the single most useful debugging instinct for this course. If a lesson works for everyone else and not for you, and your code matches the solution, try a recommended model before assuming your code is wrong. A model limitation and a bug produce very similar-looking console output.

JunoThe one hard requirement: tool calling Tool calling means the model can reply with a request instead of an answer: the name of a function and what to pass it. Your code runs the function and hands back the result.

That back-and-forth is what makes an agent. A model that can't make the request isn't a weaker agent, it isn't one at all, so this is the first thing to check about any model you're curious about.

JunoThe one hard requirement: tool calling The split to hold onto: the model decides, your code executes. Tool calling is the message format that lets the model say which function and which arguments, and everything the course builds sits on top of it.

When you look at a model outside the list below, confirm this first. Provider pages usually label it "function calling" or "tools", and it is a yes or no, not a matter of degree.

JunoThe one hard requirement: tool calling Support is not one flag, which is where the surprises come from. A model can emit tool calls and still be unreliable at what the lessons lean on: honoring a strict argument schema, or respecting a tool_choice that forces or forbids a call.

So "supports tools" on a model card means the message shape exists, not that those behaviors will hold. That gap is what the tested shortlist below closes.

The shortlist

Every model below has been tested against the course's actual agent workflow, not benchmarked in the abstract: each one completed a tool loop through the Responses API, filled in a strict tool's arguments exactly, and obeyed an instruction to call a tool or to leave tools alone. They're all fast and low cost.

Use this when	Model	Provider route
You want the default	gpt-5.4-nano	OpenAI
You want the cheapest non-OpenAI route	mistralai/ministral-3b-2512	OpenRouter
You want more headroom	gpt-5.4-mini	OpenAI
You want the newest efficient model	gpt-5.6-luna	OpenAI
You want a balanced newer model	gpt-5.6-terra	OpenAI
You want a larger Mistral	mistralai/ministral-14b-2512	OpenRouter

gpt-5.4-nano is the recommendation if you don't want to think about it. It passed every check the course depends on, it is the course's default, and it is one of the lowest-cost routes on this list.

A few notes on the rest. Ministral 3B is a budget alternative and not a quality upgrade, so pick it on price. Luna and Terra are the efficient and balanced tiers of the newer 5.6 family; both passed the same checks, and being newer is not by itself a reason to leave Nano. Ministral 14B works but was slightly less consistent than the 3B on an extra check that combines tool calls with a strictly shaped final reply, which is why it sits lower. The course doesn't require that combination, so this is a tie-breaker rather than a warning.

OpenAI models are also reachable through OpenRouter if you'd rather keep one account and one key. openai/gpt-5.4-nano on OpenRouter is a verified route.

JunoThe shortlist Take gpt-5.4-nano, copy it into AI_MODEL in your Scrimba environment, save, and get on with the course. Choosing a model is not the interesting part of this.

If you want to try something else later, the table is here and nothing stops you.

JunoThe shortlist Pick by the provider you set up. On OpenAI, start with gpt-5.4-nano and step up to gpt-5.4-mini if you want more headroom. On OpenRouter, mistralai/ministral-3b-2512 is the budget pick and openai/gpt-5.4-nano gives you the default model through the same key.

Whichever you choose, keep it as your main model for the whole course, so a surprise in a later lesson has one fewer variable.

JunoThe shortlist "Tested" here means three gates taken from the course's own turns: a full tool loop, exact arguments against a strict: true schema, and tool_choice set to required and to none. That is a narrower test than a benchmark and a more relevant one.

Worth generalizing: when you evaluate a model for agent work, test the shape of your actual turns. A cheaper model that holds its schema reliably beats a smarter one that drifts, and aggregate scores won't tell you which is which.

Sequential versus parallel tool calls

Some models issue several tool calls in one turn, and some issue one call per turn and loop. Both complete the course.

If your model only ever calls one tool at a time, you'll still reach the same result. You won't see the batched turn demonstrated in a later lesson, where the model asks for two tools at once. That's a design choice in the model, and nothing you need to fix.

JunoSequential versus parallel tool calls Some models ask for several tools at once; others ask for one, wait, then ask for the next. Both finish the course and reach the same answer.

So if a lesson shows two tool calls in one reply and yours does them one after another, nothing is broken.

JunoSequential versus parallel tool calls When you compare your Runner output against a lesson, expect this difference. A model that loops one call at a time takes more round trips, so it is slower and uses a few more tokens per task.

The code you write is identical either way, because the loop handles every tool call in the model's reply, whether that is one or several.

JunoSequential versus parallel tool calls Parallel calls collapse independent lookups into one round trip, while a sequential model pays full latency per tool, and that adds up in a turn that touches four or five.

It also shapes error handling. A batched turn can include a call that fails, and the loop still has to hand back a result for every call it was given, failures included, or the next request arrives with a call that has no answer.

Free models

Free endpoints exist, mostly through OpenRouter, and they're a good way to learn without spending anything.

The free model for this course is dots-studio/dots-3-note-preview:free on OpenRouter. It ran the course's agent loop in our checks on October 19, 2026: it called the OpenSwap tools with the right arguments, checked project health before saying a project was maintained, and answered from what the tools returned.

Free routes come and go. A free model that works today may be rate limited or withdrawn next month, so if the ID above stops working, check OpenRouter's model list for a free model with tool calling and try that.

Check the Privacy settings first

Before enabling free endpoints at all, open OpenRouter's Privacy settings. Free routes may send your requests to providers with different data policies, including providers that may train on what you send, and that page is where you decide which ones are allowed. Free and paid models have separate settings there.

JunoFree models You can follow the course on the free model. Copy its ID into AI_MODEL, save, and carry on.

A free model won't always behave exactly like the one in the recording. That's normal, and working out why is part of learning how agents behave.

JunoFree models Different models take different paths through the same loop: more or fewer turns, a different order of tool calls, different wording in the final answer. Compare your run with the lesson by what the agent did, not by the exact text.

If a free model does something the lesson's model didn't, a few lines of your own code around the loop is often enough to handle it, and that's good practice for any model you use later.

JunoFree models A rate limit comes back as an HTTP 429 error. In the Runner output it sits among any other failed request's details, so it rarely announces itself as a quota problem unless you read the status.

Give the Privacy setting a deliberate answer rather than the default one. Retention and training terms belong to whichever provider your request lands on, and unless you narrow the allowed providers there, the router makes that choice for you on each request.

Going off the list

Experiment freely. That's most of the fun. Hold onto the one debugging rule from above: when something doesn't work as expected in a later lesson, check whether it's a model limitation before you go hunting through your code.

Model catalogs and prices change faster than documentation does, so treat any specific model name here as a snapshot. The provider's own model page is always the current truth on what exists and what it costs.

JunoGoing off the list Go and try other models. The list is a starting point, not a fence.

Two habits keep it painless: check the model can call tools before you blame your code, and copy model IDs from the provider's own page rather than from anything written a while ago, this page included.

JunoGoing off the list Before switching, look for tool or function calling on the model's provider page. If a later lesson then misbehaves, switch back to a model from the table and rerun the same request.

If the problem goes away, it was the model. If it stays, it's worth reading your code against the solution.

JunoGoing off the list Treat every model name on this page as a dated claim. Provider catalogs turn over in weeks, so the durable part of this page is the capability that matters, tool calling, and the pointer to the live catalog for what currently has it.

When you evaluate something new, test it against a turn from the course rather than a benchmark score. The failure you care about is a model that answers well and holds its tool schema badly, and no aggregate score will warn you about that.

Where this goes next

Chat Completions and Responses covers the two API shapes you'll encounter and why this course settles on one of them. If your provider values aren't saved yet, Provider setup is the page that does it.

JunoWhere this goes next Once your model ID is saved in AI_MODEL, you're ready for the next page, which shows the request your code sends to that model.

JunoWhere this goes next The model is one of three values that move together. If you change provider to reach a model on this list, change AI_URL and AI_KEY with it, as Provider setup explains.

JunoWhere this goes next Every model on the shortlist was tested through the Responses API, which is the shape the next page explains. A model that only works through Chat Completions wouldn't have passed.