OpenAI compatibility
Understand the supported OpenAI-style surface and the features that remain outside it.
Router supports a focused subset of the OpenAI chat-completions interface. Existing OpenAI clients can connect by changing the base URL and API key.
Supported today
| Capability | Support |
|---|---|
GET /v1/models | Model edition discovery with Router limits and availability counts. |
POST /v1/chat/completions | Text messages with system, user, and assistant roles. |
| Non-streaming responses | Assistant text, finish reason, and provider-reported usage. |
| Streaming responses | Ordered content deltas, final finish reason and usage, then [DONE]. |
| OpenAI Python and JavaScript clients | Supported through a custom base_url or baseURL. |
Accepted chat parameters
Router accepts model, messages, stream, max_tokens, and temperature. Unknown properties are rejected, which helps catch code written for a broader API surface.
{ "model": "gemma3:1b", "messages": [ { "role": "system", "content": "Answer briefly." }, { "role": "user", "content": "What is a neural network?" } ], "max_tokens": 200, "temperature": 0.4, "stream": false}Outside the supported surface
Router does not currently support tool or function calls, image input, structured output, embeddings, audio, the Responses API, arbitrary message names, or automatic model fallback.
Migrate a basic client
import OpenAI from "openai";
const client = new OpenAI({ baseURL: process.env.ROUTER_BASE_URL, apiKey: process.env.ROUTER_API_KEY,});Use an environment base URL ending in /v1, then call client.models.list() or client.chat.completions.create(...).
Design for explicit failure
Router preserves your model choice and reports unavailable capacity. If your product wants a fallback model, make that choice in your application, tell the user when it happens, and validate the alternate model’s limits first.
Continue with the Python, TypeScript, or cURL recipe.