Skip to content

OpenRouter Models

OpenRouter is a gateway that puts hundreds of models from many vendors (Qwen, DeepSeek, Mistral, Anthropic, OpenAI, Google, …) behind a single API key. Kew dispatches to OpenRouter through the OpenCode runner, so any model in OpenRouter's catalog is one model = line away — no per-vendor accounts or keys.

Setup

  1. Install the OpenCode CLI — see https://opencode.ai/docs/.
  2. Create an OpenRouter account and API key at https://openrouter.ai/settings/keys.
  3. Authenticate OpenCode with OpenRouter — either interactively:
opencode auth login openrouter

or by setting OPENROUTER_API_KEY in the environment. Either way, kew does not see or manage the credential.

  1. Configure your OpenRouter account's data policy — see the next section — before dispatching real code.

Data policy prerequisites

OpenRouter routes each request to one of several underlying providers hosting the model you asked for, and those providers have varying data retention and training policies: some retain prompts for a period, some may train on inputs unless routing excludes them, and some offer zero-data-retention (ZDR) endpoints. See OpenRouter's provider logging documentation for the current per-provider details.

Since dispatched runs send your repository's code as prompt content, review these before pointing kew's fleet at OpenRouter:

  1. Set the account-level training opt-out. In your OpenRouter privacy settings, disable model training. OpenRouter then restricts routing to providers that honor that policy.
  2. Optionally pin routing to specific providers or ZDR. OpenRouter accepts per-request provider routing preferences (provider order, disallowing fallbacks, ZDR-only), and OpenCode can pass them through its provider config in opencode.json. For example, to pin a model to specific providers:
{
  "provider": {
    "openrouter": {
      "models": {
        "qwen/qwen3-coder": {
          "options": {
            "provider": {
              "order": ["Fireworks"],
              "allow_fallbacks": false
            }
          }
        }
      }
    }
  }
}

See OpenRouter's provider routing documentation for the available fields (including ZDR enforcement) and OpenCode's config docs for where opencode.json lives.

  1. Enterprise / EU residency. OpenRouter's enterprise plan offers an EU in-region base URL so requests are processed on in-region infrastructure. If you have data-residency requirements, that option exists — talk to OpenRouter.

None of this is unique to OpenRouter — any hosted model has a data policy — but because OpenRouter fans out across many providers, the account-level settings above are the difference between "one policy you chose" and "whichever provider happened to serve the request".

Selecting a model

Use the three-segment form openrouter/<vendor>/<model> anywhere kew accepts a model — the openrouter/ prefix routes to the OpenCode runner, and multi-segment paths are supported:

[agent]
model = "openrouter/qwen/qwen3-coder"

Or route by complexity tier:

[routing]
default = "claude-code"
simple  = { runner = "opencode", model = "openrouter/qwen/qwen3-coder" }

Cost semantics

OpenRouter pricing is consumption-based and varies per provider — the same model can cost more or less depending on which underlying provider serves the request. Kew handles this in two layers:

  • Preflight estimates are priced from a committed pricing snapshot (feature in progress, #1068), so budget gates evaluate against known list prices rather than a live lookup.
  • Actual spend is runner-reported and recorded per run, as with every other runner — see cost & honesty across runners.

Until the snapshot ships, governed dispatch of a model kew cannot price fails closed by design: an unpriceable model does not pass the budget gate. That is deliberate — no spend kew can't bound.

Next

  • OpenCode runner — the runner OpenRouter dispatch goes through, including resume support and limitations.
  • Configuration — the [routing] and [agent.opencode] sections.