DEV Community: Felix

What is an AI gateway, and what makes one European? OpenRouter vs Opper

Felix — Sat, 14 Nov 2026 02:43:34 +0000

An AI gateway is a single API between your app and many LLM providers. Without one, you end up rebuilding the same plumbing: a key per provider, an SDK per provider, retries, fallbacks, and a bill from everyone. A gateway puts all of that behind one endpoint.

A European AI gateway is one that runs in Europe, specifically the EU, and can keep your requests there, from the gateway itself to the model that answers.

This is a short, high-level comparison. I use OpenRouter and Opper as the two examples because they keep requests in the EU in different ways, and you can try both with the same OpenAI SDK.

What an AI gateway does

One endpoint, many models. You send an OpenAI-style request and pick the model by name, and the gateway forwards it to a provider that serves it.
Failover. The same open-weight model is often served by several providers, so if one is down or rate-limited the gateway retries on another.
One key and one bill. Your app holds one gateway key instead of ten provider keys, and spend shows up in one place.
Routing preferences. Cheapest, fastest or highest-throughput provider first, depending on what you ask for.

That covers most "should I use a gateway" decisions. Where it gets interesting is the data.

What makes a gateway European

"EU-hosted" gets used loosely. In practice there are four separate questions:

Where does the gateway run, and under which company? Every prompt passes through it.
Where does inference run? The same model can be served from the EU by one provider and from the US by another.
What does the provider keep? Logging, retention and training on prompts differ per provider, not per model.
What happens when the allowed route is down? The safe behaviour is to refuse the call. The common failure is a silent fallback to a provider in another region, which is exactly what failover is built to do.

Point 4 is the one people miss. Failover and data residency pull in opposite directions, so a European setup needs a way to say "fail over, but only inside this boundary".

OpenRouter and Opper side by side

	OpenRouter	Opper
Company	Stripe (US), which acquired OpenRouter in 2026	Opper Technology AB, Stockholm, Sweden
OpenAI-compatible base URL	`https://openrouter.ai/api/v1`	`https://api.opper.ai/v3/compat`
Keeping a request in the EU	Call the EU endpoint `https://eu.openrouter.ai/api/v1`, Business and Enterprise plans only	Call an EU-hosted route on any account, or set a model access rule
Per-request data controls	`provider.zdr`, `provider.data_collection`, `provider.only` / `ignore`	The route you call, `provider/model`
Org-wide enforcement	Privacy settings on the account	Model access rule on the org or a project
No eligible route left	The request errors instead of leaving the region	Refused with `403` before it reaches a provider
Fee on credit purchases	5.5%, or 8% on Business, which the EU endpoint needs	3%, EU-hosted routes included (5.5% with Control Plane rules)

On OpenRouter you don't pick a European model for this. You call the EU endpoint with the usual model id, and it only uses provider endpoints in the EU/EEA, the UK or Switzerland, so fewer models are available than on the global endpoint.

Both fail closed, which is the right call. The difference is where the boundary lives. OpenRouter draws it at the endpoint you call. Opper draws it in a rule on your org or project, so every key and every app under it inherits the same boundary. One more detail from OpenRouter's own docs: with the EU endpoint, prompts and completions stay in the region, while account, billing and other operational records may be processed in the US.

The same request on both

Both speak the OpenAI API, so switching is a base URL and a model name.

OpenRouter, EU endpoint, zero data retention providers only:

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://eu.openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
)

resp = client.chat.completions.create(
    model="mistralai/mistral-small-2603",
    messages=[{"role": "user", "content": "Summarise GDPR Article 28 in two sentences."}],
    extra_body={"provider": {"zdr": True, "data_collection": "deny"}},
)
print(resp.choices[0].message.content)

Opper, an EU-hosted route:

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.opper.ai/v3/compat",
    api_key=os.environ["OPPER_API_KEY"],
)

resp = client.chat.completions.create(
    model="mistral/mistral-small-2603",  # Mistral Small on Mistral's own EU route
    messages=[{"role": "user", "content": "Summarise GDPR Article 28 in two sentences."}],
)
print(resp.choices[0].message.content)

On Opper the model id carries the route as provider/model, and each route's data policy is in the public catalogue. https://api.opper.ai/v3/models?q=mistral-small-2603 lists every route for that model, and for the one above it returns "inference_location": "EU", "training": "no" and "logging": "none".

To make it a rule rather than a habit, a model access rule allowlists EU inference locations for the whole org or a project. A call that names a US route then comes back as:

403 model "anthropic/claude-sonnet-5" is blocked by the active model allowlist: inference location US is outside EU

A bare model name, like mistral-small-2603 without a provider, still fails over, but only across the allowed routes, and it's refused with 403 if none are left. That's point 4 handled in one place.

How to pick

You want the biggest community and the most integrations: OpenRouter is hard to beat.
You need EU processing on OpenRouter: that means the Business plan, with an 8% fee on every credit purchase against Opper's 3%, and their docs say operational data may still be processed in the US.
You want the gateway company, the gateway and inference in Europe, with one rule your whole org inherits: that's the case Opper is built for.
Whichever you pick: test point 4 yourself. Block a region and see whether the call fails or quietly goes somewhere else.

Docs if you want to dig in: OpenRouter EU in-region routing, Opper model access rules.

Codex CLI with any model: the "codex router" setup in one config block

Felix — Tue, 25 Aug 2026 09:18:02 +0000

OpenAI's Codex CLI is a genuinely good coding agent, but out of the box it runs OpenAI models on OpenAI billing. Sometimes you want Claude Opus for a gnarly refactor, Kimi K2.7 Code for cheap long sessions, or a model served from EU infrastructure because your client asks where tokens go.

What most people miss: Codex has custom providers built in. It speaks the Responses API to whatever base_url you give it, so any gateway that implements the Responses API can act as the router behind Codex. No forks, no proxies, one config block.

Option 1: the config block

Codex reads ~/.codex/config.toml. Add a provider and a profile:

[model_providers.opper]
name = "Opper"
base_url = "https://api.opper.ai/v3/compat"
env_key = "OPPER_API_KEY"
wire_api = "responses"

[profiles.opus]
model = "anthropic/claude-opus-4-7"
model_provider = "opper"

[profiles.kimi]
model = "moonshot/kimi-k3"
model_provider = "opper"

I'm using Opper here (disclosure: I work there), an EU-hosted gateway with 700+ models behind one API key that implements the Responses API. Export the key and launch with a profile:

export OPPER_API_KEY="your-key"
codex --profile opus

That's the whole router. Yes, that means Claude running inside OpenAI's own CLI, which never stops being funny.

Option 2: one command

If you don't want to touch config files, the Opper CLI writes exactly that block for you (with sentinel markers, so it never clobbers your existing config and can cleanly remove itself):

npm install -g @opperai/cli
opper launch codex

It detects Codex (installs it with --install if missing), configures the provider, and starts it with preset profiles. opper launch codex --model moonshot/kimi-k3 picks a model at launch.

Which models actually make sense in Codex

openai/gpt-5.3-codex: the model Codex was built for, via API billing. Honest note: if you already have a ChatGPT plan, Codex is included there and that's the cheaper path for this one model. The router play is for everything else.
anthropic/claude-opus-4-7 / claude-sonnet-4-6: the most common reason people set this up at all.
moonshot/kimi-k3 and alibaba:global/kimi-k2.7-code: strong coding output per dollar for long agent sessions.
EU variants like vertexai/gemini-3.7-flash-eu or Claude on European Vertex regions, if tokens staying in Europe is a requirement and not a preference.

The full catalogue with per-model pricing, context windows and hosting regions is at opper.ai/models. Every route is labeled with where it runs and what the retention posture is, which is the part my compliance-minded clients actually care about.

The fine print

Codex talks to custom providers over the Responses API (wire_api = "responses"). Chat-completions-only gateways need wire_api = "chat", which Codex also supports, but Responses is the native path and what I tested here.
Billing on the gateway side is pay-as-you-go at provider token rates, and only successful responses are billed, so a failed request that retries elsewhere doesn't double-charge.

If you hit something weird with a specific model, tell me in the comments, I run this setup daily.

Claude Code with any model: three ways to route it (incl. the 2-minute one)

Felix — Thu, 20 Aug 2026 16:29:41 +0000

Claude Code is the best agentic coding interface right now, but out of the box it only talks to Anthropic's API with Anthropic billing. Sometimes you want the same interface with a different brain: Kimi K3 for cheap long sessions, GPT-5.4 to cross-check a plan, Gemini 3.7 Flash for speed, or simply a model that runs on EU infrastructure because your client requires it.

There are three ways to do this. I'll go from most configurable to least effort.

Option 1: claude-code-router

claude-code-router is the community answer, and it's genuinely powerful: per-task routing rules, request transformers, plugins. If you want "background tasks go to a cheap model, planning goes to a big one," this is your tool.

The tradeoff is that you run and maintain a local proxy with a JSON config, and you still need API keys for every provider you route to. For a team setup that's real overhead.

Option 2: point Claude Code at an Anthropic-compatible gateway

Claude Code respects two environment variables, which means any gateway that speaks the Anthropic Messages API can sit behind it. I work at Opper, an EU-hosted gateway that serves 700+ models through one API key, so that's what I'll use:

export ANTHROPIC_BASE_URL="https://api.opper.ai/v3/compat"
export ANTHROPIC_AUTH_TOKEN="<your-opper-api-key>"
claude

That's the whole setup. Because the gateway also implements Anthropic's model-listing endpoint, the /model picker inside Claude Code shows the live catalogue, so you can switch to moonshot/kimi-k3, openai/gpt-5.4 or gemini/gemini-3.5-flash mid-session instead of editing config files.

Two things I like about this over a local proxy: there's nothing running on your machine, and billing is unified, one balance across every model with token prices matching what the providers charge.

Option 3: one command

If you don't want to manage env vars at all, the Opper CLI wires everything for you:

npm install -g @opperai/cli
opper launch claude

opper launch starts Claude Code with its inference already routed through the gateway. Pick a model at launch if you want:

opper launch claude --model moonshot/kimi-k3

Anything after the agent name is forwarded to Claude Code verbatim, so opper launch claude --resume works exactly as you'd expect.

The EU angle

If you build for European customers, this setup solves a second problem for free. Opper runs in the EU, and the catalogue marks which routes are EU-hosted, including EU variants of frontier models (for example vertexai/gemini-3.7-flash-eu, or Claude served from European Vertex regions). Same Claude Code workflow, but the tokens don't leave Europe, which is the difference between "we should check with legal" and "approved" in a lot of B2B contexts.

Which one should you use?

You want per-task routing rules and love config: claude-code-router
You want zero local moving parts and model switching from inside Claude Code: the two env vars
You want the shortest path: opper launch claude

The full model catalogue with prices and EU/US hosting per route is at opper.ai/models. If you try this and something breaks, tell me in the comments, I maintain this setup daily.