Skip to content

Migration guidesFrom OpenRouter

From OpenRouter, with OpenRouter still in the picture if you want it

OpenRouter gives one account and one key for models from many vendors, paid from its credits, with your own provider keys as an option. INFRO is the other way round: every request runs on a provider account you hold. The two are not exclusive, because OpenRouter is one of the providers INFRO connects to. This page shows both moves: OpenRouter as one upstream among your direct accounts, or direct accounts only.

Stripe agreed to acquire it (announced 2026-08-19); no completion notice as of 2026-10-19

INFRO accounts are self-serve. The catalog, the docs, and the API contract are public, the gateway is deployed, and anything beyond v1 is marked Later. Plans and trial

Where things stand

Ownership

Stripe announced on 2026-08-19 that it has agreed to acquire OpenRouter. OpenRouter's own post says the name, product and roadmap stay and that integrations do not change. Neither company had published a completion notice when we read their pages on 2026-10-19.

Whose account serves the request

By default OpenRouter's own provider accounts, paid from prepaid credits. With BYOK, your provider key is tried first; OpenRouter's docs say it can fall back to its shared capacity on failure unless that is switched off per key.

What moves

Base URL and key; models to fallbacks; provider routing to routes or routing.providers; user, session_id and trace to metadata or INFRO headers. HTTP-Referer and X-OpenRouter-Title come out.

OpenRouter solves access: one account, many vendors. If that is the problem you have, it is the right product, and you can still put INFRO in front of it.

  • You do not want an account with each vendor. INFRO only runs on accounts you hold, so every model you call needs a provider account behind it (OpenRouter's can be one of them).
  • You choose among many hosts of open-weight models by price, throughput or latency per request (provider.sort, max_price). INFRO has no per-request price or latency sorting; a route sets the order.
  • You rely on openrouter/auto or presets that carry a system prompt and parameters. INFRO's closest thing is a route with a prompt classifier, which picks targets, not prompts.
  • You need EU in-region routing today. INFRO's residency is on the roadmap, not available.

The edits, one row each. Everything not listed here stays as it is.

 OpenRouterINFRO
Base URLhttps://openrouter.ai/api/v1https://api.infro.io/v1
KeyAn OpenRouter key; your provider keys optionally added as BYOK.An INFRO gateway key. Your provider accounts (and your OpenRouter key, if you keep it) are connections in the console.
Model idvendor/model, ~vendor/...-latest, openrouter/auto, @preset/name.vendor/model from INFRO's catalog, or a route name. GET /v1/models lists what your connections serve. Some vendor prefixes differ from OpenRouter's (INFRO's xai/, OpenRouter's x-ai/).
Body fieldsmodels, provider { order, only, ignore, sort, max_price }, user, session_id, trace.fallbacks (up to 5), routing.providers { allow, deny }, metadata { user_id, session_id, tags }; X-INFRO-Trace-Id for a trace id.

Before · OpenRouter

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://openrouter.ai/api/v1",
  apiKey: process.env.OPENROUTER_API_KEY,
  defaultHeaders: { "X-OpenRouter-Title": "Example App" },
});

await client.chat.completions.create({
  model: "anthropic/claude-sonnet-5.5",
  messages: [{ role: "user", content: "Hello" }],
  user: "user_123",
  // @ts-expect-error OpenRouter extensions
  models: ["anthropic/claude-sonnet-5.5", "openai/gpt-5.6-terra"],
  provider: { order: ["anthropic", "google-vertex"] },
});

After · INFRO

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.infro.io/v1",
  apiKey: process.env.INFRO_API_KEY,
});

await client.chat.completions.create({
  model: "anthropic/claude-sonnet-5.5",
  messages: [{ role: "user", content: "Hello" }],
  // @ts-expect-error INFRO extensions
  fallbacks: ["openai/gpt-5.6-terra"],
  routing: { providers: { allow: ["anthropic", "google-vertex"] } },
  metadata: { user_id: "user_123" },
});

Order lives in a route

routing.providers narrows which of your providers may serve a request; it does not set the order. For a fixed order, create a route (say chat-default) with your targets in sequence and send it as model.

Keeping OpenRouter behind INFRO

Connect your OpenRouter key as a provider in the console. Requests can then fail over from your direct accounts to OpenRouter, and routing.providers with openrouter in allow or deny includes or excludes it per request.

Fallback triggers

fallbacks are tried after every connection for model has failed. A provider error after the response has started streaming is returned, not re-routed.

OpenRouter's objects against INFRO's, from OpenRouter's public documentation read on 19 October 2026 and checked against what the gateway implements. Two rows say INFRO has nothing.

OpenRouterWhat it does thereIn INFRO
OpenRouter key and creditsdifferentOne key for every model, paid from prepaid credits.A gateway key over provider accounts you connect; each provider bills you directly. INFRO charges a subscription and adds 0% to model spend.
BYOKdifferentYour provider keys, tried first; shared-capacity fallback unless switched off per key.The only mode. No shared capacity behind the gateway: if every connection fails, the request fails.
`models` fallbackssame shapeA priority list of models tried on error.fallbacks, up to 5 model ids tried after every connection for model has failed.
`provider` order, only, ignoredifferentPick, order and exclude upstream providers per request.routing.providers allow or deny per request; the order is set on a route, with failure rules per kind (429, 5xx, timeout).
`provider.sort`, `max_price`, throughput and latency preferencesnothingChoose a host per request by price, throughput or latency.Nothing. INFRO does not choose between hosts by price or latency; a route's order or weights decide.
Auto routerdifferentopenrouter/auto picks a model per prompt.A route can classify each prompt with a decision model on your own connection and send each class to its own targets.
PresetsdifferentNamed server-side config: model, routing, system prompt, parameters.Routes carry the model and the targets. System prompts and parameters stay in your code.
Response cachingsame shapeExact-match cache per key via X-OpenRouter-Cache headers.An opt-in, exact-match cache for chat completions, with a namespace and TTL.
Guardrails (budgets, allowlists)same shapeSpend caps and model or provider allowlists per workspace, member or key.Budgets at organization, project, member, key and end customer that refuse with 402 before the call; allow and block lists per organization, project and key.
BroadcastdifferentTraces exported to Langfuse, Datadog, an OTel collector, S3 or a webhook.Spans to your OpenTelemetry collector, request exports and the request log. No built-in destinations for specific vendors.
Cost per requestdifferentCost per generation at the price OpenRouter lists.An estimate of your provider's bill on every response (usage.cost, usage.price_source): your negotiated rate where you entered one, the vendor's list rate otherwise, and unpriced rather than zero when neither is known.
EU in-region routing, ZDR endpointsnothingAn EU base URL and a filter for zero-data-retention endpoints.Not available. Region pinning is on the roadmap; retention at the provider is governed by your own contract with it.

Our reading of OpenRouter’s published documentation, not a trial or a benchmark. If we have read something wrong, tell us and we will fix the row.

What INFRO does not do

  • Give you access to a vendor you have no account with, except through a connection to an aggregator account you hold (OpenRouter's included).
  • Choose a host per request by price, throughput or latency.
  • Store system prompts and parameters server-side (presets).
  • Pin traffic to the EU; residency is on the roadmap.
  • Serve embeddings.

What does not come across

  • Your OpenRouter activity history and generation logs. There is no importer.
  • Credits. They stay on your OpenRouter account and are spent only if you keep OpenRouter as a connection.
  • Presets, workspaces and guardrails. Recreate them as routes, projects, budgets and allowlists.

Questions

Can I keep OpenRouter and add INFRO?
Yes. OpenRouter is a provider kind in INFRO: connect your OpenRouter key and it serves requests next to your direct accounts, with failover between them.
Does INFRO sell credits or resell model access?
No. INFRO runs every request on a provider account you hold, your providers bill you directly, and INFRO charges a subscription with 0% markup on model spend.
What replaces the `models` and `provider` fields?
fallbacks replaces models; routing.providers allow and deny replaces provider.only and provider.ignore; a named route sets the order. Price and latency sorting has no equivalent.

Move with us, or on your own

The migration program maps your OpenRouter setup to INFRO connections, routes and budgets on a call and moves the first service with you. Your providers keep billing you directly; INFRO is a subscription and adds 0% to model spend.

Start 14-day trial Book a migration sessionINFRO vs OpenRouterRead the quickstart

Sources

Every statement on this page about OpenRouter comes from one of these, read on 19 October 2026. Nothing is inferred from a trial, a benchmark, or a conversation.