Quickstart

Make your first request

1. 1

   Create an account and get approved

   Sign up with email or Google, and confirm your email if asked. New accounts need an admin's approval before keys work; the dashboard shows whether you are still waiting. If an admin pre-approved your address, access starts as soon as your email is confirmed.

2. 2

   Create an API key

   In the dashboard, name a key and press New key. Copy it straight away: it starts with rk_live_ and is shown only once. Keep it out of source code, for example in an environment variable:

   export ROUTER_API_KEY="rk_live_..."

3. 3

   Pick a model

   Loading models…

4. 4

   Send a chat completion

   curlPythonJavaScript

   curl https://your-router.example/api/public/v1/chat/completions \
     -H "Authorization: Bearer $ROUTER_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
       "model": "your-model",
       "messages": [{"role": "user", "content": "Say hello in one sentence."}]
     }'

   The request shows up under Recent requests in your dashboard with its status, latency and token count.

Streaming

Set stream: true to receive tokens as server-sent events, exactly as the OpenAI API sends them. Add stream_options: { include_usage: true } to get token counts in the final chunk, which also makes them appear in your usage history.

curl -N https://your-router.example/api/public/v1/chat/completions \
  -H "Authorization: Bearer $ROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "your-model",
    "stream": true,
    "stream_options": {"include_usage": true},
    "messages": [{"role": "user", "content": "Count from 1 to 5."}]
  }'

Use it from a local coding agent

Coding agents that accept a custom OpenAI-compatible provider work with the router: give them the base URL, your key and a model name. Keep the key in the ROUTER_API_KEY environment variable rather than in a config file you might commit.

• Agents edit files and run commands through tool calls, so pick a model that supports function calling well, ideally a coding model. Aider is the exception: it edits through plain text and works with any chat model.
• The router does not report context sizes, so the examples set a 128k context window. Change it to the model's real limit; too high and long sessions fail.
• Choose the provider type that uses Chat Completions. Options built on the OpenAI Responses API do not work here.

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "router": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LLM API Router",
      "options": {
        "baseURL": "https://your-router.example/api/public/v1",
        "apiKey": "{env:ROUTER_API_KEY}"
      },
      "models": {
        "your-model": {
          "name": "your-model",
          "limit": { "context": 128000, "output": 16384 }
        }
      }
    }
  },
  "model": "router/your-model"
}

Models

Model names are chosen by the admins and can differ from the provider's own names. List the ones available right now without a key:

curl https://your-router.example/api/public/v1/models

Loading models…

API reference

Only these two endpoints exist today. Embeddings, the legacy completions endpoint and the Responses API are not routed.

Errors

Errors use the OpenAI shape, {"error": {"message": "..."}}, so SDKs raise them as normal API errors.

Keys and usage

• Create as many keys as you like, for example one per app or machine.
• The router stores only a hash of each key, so a lost key cannot be recovered. Create a new one and revoke the old one.
• Revoking a key stops it working immediately. So does an admin removing your account's access, for all of your keys.
• The dashboard shows when each key was last used and your last 25 requests with status, latency and tokens.

For admins

The first account created on a new deployment becomes the admin and is always allowed. Everyone else needs your approval before their keys work. Models only appear for users once an admin has connected a backend and routed a model name to it, all under Admin.

1. 1

   Connect a backend

   In Backends, add one. The Nebius Token Factory and OpenRouter presets fill in the base URL. Leave Credential empty to use the server secret NEBIUS_API_KEY or OPENROUTER_API_KEY set in Lovable Cloud; that keeps the provider key out of the database. Any other OpenAI-compatible endpoint works with its own credential.

2. 2

   Test it

   Press Test on the backend's row. It lists the provider's models; an error here means a wrong base URL or key.

3. 3

   Route a model name

   In Model routing, choose the public name users will send, the backend, and the provider's model id. After a successful test the model id field suggests the provider's models. Short public names without slashes, such as qwen3-coder, are easiest to use from coding agents, some of which prefix model names with a provider and a slash.

4. 4

   Approve users

   In Users, new accounts are listed as pending, with a count on the tab. Approve lets their keys work; Remove access stops all of an account's keys on the next request. Under Pre-approved emails, add addresses you trust: a matching account is approved once its email is confirmed, so signing up with someone else's address is not enough. Pre-approval never overrides a denial.

5. 5

   Check tracing and traffic

   LLMOps turns LangSmith tracing on or off and sets the project; it needs the LANGSMITH_API_KEY server secret. Traffic shows every user's requests.