How Do You Connect Your OpenRouter API Key to Cursor and Set Up Your .env File Correctly?

Connecting OpenRouter to Cursor trips people up because two different things get conflated: configuring Cursor itself to use OpenRouter models, and setting up a .env file so your own project code can call OpenRouter. They are separate, and doing each correctly keeps your key secure and your setup working. One lives in Cursor’s settings, the other in your codebase. Here is how to connect your OpenRouter API key to Cursor and set up your .env file the right way.

Two places the key is used

First, get the distinction clear. To make Cursor’s own agent use OpenRouter models, the key goes in Cursor’s model settings, not a .env file. To make code you are building call OpenRouter, the key goes in a .env file your app reads at runtime. Same key, two homes, for two purposes. Confusing them is why setups fail. Knowing which you are configuring, the editor or your app, is the first step to doing it right.

Get your OpenRouter key

Both paths need a key. Create an OpenRouter account, generate an API key in the dashboard, name it so you can track it, and copy it somewhere safe, since it is typically shown in full only once. Add a little credit or plan to use a free model so the key can actually make calls. With the key in hand, you are ready to wire it into either Cursor or your project. The key itself is the same regardless of where it ends up.

Open Cursor’s model settings

To connect Cursor itself, open its settings and find the models section. Cursor supports custom OpenAI-compatible providers, which is exactly how OpenRouter presents itself, so this is where the connection is made, alongside Cursor’s other settings and configuration. This is the editor-level setup that lets Cursor’s agent talk to OpenRouter. Everything for the Cursor side happens here, not in your code. Start in the model settings to point the editor at OpenRouter.

Add the key and override the base URL

In the model settings, enable a custom OpenAI key and paste your OpenRouter key, then override the base URL with OpenRouter’s API endpoint so requests route there instead of to OpenAI. This pair, key plus base URL, is the whole connection. The official OpenRouter Cursor guide lists the exact endpoint and fields. Getting the base URL right is the step people miss most. With both set, Cursor sends its calls through OpenRouter.

Add the model identifiers

Finish the Cursor side by telling it which models to offer. Add the OpenRouter model identifiers you want, copied exactly from OpenRouter’s catalog, so they appear in Cursor’s model picker. Naming them precisely matters, since a wrong identifier will fail. Once added, you switch between them in Cursor as you would any model, extending how Cursor already blends editor and command-line workflows. Now Cursor’s agent can use your chosen OpenRouter models directly.

Set up the .env file for your app

The .env file is a separate matter, for when your own project calls OpenRouter. Create a file named .env in your project root and add a line like OPENROUTER_API_KEY=your_key, then have your code read it from the environment rather than hard-coding the key. This keeps the secret out of your source. The .env file is the standard home for keys your application uses at runtime. It has nothing to do with Cursor’s own settings.

Gitignore the .env file

A .env file must never reach your repository. Add .env to your .gitignore before your first commit so the key is not tracked, because a key pushed to a remote, especially a public one, is compromised the moment it lands. This single line prevents the most common and most damaging leak. Gitignoring secrets is non-negotiable, part of keeping any project safe when using agents. Protect the file before you ever commit. An untracked .env is a safe .env.

Never commit secrets

The broader rule is that keys never belong in code or version control. Beyond .env, avoid pasting the key into source files, client-side JavaScript, or anywhere it could ship to a browser, since anyone who sees it can spend your balance. Using environment variables everywhere and scanning commits for stray secrets keeps you safe. This discipline applies to every key, not just OpenRouter’s. Treat secrets as radioactive, kept only where they must be. Guarding them is basic security hygiene.

Test and troubleshoot

Confirm each path works. In Cursor, send a prompt with an OpenRouter model selected and check for a reply; in your app, run a call and see that it returns. If it fails, the usual causes are a wrong base URL, a mistyped model identifier, an empty balance, or a key pasted with a stray space or newline. Working through those resolves nearly every issue, and the error message usually points at the culprit. A quick test proves the connection before you rely on it.

If the key ever leaks, rotate it

Even with good habits, keys sometimes slip out, pasted into a screenshot, committed before .gitignore was set, or shared in a message. The fix is not to panic but to rotate: revoke the exposed key in the OpenRouter dashboard and generate a fresh one, then update it in Cursor’s settings and your .env. Because a single key can spend real credit or call expensive models, treating any exposure as a reason to rotate immediately is the safe default, and separate keys per project limit the blast radius when it happens. If you committed a key by accident, rotating it matters more than trying to scrub the git history, since the old key is already compromised the moment it was pushed.

The takeaway

Connecting OpenRouter to Cursor means two separate setups. For Cursor’s own agent, open the model settings, enable a custom OpenAI key, paste your OpenRouter key, override the base URL with OpenRouter’s endpoint, and add the exact model identifiers. For your own project code, put the key in a .env file the app reads at runtime, and crucially add .env to .gitignore so the secret never reaches your repository. Keep keys out of source and client code entirely, test both paths, and you have a secure, working OpenRouter connection in and around Cursor.

Common questions