Setting Up My First OpenRouter AI API Key: Working Code and Two Mistakes I Made

Why I Went Looking for an AI API Gateway

I was comparing three different LLMs for a small side project — a tool that rewrites messy meeting notes into clean summaries — and quickly realized that testing each one meant signing up separately with each provider, generating a separate key, and learning each provider's specific request format. That's a lot of setup before I'd written a single line of the actual feature. This is roughly the point where most people discover what an AI API gateway actually is: a single service that sits in front of multiple LLM providers, so you authenticate once and call whichever model you want through one consistent format.

OpenRouter is one of the more commonly recommended options for this, so that's where I started. Here's the actual setup process, plus the two mistakes that cost me time I didn't need to lose.

Getting an OpenRouter API Key

Sign up on OpenRouter's site, and there's a dedicated Keys section in the dashboard where you generate one. This part is genuinely simple — no unusual configuration, just a string you'll pass in your requests like any other AI API key.

Configuring It in Code

OpenRouter's API follows the OpenAI compatible API format, which meant I didn't need a new SDK — just a different base URL and my OpenRouter key:

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_OPENROUTER_API_KEY",
    base_url="https://openrouter.ai/api/v1"
)

def ask(model, prompt):
    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    return response.choices[0].message.content

meeting_note = "Discussed Q3 roadmap, agreed to delay launch by two weeks, action items assigned to Sam and Priya."

result = ask("anthropic/claude-3.5-sonnet", f"Summarize this meeting note in two sentences: {meeting_note}")
print(result)

The model string is where the actual utility of using this kind of gateway shows up — switching between different OpenRouter models just meant changing that one argument, not rebuilding my client setup for each provider I wanted to test.

Testing Multiple Models Without Repeating Setup

models_to_compare = [
    "anthropic/claude-3.5-sonnet",
    "openai/gpt-5.6-mini",
    "google/gemini-2.5-flash",
]

for model in models_to_compare:
    print(f"--- {model} ---")
    print(ask(model, f"Summarize this meeting note in two sentences: {meeting_note}"))
    print()

This is the actual value for a comparison-heavy workflow like mine: one function, one loop, three models tested in the time it would've taken to configure one provider's SDK from scratch.

Mistake #1: Assuming Auth Errors Mean a Bad Key

My first several requests failed with an authentication error even though I'd copied the key correctly. The actual problem was a leftover Authorization header format in my client config from a different provider I'd tested earlier. If you're migrating code written for another LLM API, double-check your header format against what the OpenRouter API documentation actually shows — don't assume a failed auth request means the key itself is wrong.

Mistake #2: Assuming Flat-Rate Pricing

I initially assumed one API key meant one pricing tier across every model. It doesn't — each model you call carries its own per-token pricing set by the underlying provider, and it varies meaningfully between something like a fast, cheap model and a larger flagship one. Worth checking current pricing for your specific target models before running anything at real volume, rather than assuming a uniform rate.

What I'd Tell Someone Following an OpenRouter API Tutorial for the First Time
Get one model working end-to-end before adding a comparison loop — isolate whether an issue is your setup or a specific model's behavior
Store your key in an environment variable immediately; a leaked gateway key exposes access to every model you've configured it to reach, not just one provider's service
Check per-model pricing explicitly rather than assuming your existing budget assumptions from a single-provider setup still apply
Where This Left Me

Once I had this comparison running cleanly, I also tested the same three models through RouteAI, mainly out of curiosity about how pricing and available models compared across a couple of gateways before settling on one long-term. That's genuinely a "check both, see what fits your specific models and budget" decision rather than something I'd tell you to take on faith — the actual problem worth solving here isn't which gateway you pick, it's not losing an afternoon to four separate provider signups just to run one comparison.

TL;DR: Setting up an OpenRouter API key is mostly a five-minute process — the two things that actually cost me time were a stale auth header from a different provider, and assuming pricing was flat across models when it's per-model. Working code for a multi-model comparison loop is above.

Linking the tool mentioned above: www.fastrouteai.com