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 a few related capabilities as it goes: passing strictly-typed arguments, controlling whether a tool is used at all, and returning structured output, meaning a reply shaped to a schema your interface can render instead of loose prose. 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 replies 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 the whole idea of an agent. A model that can't make that 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 it 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, this is the capability to confirm 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 the things the later lessons lean on: honouring a strict argument schema, respecting a forced tool choice, or issuing several calls in one turn.

So "supports tools" on a model card means the message shape exists, not that every behaviour the course demonstrates will hold. That is the gap the tested shortlist below is closing for you.

The shortlist

Every model below has been tested against the course's actual agent workflow, not benchmarked in the abstract. 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 cost-light 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 capability check the course depends on, and it's the cheapest verified route into the full workflow.

A few notes on the rest. Ministral 3B is a budget alternative and not a quality upgrade, so pick it on price. The 5.6 family is newer than 5.4, though newer doesn't mean cheaper, and Nano remains the cost-conscious default. Ministral 14B works but was slightly less consistent than the 3B on the course's combined tool-and-structured-output flow, which is why it sits lower.

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 and get on with the course. It is the cheapest model that passed every check, and 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 shortlistgpt-5.4-nano is the default for a reason: cheapest route that cleared every capability check the course needs.

The one reason to move up is headroom in the later lessons, where the agent juggles several tools in a turn. gpt-5.4-mini is the smallest step that helps, and it is worth trying before you assume your prompt is at fault.

JunoThe shortlist The ordering here is about consistency under the course's combined tool-and-structured-output flow, which is a narrower test than a benchmark and a more relevant one. Ministral 14B is a capable model that placed lower than the 3B on exactly that flow, which is the kind of result general leaderboards will not show you.

Worth generalising: when you evaluate a model for agent work, test the shape of your actual turns. Aggregate reasoning scores predict this poorly, and a cheaper model that holds its schema reliably beats a smarter one that drifts.

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 both give the same answer.

So if a lesson shows two tool calls in one reply and yours does them one after another, nothing is broken. It is the model's style, not your bug.

JunoSequential versus parallel tool calls Both patterns reach the same result, and the difference is the model's design rather than anything in your code.

Useful to know when you compare your console output against a lesson: a model looping one call at a time takes more round trips, so it is slower and costs slightly more per task, but the logic you wrote is identical either way.

JunoSequential versus parallel tool calls The distinction starts to matter once latency is a real constraint. Parallel calls collapse independent lookups into one round trip, while a sequential model pays full latency per tool, and that multiplies quickly in a turn that touches four or five.

It also changes your error handling. A batched turn can return several tool calls where one fails, so the loop has to hand back a result for every call it was given, including the failures, or the next turn arrives with a hole in its history.

Free models

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

The free route suggested for this course is google/gemma-4-26b-a4b-it:free on OpenRouter. Treat it as an experiment instead of one of the recommendations above, because free endpoints are rate limited, meaning the provider caps how many requests you can make in a period and refuses the rest, often enough that it hasn't been through the same testing.

Two caveats apply to any free route:

• Availability changes. A free model that works today may be rate limited or withdrawn next month, and free-tier policies shift frequently enough that any list printed in documentation goes stale.
• Consistency changes too. Free routes often shuffle between backing providers, so the same prompt can behave differently from one run to the next. When you're learning a new concept, that variability makes it hard to tell whether an odd result came from your code or from the route.

If a free route interrupts a lesson, switch to a verified paid model above for a few cents. That is the fastest way to rule the model out as the cause and keep going.

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, and that page is where you decide which ones are allowed.

JunoFree models Free routes are a fine way to read along and experiment without spending anything. They are a poor place to be when something goes wrong.

The reason is simple: you cannot tell an odd answer from an odd route, and that is exactly what you need to tell apart while learning. If a lesson starts misbehaving, spend a few cents on a paid model before you spend an hour on your code!

JunoFree models Two things move underneath a free route: availability and which upstream provider actually serves you. Both make results harder to reproduce from one run to the next.

That is fine for reading and poking around, and bad for debugging. Keep a paid model configured as the thing you switch to the moment a lesson stops behaving, so you can rule the route out in seconds.

JunoFree models Free endpoints are rate limited, and the way that surfaces is worth expecting: a 429, or a queue that stretches response times far enough to look like a hang. Neither reads obviously as a quota problem from inside your own code.

The Privacy setting deserves a deliberate answer rather than a default one. Free capacity is subsidised, and retention and training terms vary by the provider your request lands on, which is decided per request and not by you.

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, and experimenting is most of the fun.

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 Experiment freely, and keep the one debugging rule: when a later lesson misbehaves, test a known-good model before you go through your own code.

Read model IDs off the provider's current page. Catalogs move fast enough that a name in documentation is a snapshot, and a retired ID fails with a message that looks nothing like "this model is gone".

JunoGoing off the list Treat every model name on this page as a dated claim. Provider catalogs turn over on a timescale of weeks, and the honest position for documentation is to name the capability that matters, tool calling, and point at the live catalog for what currently has it.

When you do evaluate something new, test it against a turn from the course rather than a benchmark score. The failure mode you care about is a model that answers well and holds its tool schema badly, and nothing in an 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.