OpenRouter: egy API-kulcs a katalógus minden modellje előtt

Az OpenRouter egy hosztelt útválasztó réteg a modell-API-k előtt: egyetlen OpenAI-kompatibilis végpont, amely minden kérést ahhoz a szolgáltatóhoz továbbít, amelyik az adott modellt kiszolgálja. Saját modellt nem üzemeltet, a díjszabási oldal szerint az inference a szolgáltató listaáron megy, a platformdíj pedig a credits vásárlásakor keletkezik. Ennek az értékelésnek az álláspontja: ez a legolcsóbb módja annak, hogy egy változó katalógust egy kulcs mögé tereljünk — és a legdrágább függőség, amit később le lehet bontani, miután minden szolgáltatás ezt a dialektust beszéli.

Azt a helyet foglalja el, amit egy önállóan üzemeltetett gateway foglalna, és a LiteLLM-mel, a Portkeyvel és azzal a szokással versenyez, hogy minden szolgáltatót külön hívunk meg. A különbség a felelősségben van, nem a funkciókban. A gateway egy folyamat, amit telepítenek, patchelnek és skáláznak; az OpenRouter egy szolgáltatás a termék minden hívásának útvonalán — a rendelkezésre állás, az adatkezelés és az árazás így valaki más problémája lesz. Éppen ezt vesszük meg.

Mi ez

A cég 2023 óta terel forgalmat, és a terméket száz modellre kiterjedő egységes felületként írja le. A dokumentált felület szándékosan kicsi: egy végpont, egy kulcs, egy modell-slug és néhány opcionális routing-jelzés. A szolgáltatók állapota, az ár-összehasonlítás és a failover mind a hívás túloldalán történik.

• Kizárólag hosztelve: önállóan üzemeltetett kiadás nincs, a termék a(z) https://openrouter.ai/api/v1 végpont.
• 500+ modell 80+ szolgáltatótól a fizetős csomagokon; a Free csomag 25+ ingyenes modellt kínál 4 szolgáltatótól.
• OpenAI-kompatibilis chat completions, emellett Anthropic messages útvonal, Responses API, embeddingek és batch-ek.
• Modell-fallback egy models listával: a következő modell jön, ha az első hibát ad, rate limitet kap vagy a moderáció elutasítja.
• Szolgáltató-szabályozás kérésenként — order, only, ignore, kvantálási szűrők, valamint rendezés ár, throughput vagy késés szerint.
• Bring-your-own-key útválasztás: a szolgáltatókulcs havi 25 000 USD listaárnyi inference-éig OpenRouter-díj nélkül.
• Activity naplók exporttal minden csomagon, generációnkénti rekordok, valamint trace-export Datadogba, Grafana Cloudba, Langfuse-be, OpenTelemetrybe, Snowflake-be vagy webhookra.

Hogyan működik

Az alapértelmezett stratégia ár-alapú load balancing. A router először kihagyja az elmúlt 30 másodpercben komoly kimaradást szenvedett szolgáltatókat, majd a stabilok közül az ár négyzetének reciprokával súlyozva választ, a többit tartalékul hagyja: 1 USD-s és 3 USD-s végpont között a olcsóbb kilencszer nagyobb eséllyel jön előbb. A explicit sort vagy order ezt a kiegyenlítést kapcsolja ki — ez az a kapcsoló, amely a költségoptimalizáló routerből kiszámíthatóvá teszi.

Az egy lépés ára

Minden hívás most két hálózaton megy át, nem egyen. A díjszabási GYIK kimondja, hogy a routing a megbízhatóságot javítja, a késés viszont modelltől, szolgáltatótól és régiótól függ, a stabil késésre adott tanács pedig: rögzítse a modellt és a szolgáltatót. A plusz lépés elhanyagolható egy másodpercekig tartó generálás mellett, és nem elhanyagolható egy szubszekundumos osztályozás mellett: a rögzítés a közvetlen API viselkedését adja plusz egy oda-vissza úttal.

A közbeiktatás ott marad látható, ahol számít. A válasz megnevezi a ténylegesen kiszolgáló végpontot, és egy opcionális header minden válaszban megmutatja a routing-döntést, így a váratlan szolgáltató egy naplósorban jelenik meg, nem egy ügyfélpanaszban.

• sort: price, throughput vagy latency, és kikapcsolja a load balancinget.
• order: explicit szolgáltató-sorrend, allow_fallbacks false-zal, ha semmi más nem próbálható.
• require_parameters: csak olyan szolgáltató, amely a kérés minden paraméterét támogatja — a strukturált kimenetek és a tool-hívások nem értékelődnek alul csendben.
• zdr és data_collection: csak zero-data-retention végpontokra vagy csak nem tároló szolgáltatókra routing.

Első lépések

Egy kulcs és egy POST. Az ingyenes fiók azonnal működő végpontot kap: az ingyenes modelleknél percenként 20, naponta 50 kérés a limit, a napi keret pedig 1 000re nő, miután a fiók legalább 10 USD creditsért vásárolt.

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "models": ["~openai/gpt-sol-latest", "~anthropic/claude-sonnet-latest"],
    "messages": [
      { "role": "user", "content": "Summarise this stack trace in one sentence." }
    ],
    "provider": {
      "sort": "price",
      "require_parameters": true
    }
  }'

A válasz OpenAI-alakban érkezik, a model mező pedig megnevezi a ténylegesen kiszolgáló végpontot — ez alapján számlázzák a kérést, akár elsőként szerepelt a listán. A meglévő OpenAI-kliensnek csak más base URL kell; a dokumentáció ugyanezt a cserét mutatja Pythonban és TypeScriptben.

Árazás

Nincs előfizetés, nincs minimum, nincs lekötés. A creditsot kártyával, AliPayjal vagy USDC-vel vásárolják előre, minden kérés a szolgáltató listaárát vonja le az egyenlegről; a platformdíj — 5,5% Standard, 8% Business — a vásárláskor keletkezik, kérésenként soha.

• Free: 25+ ingyenes modell, 4 szolgáltató, activity napló exporttal, naponta 50 kérés az ingyenes modelleknél. Nincs auto-routing, nincs költségkeret, nincs prompt caching.
• Standard: mind az 500+ modell és 80+ szolgáltató 5,5% díjjal a credits-vásárlásokra, auto-routinggal, költségkeretekkel, prompt cachinggel, management API-kulcsokkal és öt workspace-szel.
• Business: ugyanaz a katalógus 8%-kal, EU-s vagy US-széles in-region routing eu.openrouter.ai és us.openrouter.ai címen, 1 000 workspace és workload identity federation.
• Enterprise: szerződött díjak, számlázás, SSO és SCIM, szerződéses SLA, valamint havi 200 000 USD BYOK-listaárnyi inference 5%-os felár előtt.

Vezérlés

Csapatoknál a lényeg nem a request bodyban van. A workspaces, a költségkeretek és a guardredek döntik el, hogy ki milyen kulccsal mire hívhat — és a platformban élnek, nem a saját kódban. Éppen ez az értelmük: a szabályváltozás már nem deploy.

• A workspaces elválasztják a környezeteket: öt Free és Standard alatt, 1 000 Businesson, egyenként saját kulcsokkal és limitekkel, plusz credits-cap kulcsonként.
• A guardredek kulcsokhoz vagy tagokhoz kötődnek, és a költést, a modellhozzáférést, a prompt-injection mintákat és az érzékeny adatok szabályait fedik le.
• A management API-kulcsok programozottan hoznak létre, listáznak és törölnek kulcsokat — a kulcs életciklusa így a CI-be kerül, nem szokássá a dashboardon.
• A Broadcast tracet küld Datadogba, Grafana Cloudba, Langfuse-be, OpenTelemetrybe, Sentrybe, Snowflake-be vagy bármely HTTP-végpontra, így a költés összekapcsolható a többi rendszerrel.

A zero data retention minden csomagon fut, fiók- vagy kérés szinten zdr-rel. A regionális tartózkodás az a funkció, ami nem ingyenes: a promptok és válaszok EU-n vagy USA-n belül tartása a Business csomagtól indul, így szabályozott terhelésnél a 8%-os csomag az alap, nem a feljebb lépés.

Hol nyikorog

A gyengeségek szerkezetiek. Minden kérés egy harmadik fél rendelkezésre állásától függ, a routing-döntés pedig láthatatlan marad, amíg a metadata header be nem kapcsol. Ugyanannak a modellnek a szolgáltatói eltérően támogatják a paramétereket, így ami az egyik végponton működik, a másikon csendben leépülhet, ha nincs require_parameters. A szolgáltatói árváltozások átmennek — a GYIK szerint az új díjszabás szerint számlázzák —, az ingyenes sávot pedig rate limit korlátozza, nem nagylelkűség. És ott a tulajdonlás: a Bloomberg és a Wall Street Journal 2026 augusztusában arról számolt be, hogy a Stripe megállapodott a felvásárlásról — emlékeztető arra, hogy a kérési útvonalban lévő rétegnek gazdája van.

Az összehasonlítás, ami számít, a felelősségről szól, nem a funkciókról. Az OpenRouter elveszi az üzemeltetést, és hozzátesz egy százalékot meg egy függőséget; a LiteLLM megtartja a kulcsokat és a terhelést a saját infrastruktúrában; az első féltől származó API adja a legrövidebb utat és a legkevesebb fedezetet, ha egy modell elérhetetlen. Egy olyan terméknél, amely gyakrabban vált modellt, mint másik árat, a fedezet többet ér a díjnál.

Ítélet

Az OpenRouter azt válaszolja meg, hogyan kaphat sok agent, szolgáltatás és csapat hozzáférést a gyorsan változó modellkatalógushoz gateway üzemeltetése nélkül. Azt nem válaszolja meg, hogyan birtokolja valaki a kérési utat.

1. Válassza, ha a modellkatalógus gyorsabban változik, mint a integráció: egy végpont és egy models lista a beszállítói értékelést konfigurációs értékké alakítja.
2. Válassza agentes és coding-agentes terhelésre, ahol a számla sok modellre terjed ki, és egy exportálható activity napló többet ér négy szolgáltatói dashboardnál.
3. BYOK-et használjon, ha a szerződés vagy az adatszabály közvetlen szolgáltatói kapcsolatot kíván; a routing és az analitika megmarad, a havi 25 000 USD listaárnyi inference díjmentes.
4. Hagyja el olyan késésérzékeny útvonalakon, ahol nem rögzíthető a szolgáltató: a rendelkezésre állási routing maga a termék, és a végpontot váltó kérés olyan farok-késés, amit senki sem kontrollál.
5. Hagyja el, ha egy szolgáltató és egy modell az egész termék: a szolgáltató SDK-ja, a közvetlen számlázás és a közvetítői százalék kevesebb gépezet ugyanahhoz a híváshoz.

„Az inference minden csomagon a szolgáltató listaáron megy.” a díjszabási oldal A díj kicsi és átlátható; a függőség az, amit be kell árazni — és az egyik listán sem szerepel.

Források

1. OpenRouter-dokumentáció: quickstart
2. OpenRouter-díjszabás
3. OpenRouter-dokumentáció: modell-fallback
4. OpenRouter-dokumentáció: szolgáltatói routing
5. OpenRouter-dokumentáció-ág
6. Wikipédia: OpenRouter