How do you point the OpenAI SDK at OpenRouter, and how are models named there?

## What OpenRouter is doing OpenRouter is a gateway: a single HTTPS endpoint, a single API key, and a catalog of hundreds of models from dozens of vendors behind it. The design bet is that most applications only need the common denominator of chat — a list of messages in, a message out, optionally streamed, optionally with tool calls — and that the OpenAI Chat Completions request/response shape is the de-facto lingua franca for that. So OpenRouter accepts that shape, converts it into whatever the upstream vendor really speaks (Anthropic's Messages API, Google's `generateContent`, a vLLM deployment, and so on), and converts the answer back. ## Wiring an existing client Because the wire format matches, you do not need a new SDK. Every OpenAI client library lets you override the base URL, and that is the whole integration: - base URL: `https://openrouter.ai/api/v1` - credential: your OpenRouter key, sent as the standard `Authorization: Bearer <key>` header (the SDK does this for you when you pass it as the api key) - endpoint: `POST /api/v1/chat/completions`, with the familiar `model`, `messages`, `temperature`, `max_tokens`, `stream` fields That also means curl works, and so does any framework that already targets an OpenAI-compatible base URL. There is no OpenRouter-only client you must adopt. ## Model slugs are namespaced The field that differs is `model`. OpenAI's own API takes a bare name because there is only one vendor; OpenRouter serves many, so the identifier is namespaced as `author/model-slug`. Examples: `openai/gpt-4o`, `anthropic/claude-sonnet-4.5`, `google/gemini-2.0-flash-001`, `mistralai/mistral-large`, `meta-llama/llama-3.3-70b-instruct`. Some slugs carry a suffix after a colon that selects a variant of the same model rather than a different model. Two consequences follow. First, a bare `gpt-4o` is not a valid OpenRouter model id — the vendor prefix is part of the name, and omitting it is the single most common first-request error. Second, switching vendors is a one-string change in your code, which is exactly the property people adopt the gateway for: the same `messages` array, the same parsing code, a different slug. ## What comes back The response is normalised to the OpenAI shape: an object with `id`, `model`, `choices[]` where each choice has a `message` with `role` and `content` (plus `tool_calls` when the model called a tool) and a `finish_reason`, and a `usage` object with `prompt_tokens`, `completion_tokens` and `total_tokens`. Streaming works the same way as OpenAI's — `"stream": true` yields Server-Sent Events whose `data:` lines carry `choices[].delta` fragments and terminate with `data: [DONE]`. The response also records which model actually served the request, which matters because the served model is not always the exact one you named. One streaming detail bites hand-rolled parsers: while a request is queued upstream, the gateway may emit SSE *comment* lines (lines starting with `:`) purely as keep-alive so proxies do not time the connection out. The SSE specification says comments are to be ignored, and every real SDK does; a naive `split("data: ")` parser that tries to JSON-decode every line will blow up on them. ## Discovering the catalog `GET /api/v1/models` returns the machine-readable catalog: each entry carries the slug, a context length, the modalities it accepts, and the list of request parameters it honours. Use it rather than hardcoding assumptions — the catalog changes weekly as vendors ship and retire models. ## Common mistakes Passing an OpenAI key to OpenRouter (it is a distinct credential, issued by OpenRouter), forgetting the vendor prefix, assuming a vendor-specific SDK such as `anthropic` will work against the gateway (it will not — the gateway's chat surface is OpenAI-shaped, so use an OpenAI-shaped client), and assuming everything that works for one slug works for the next. The transport is uniform; the models behind it are not.