Running Intro to Mistral AI locally

Use this page to run the extracted Intro to Mistral AI project on your computer. You adapt its Scrimba-only API-key lookup for Vite, start the project, and find the function-calling result in the browser console. The key handling here matches the pattern in Running Chef Claude locally, so the two pages solve the same problem for different providers.

What you need first

Install a supported LTS version of Node.js. Node 24 is recommended and includes npm.

Check that Node and npm are available:

$ node --version
v24.18.0
$ npm --version
11.18.0

You also need a Mistral API key. If you do not have one, follow Mistral's Studio key setup, create a key, and copy it when it is shown. You will add it to the local environment file later on this page.

JunoWhat you need first Install the LTS version of Node.js, which brings npm with it, and create a Mistral API key. Copy the key the moment Studio shows it, because that is the only time you see the full value. I have closed that dialog too fast and had to create a second key more than once!

JunoWhat you need first Studio shows a new key once and stores only its name afterwards, so paste it somewhere safe before you leave the page. Check that your account can reach the model your downloaded lesson names, since key creation and model access are separate things. A free-tier key allows enough requests for this project.

JunoWhat you need first The project runs with Vite and installs with npm, so the page can start with a placeholder key and look completely normal. Only the function-calling loop proves the key and the model together, which is why a dev server that starts without errors tells you nothing about your Mistral account. Confirm the credential works before you start debugging code that is not broken.

Open the project folder

Open a terminal in the extracted folder containing package.json:

$ cd path-to-your-downloaded-project

JunoOpen the project folder Work in the extracted folder that contains package.json, and run every npm command from there. The environment file you create later belongs in that same folder. The most common reason a setup fails at this point is running the commands from the wrong folder, and one command confirms which folder you are in.

JunoOpen the project folder This is an npm and Vite project, so package.json tells you what npm start actually runs. The next step changes its Scrimba-only key lookup so the extracted app reads your local environment file instead.

JunoOpen the project folder Read the scripts in the extracted project rather than assuming the usual npm commands. This download includes no lockfile, so npm install resolves versions against the registry each time and writes the result locally. Two people setting up on different days can get different patch versions, which is worth remembering before you blame your own machine for a difference.

Make the API key work in Vite

The downloaded index.js reads the key with Scrimba's environment syntax:

const client = new MistralClient(process.env.MISTRAL_API_KEY)

A stock Vite browser project does not provide that process.env value. Change the line to:

const client = new MistralClient(import.meta.env.VITE_MISTRAL_API_KEY)

Create .env beside package.json:

VITE_MISTRAL_API_KEY=your-mistral-api-key-here

Create .gitignore beside it and add:

.env
node_modules/

The VITE_ prefix is required because Vite exposes only specially prefixed environment variables to browser code. Adding a key to Git by accident is not undone by deleting the file, because the value stays in the repository history, and the Git handbook covers the wider habit in ignoring files and good habits.

This key is visible in the browser

The VITE_ prefix deliberately puts the API key into the frontend bundle. Use a temporary, restricted key for local learning only. Never deploy or share this version, and never commit .env. A production application needs a backend or serverless function that keeps the key on the server.

JunoMake the API key work in Vite Change the old key lookup, put a temporary key in .env, and keep that file out of Git. The browser can still read this key, so use a key you are willing to delete afterwards. This exposure is a limitation of frontend-only projects, not an error in your setup.

JunoMake the API key work in Vite Vite client code reads import.meta.env and exposes only VITE_-prefixed variables, which is why the rename matters. Restart the server after editing .env, because those values are read at startup.

JunoMake the API key work in Vite Vite inlines the literal key string into the served JavaScript, so you can open DevTools, search Sources, and find your own credential there in plain text. Looking at it once makes the rule concrete. The backend boundary for this project has to cover the whole function-calling loop, not the key alone: the server holds the credential, runs the tool calls, and returns only the finished answer.

Install and run the project

Install the downloaded dependencies and start Vite:

$ npm install
$ npm start

Open the exact Local URL Vite prints, usually http://localhost:5173/. In the function-calling lesson, open your browser's developer tools and select Console. A returned Mistral response there is the visible success result; the lesson does not render that result on the page.

Restart Vite after changing .env. Stop it with Ctrl+C.

JunoInstall and run the project Run npm install, then npm start, and open the Local URL it prints. Then open the browser Console, because the function-calling lesson prints its answer there rather than on the page. An empty-looking page is the expected result, not a failure.

JunoInstall and run the project Use the exact address Vite prints rather than a remembered port, and restart after environment changes. The function-calling lesson reports to the Console, so keep DevTools open while you test it.

JunoInstall and run the project A running Vite server proves the packages installed and your edited source compiled, and it proves nothing beyond that. Only a real request confirms that Mistral accepts your key and the lesson's model, so run the function-calling example before you consider the setup finished. Startup and a working credential fail in completely different places.

Troubleshooting

process is not defined: The Scrimba-style environment read remains in index.js. Replace it with the import.meta.env.VITE_MISTRAL_API_KEY form above and restart Vite.

The key is undefined or authentication fails: Confirm the exact VITE_ variable name, make sure .env is beside package.json, and restart the project. Check that the key is still active in your Mistral account.

The model is unavailable or the SDK request fails: The downloaded ZIP pins an older Mistral SDK and asks for mistral-large-latest. Provider SDKs and model catalogs change. Compare the model ID in index.js against the models listed in Mistral's documentation, and change the ID before you change the pinned SDK version, since a renamed model is the more common cause.

Nothing appears on the page: Open the browser console. The representative function-calling lesson logs its final response there instead of rendering it in the page.

If you want to publish this project: Do not publish this frontend-only version. Move the Mistral call and credential to a backend first.

JunoTroubleshooting Check the VITE_ name, where .env sits, the model ID, and the browser Console, then restart. Work through those one at a time instead of changing several things at once. Do not publish this version, however well it runs on your machine.

JunoTroubleshooting Separate an unresolved process.env read from provider authorization and model availability, since each produces a different error. Compiling and completing a request are different checkpoints, and a page that reaches your browser confirms only the first one.

JunoTroubleshooting Check in this order: the Vite variable first, then SDK startup, then model access, then the function-calling loop. A renamed model and a rejected key both appear as a failed request and need opposite fixes, so read the response body before you edit anything. Before deployment the requests move to a backend, which removes this entire class of problem along with the exposed key.