Provider setup

Before any of the agent code can run, it needs to know where to send a request, which key authorizes it, and which model to ask for. This page gets those three values in place.

Your API key is a credential

Treat it the way you'd treat a password. Never paste it into a JavaScript file, never commit it, never post it in a Discord message asking for help. Anyone holding your key can spend your credit.

That rule is also why the course keeps every API call on a server instead of in the browser. Browser code is visible to anyone who opens their browser's developer tools, so a key used there is a key you've given away.

Check what you already have

If you've taken Intro to AI Engineering, these variables may still be saved in your Scrimba account.

Open Settings in the Scrimba editor, then select Edit Environment. You're looking for three entries named exactly AI_URL, AI_KEY, and AI_MODEL.

If all three are there and point at a provider you still have credit with, you're most likely ready. Jump ahead to recommended models and confirm the model in AI_MODEL supports tool calling, since that requirement is stricter in this course than it was in the last one.

If any are missing, or you want to switch providers, keep reading.

JunoCheck what you already have Before you sign up for anything, look in Settings, then Edit Environment. Intro to AI Engineering used these exact three names, so they may already be sitting there waiting for you.

Checking takes ten seconds and can save you creating a second account you don't need!

JunoCheck what you already have Check the existing values before creating anything new. The names carry over from Intro to AI Engineering unchanged.

One thing to confirm rather than assume: that the model in AI_MODEL supports tool calling. The previous course did not require it, so a set of variables that worked perfectly there can still fall over in lesson three here.

JunoCheck what you already have Carrying the values over is the right move, with one caveat about the key itself. If that key has been sitting in a shared or long-lived account since the last course, this is a reasonable moment to rotate it, because you have no record of where it has been pasted since.

Rotating costs a minute and resets what you know about its exposure. Reusing an old learning key is fine; reusing one you have lost track of is the habit worth not building.

Which provider

OpenAI is the default used by this course. Its API is the one the Responses API originates from, and using it requires API credit. Costs depend on the model, request size, and how much you experiment, so check the current pricing before adding an amount you are comfortable using.

OpenRouter is the alternative if you can't or don't want to use OpenAI. It's a single API that routes to many providers, including free-tier models, and it speaks the same OpenAI-compatible shape, so the course code doesn't change.

Either way the setup is the same shape: create an account, generate a key, then store the provider's URL, your key, and a model ID.

JunoWhich provider Both providers work for every lesson, so there is no wrong answer here. OpenAI is what the lessons were recorded with, which makes it the easiest to follow along.

Pick OpenRouter if paying OpenAI directly is awkward where you are, or if you want to try a free model first.

JunoWhich provider The course code does not change between the two, because OpenRouter speaks the same OpenAI-compatible request shape. That is the whole reason it is offered as an alternative.

Practical split: OpenAI if you want to match the recordings exactly, OpenRouter if you want one account reaching many providers or you need a free tier to get started.

JunoWhich provider "OpenAI-compatible" is a strong claim that holds well for the request shape and less well at the edges, and the edges are where agent work lives. Strict argument typing, tool-choice forcing, and structured output enforcement are the three that vary by upstream provider, and OpenRouter passes your request to whichever one is serving that model.

It works for this course on the routes named on the models page. Keep the caveat in mind when you take the pattern somewhere else: compatibility is per-route, not per-gateway.

Setting up OpenAI

Head to the OpenAI developer platform and sign in or create an account.

ChatGPT Plus is not API credit

The developer platform is billed separately from a ChatGPT subscription. Having ChatGPT Plus does not give your API account any credit, and this catches nearly everyone once.

Open Billing in the platform settings and add credit if your account has none. Check the current model pricing and set a budget that suits your own usage.

Now open API keys in the platform settings and select Create new secret key. Give it a name that will still mean something to you in three months. When the key is created, copy it immediately, because the full value is shown exactly once and cannot be retrieved afterwards.

Back in Scrimba, open Edit Environment and set:

AI_URL=https://api.openai.com/v1
AI_KEY=your-api-key-here
AI_MODEL=gpt-5.4-nano

See recommended models if you want something other than the default. Save the environment variables once all three are in place.

JunoSetting up OpenAI The secret key appears once and is never shown again, so copy it into Scrimba while the dialog is still open. Close it too early and you delete that key and make a new one, which is annoying but harmless.

Set a billing budget while you are in there. It takes a minute and means a runaway loop can never turn into a surprise!

JunoSetting up OpenAI Two things to do in the same sitting: copy the key straight into Scrimba while it is visible, and set a spending limit in Billing before you leave.

Name the key something you will recognise in three months. When you eventually have several and need to revoke one, a list of keys called "key1" and "test" is its own small problem.

JunoSetting up OpenAI A per-key budget and a sensible name are what let you revoke precisely later. The failure they protect against is not overspending, it is being unable to tell which key leaked, so you revoke everything and rebuild every integration you own.

For a learning account that is a small inconvenience. The habit is worth forming here, because the first time it matters you will be doing it under time pressure.

Setting up OpenRouter

Create an OpenRouter account, open the API Keys page, and create a key.

OpenRouter does offer free models, and they're useful for learning. Be aware of two things before you rely on one.

Free endpoints are not guaranteed to be available, and their behavior can differ from one run to the next, which makes it hard to tell whether an odd result came from your code or from the model. Free endpoints may also route your requests to providers with different data policies, so open the Privacy settings and make a deliberate decision before enabling them.

If you want consistent results, the same advice applies here as with OpenAI: load a small amount of credit and pick a lightweight paid model.

In Scrimba, set:

AI_URL=https://openrouter.ai/api/v1
AI_KEY=your-api-key-here
AI_MODEL=mistralai/ministral-3b-2512

Save the environment variables.

JunoSetting up OpenRouter One account and one key, reaching many providers. The course code does not change at all to use it.

Watch the model ID format: it includes the provider in front, so it is mistralai/ministral-3b-2512 and not the short name on its own. That prefix trips people up constantly!

JunoSetting up OpenRouter The provider prefix is part of the ID on OpenRouter, which is the difference to watch when copying a model name from anywhere else.

Open the Privacy settings before you enable free models. That page controls which upstream providers your requests may reach, and it is the setting people skip on the way to the free tier.

JunoSetting up OpenRouter The Privacy page matters more than its placement suggests. Free routes are subsidised by someone, and the terms attached to that vary by upstream provider, including whether your prompts may be retained or used for training.

For course exercises that is a low-stakes decision. Make it deliberately anyway, because the same account and the same default will still be there the day you paste in something from work.

The three values move together

The most common setup failure is a mismatched set instead of a single wrong value. A valid OpenAI key against OpenRouter's URL fails. A valid OpenRouter setup with an OpenAI-only model ID fails. Both produce authentication or model-not-found errors that read like something is broken in the course code.

So whenever you change providers, change AI_URL, AI_KEY, and AI_MODEL as one set, and save them together.

Running the code on your own machine?

Scrimba stores these as account-level environment variables, which is why there's no .env file in the browser project. On your own machine you'll put the same three values into a .env file instead. Running the code locally covers that.

JunoThe three values move together If you see an authentication error or a model-not-found error, check these three before you check anything you wrote. Nine times out of ten one of them is left over from a previous setup.

The error messages are not much help here, because they describe what went wrong at the provider, so they read as though the course code is broken. It usually isn't!

JunoThe three values move together Treat a provider switch as one edit with three parts, saved together. Changing two of three is the specific mistake this section exists to prevent.

When an error does appear, read all three values top to bottom before opening any code. It is faster than debugging, and it is the cause far more often than anything you wrote.

JunoThe three values move together Both failures produce error messages that point somewhere other than the fault. A key sent to the wrong base URL returns a 401, which reads as a bad key. A model the provider does not serve returns a 404 on the model name, which reads as a typo.

The underlying fault in both cases is the set being inconsistent, and nothing in either message says so. That mismatch between the symptom and the cause is the reason this gets its own section rather than a footnote.

Where this goes next

Recommended models covers what makes a model suitable for agent work and which ones have been tested against this course. If you'd rather see how the request itself is put together, Chat Completions and Responses compares the two API shapes.