Skip to content

Other clients

The gateway is OpenAI Chat Completions-compatible. Most coding clients and LLM SDKs that support an "OpenAI base URL" plug in without code changes.

This page collects short notes for clients that did not get a dedicated guide. For clients not listed here, follow the OpenAI-compatible guide; the same principles apply.

Cline (VS Code extension)

Cline is supported as a first-class client (the architecture freeze names it explicitly in frozen-v3/00-architecture-decisions.md).

In Cline's API provider settings:

  • API Provider: OpenAI Compatible
  • Base URL: https://smart-openrounter.bee1x.one/v1
  • API Key: your SMART_GATEWAY_API_KEY
  • Model ID: smart-router

Cline sends Chat Completions, so routing works out of the box. Use smart-router-pro for hard reasoning tasks; use smart-router-flash to constrain cost.

Roo-Code (VS Code fork)

Roo-Code is supported as a first-class client (also in frozen-v3/00-architecture-decisions.md).

Same configuration pattern as Cline: OpenAI-compatible provider, gateway base URL, gateway key, model = smart-router.

Continue.dev

Continue config in ~/.continue/config.json:

{
  "models": [
    {
      "title": "Smart Router",
      "provider": "openai",
      "model": "smart-router",
      "apiBase": "https://smart-openrounter.bee1x.one/v1",
      "apiKey": "<SMART_GATEWAY_API_KEY>"
    }
  ]
}

OpenCode / open-interpreter

Both expose an OpenAI-compatible base URL. Point them at the gateway, pass the gateway key, set the model to smart-router.

LM Studio / Ollama (local proxies)

If you have a local LLM proxy that already speaks OpenAI's API, you can chain it: LM Studio → gateway → OpenRouter. The gateway's OPENROUTER_BASE_URL swap means you can also point it at a local OpenAI-compatible server in a dev profile, but for production it is hard-coded to https://openrouter.ai/api/v1 in env.production.template.

curl / httpie / wget

Any HTTP client works. See Integrations → cURL.

Chat clients (ChatBox, Open WebUI, etc.)

Most chat clients that support a custom OpenAI endpoint work with the gateway. Set:

  • Endpoint / Base URL: https://smart-openrounter.bee1x.one/v1
  • API Key: your gateway key
  • Model: smart-router (or one of the other aliases)

If the client supports streaming, enable it. Some chat clients display a small first-character latency because of the gateway's reasoning-delta normalization; this is harmless.

Edge cases

  • Clients that hard-code gpt-4 or gpt-3.5-turbo in their picker. The gateway will return 200 with an empty model field. Either pick smart-router in the client or override the model picker via environment variables if your client supports it.
  • Clients that send only system and no user. These are allowed by OpenAI but the policy will route them normally based on the system content. There is no special handling.
  • Clients that send only assistant messages (e.g. for regeneration). Same as above — the most recent non-empty message becomes the policy input.
  • Clients that pin to a specific OpenRouter model ID. These bypass the gateway's alias layer. The gateway forwards them as-is, but the response model field will echo the requested ID, and the privacy gate and budget policy still apply. We do not recommend this — use an alias.

When the client is not OpenAI-compatible

The gateway does not expose:

  • Anthropic /v1/messages (use OpenAI shape; an Anthropic SDK can speak it via a translation shim if you need one).
  • The OpenAI Responses API.
  • Google Gemini's native shape.

If you need a non-OpenAI shape, point the client at a local translator (LiteLLM proxy, Portkey, etc.) that exposes the right shape upstream of the gateway.