W pewnym momencie projekt korzystający z AI zaczyna wyglądać tak: osobny klucz do OpenAI, drugi do Anthropic, trzeci do Google, kilka różnych SDK, różne formaty żądań i osobne rozliczenia.
Da się z tym żyć. Do czasu.
Problem zaczyna się wtedy, gdy chcesz zmienić model, dodać fallback albo przestać wiązać całą aplikację z jednym dostawcą. OpenRouter próbuje rozwiązać właśnie ten problem. Udostępnia jeden endpoint HTTP, przez który można korzystać z modeli wielu dostawców.
Zamiast kilku integracji masz jeden klucz, jeden format żądania i jedno rozliczenie.
Według oficjalnego API OpenRouter udostępnia obecnie 397 modeli. Lista modeli obejmowała pozycje od 59 autorów, między innymi OpenAI, Qwen, Google, Anthropic, Mistral, DeepSeek czy Meta. Za nimi stoi dodatkowo 104 dostawców infrastruktury, czyli miejsc, w których modele są faktycznie uruchamiane.
| Co liczymy | Liczba |
|---|---|
| Modele według oficjalnego licznika API | 397 |
| Autorzy modeli | 59 |
| Dostawcy infrastruktury | 104 |
To rozróżnienie jest ważne. Model i dostawca nie oznaczają tutaj tego samego. Ten sam model może być obsługiwany przez więcej niż jeden endpoint, a OpenRouter może wybrać pomiędzy nimi. Sama możliwość sięgnięcia po wiele modeli przez jedno API jest wygodna, ale prawdziwa wartość siedzi właśnie w tym wyborze: w routingu, doborze dostawcy i automatycznym fallbacku.
Jak to działa
OpenRouter udostępnia API pod adresem:
1https://openrouter.ai/api/v1
Dla czatu podstawowym endpointem jest:
1POST /api/v1/chat/completions
OpenRouter opisuje swoje API jako zamiennik zgodny z OpenAI, więc SDK obsługujące OpenAI zadziała również tutaj po zmianie adresu bazowego i klucza. Konfiguracja klienta sprowadza się do wskazania innego base_url.
Python1 2 3 4 5 6from openai import OpenAI client = OpenAI( base_url="https://openrouter.ai/api/v1", api_key="OPENROUTER_API_KEY" )
Nie oznacza to jednak stuprocentowej zgodności każdego szczegółu. Sama dokumentacja OpenRoutera zaznacza, że schemat jest bardzo podobny do OpenAI Chat API, ale występują niewielkie różnice.
Obowiązkowy jest nagłówek:
HTTP1Authorization: Bearer OPENROUTER_API_KEY
Aplikację można dodatkowo oznaczyć nagłówkami:
HTTP1 2HTTP-Referer: https://example.com X-OpenRouter-Title: Example App
W starszych materiałach można znaleźć X-Title. Nadal jest wspierany dla zgodności wstecznej, ale aktualnym nagłówkiem jest X-OpenRouter-Title.
Streaming działa przez stream: true i SSE. Strumień kończy się znacznikiem [DONE], a przed nim OpenRouter przesyła chunk zawierający informacje o użyciu.
Tool calling korzysta z formatu znanego z OpenAI, czyli między innymi tools i tool_choice. OpenRouter normalizuje ten mechanizm pomiędzy dostawcami. Obsługiwane są również równoległe wywołania narzędzi oraz tool calling w streamingu.
API obsługuje też dane multimodalne. Obrazy można przekazywać przez image_url, jako URL albo base64, a PDF-y przez typ file.
OpenRouter dodaje też własne parametry, których nie znajdziesz w standardowym API OpenAI, między innymi:
1 2 3 4 5models provider route plugins zdr
I to właśnie one pozwalają sterować routingiem i prywatnością.
Ile to kosztuje
Tutaj pojawia się najczęściej powtarzany błąd w opisach OpenRoutera.
OpenRouter nie dolicza 5,5% marży do ceny inferencji.
Dokumentacja mówi wprost, że nie ma narzutu na ceny inferencji. Za tokeny płacisz według stawki dostawcy.
Opłata pojawia się przy kupowaniu kredytów.
| Element | Pay-as-you-go |
|---|---|
| Narzut na cenę inferencji | 0% |
| Platform fee przy zakupie kredytów | 5,5% |
| Abonament | brak |
Zamieszanie bierze się z samej strony z planami, gdzie te 5,5% figuruje w tabeli jako „Platform Fees". Bez doczytania wyjaśnienia łatwo uznać, że to prowizja doliczana do każdego zapytania. Dokumentacja cenowa precyzuje jednak, że opłata pobierana jest przy zakupie kredytów.
OpenRouter działa więc w modelu kredytowym. Kredyty są rozliczane w dolarach i można je doładowywać ręcznie lub przez auto-top-up.
Nie ma standardowych rabatów wolumenowych. Niewykorzystane kredyty mogą wygasnąć po roku.
OpenRouter obsługuje również BYOK, czyli używanie własnych kluczy dostawców. W planie Pay-as-you-go pierwsze 25 000 USD miesięcznej inferencji według cen katalogowych przechodzi bez dodatkowej opłaty BYOK, a powyżej tego poziomu pobierane jest 5%. W Enterprise próg wynosi 200 000 USD.
Jest też mechanizm Zero Completion Insurance. Jeżeli odpowiedź kończy się zerową liczbą tokenów wyjściowych i pustym albo błędnym finish_reason, OpenRouter nie nalicza opłaty za model. Nie obejmuje to jednak wszystkich dodatkowych usług. Web search, OCR i web fetch mogą zostać naliczone również wtedy, gdy później odpowiedź modelu zakończy się błędem.
Routing i fallback
To jest część OpenRoutera, która ma większe znaczenie niż sama liczba dostępnych modeli.
W zwykłej integracji wybierasz konkretnego dostawcę i wysyłasz do niego żądanie. Jeżeli endpoint przestaje odpowiadać albo zostaje objęty limitem, problem trafia do Twojej aplikacji.
OpenRouter może wstawić pomiędzy aplikację a dostawcę warstwę routingu.
Domyślnie najpierw odrzuca dostawców, u których w ciągu ostatnich 30 sekund wystąpiła istotna awaria. Następnie wybiera pomiędzy pozostałymi endpointami, preferując tańsze.
Nie jest to proste sortowanie po cenie. Waga wyboru jest odwrotnie proporcjonalna do kwadratu ceny, więc według przykładu z dokumentacji dostawca kosztujący 1 USD za milion tokenów będzie wybierany dziewięć razy częściej niż ten za 3 USD. Pozostałe endpointy zostają dostępne jako fallback.
Zachowanie można kontrolować przez obiekt provider. Dostępne są między innymi:
1 2 3 4 5 6 7 8 9order allow_fallbacks require_parameters data_collection only ignore quantizations sort max_price
Możesz więc ograniczyć listę dostawców, wykluczyć część z nich, wymagać obsługi konkretnych parametrów albo sortować endpointy według ceny, przepustowości lub opóźnienia.
Jest tu jeden haczyk: ustawienie sort albo order wyłącza standardowy load balancing, a router przechodzi wtedy po endpointach w narzuconej kolejności.
OpenRouter ma dwa poziomy fallbacku.
Pierwszy dotyczy dostawców. Jeżeli jeden dostawca zwróci błąd, żądanie może zostać skierowane do innego zdrowego endpointu obsługującego ten sam model, o ile ustawione filtry na to pozwalają.
Drugi poziom dotyczy samych modeli. Można przekazać tablicę models ułożoną według priorytetu, a gdy pierwszy zwróci błąd, OpenRouter próbuje następnego. Uruchamia się to między innymi przy problemie z długością kontekstu, moderacją, rate limitingiem albo niedostępnością usługi.
Rozliczenie następuje według modelu, który faktycznie został użyty. Jego identyfikator wraca w polu model.
Jest również router openrouter/auto, który sam wybiera model bez dodatkowej opłaty, oraz sufiks :nitro, który sortuje dostępne endpointy według przepustowości.
Kurs Claude Code rusza jesienią. Chcesz wiedzieć pierwszy?
Zostaw e-mail, a napiszę do Ciebie pierwszego dnia sprzedaży — z ceną przedsprzedażową dla osób z listy. Bez zapychania skrzynki po drodze.
Modele darmowe i limity
OpenRouter udostępnia modele oznaczone sufiksem :free. W momencie weryfikacji API zwracało 18 modeli z takim sufiksem oraz 21 pozycji z ceną 0/0.
Jest też router:
1openrouter/free
Problemem są limity.
| Warunek | Limit |
|---|---|
Modele :free | 20 zapytań na minutę |
| Zakupione kredyty poniżej 10 USD | 50 zapytań dziennie |
| Zakupione łącznie co najmniej 10 USD | 1000 zapytań dziennie |
Dokumentacja określa limity darmowych modeli jako niskie i wprost zaznacza, że zwykle nie nadają się one do zastosowań produkcyjnych.
Zakładanie kolejnych kluczy API albo kont nie rozwiązuje tego problemu, bo limity są zarządzane globalnie na poziomie konta. Ujemne saldo blokuje przy tym również modele darmowe.
Po przekroczeniu limitu API może zwrócić błąd 429 wraz z nagłówkami X-RateLimit-Limit, X-RateLimit-Remaining oraz X-RateLimit-Reset. Jeżeli dostawca przekazuje taką informację, dostępny może być również Retry-After.
Czy Twoje prompty są logowane
OpenRouter loguje podstawowe metadane zapytań, takie jak czas wykonania, użyty model czy liczba tokenów.
Treść promptów i odpowiedzi nie jest domyślnie logowana.
Ustawienie „OpenRouter Use of Inputs/Outputs" jest domyślnie wyłączone. Można je włączyć, otrzymując w zamian 1% rabatu na użycie modeli.
Osobną kwestią jest przetwarzanie danych przez dostawców modeli.
W ustawieniach konta można wyłączyć routing do dostawców wykorzystujących dane do trenowania. OpenRouter udostępnia osobne ustawienia dla modeli płatnych i darmowych.
Da się również kontrolować to per request:
JSON1 2 3 4 5{ "provider": { "data_collection": "deny" } }
Jeżeli żaden dostawca nie spełnia ustawionych wymagań dotyczących prywatności, żądanie zakończy się błędem zamiast zostać wysłane do mniej restrykcyjnego endpointu.
Najostrzejszym mechanizmem jest ZDR, czyli Zero Data Retention. Można je ustawić na poziomie konta, klucza albo pojedynczego żądania:
JSON1 2 3{ "zdr": true }
Dostawca zgodny z ZDR nie powinien przechowywać danych przez żaden okres. Ograniczenie jest jedno, ale istotne: ZDR nie obejmuje pluginów i narzędzi.
Z czym się integruje
Ponieważ OpenRouter zachowuje dużą zgodność z API OpenAI, lista obsługiwanych narzędzi jest szeroka.
Oficjalna dokumentacja wymienia między innymi OpenAI SDK, LangChain, LlamaIndex, Vercel AI SDK, PydanticAI, Mastra, TanStack AI oraz Anthropic Agent SDK.
Wśród narzędzi pojawiają się Cline, Roo Code, Kilo Code, Aider, VSCode Copilot, Junie, Xcode, Zapier, Langfuse, Arize AX, LiveKit i Replit.
Dokumentacja zawiera też przykłady użycia z Claude Code, Cursor, Codex CLI oraz OpenCode.
OpenRouter udostępnia własne SDK dla Pythona, TypeScriptu i Go.
Osobnym przypadkiem jest n8n.
OpenRouter nie wymienia n8n na swojej oficjalnej liście integracji. Obsługę potwierdza natomiast dokumentacja n8n, która zawiera wbudowany credential OpenRouter oraz node Chat OpenRouter.
To rozróżnienie ma znaczenie, bo powtarzane w sieci zdanie o „oficjalnej integracji OpenRoutera z n8n" nie znajduje potwierdzenia w dokumentacji samego OpenRoutera.
Czego OpenRouter nie zrobi
OpenRouter nie usuwa wszystkich problemów związanych z korzystaniem z wielu dostawców.
Im więcej restrykcji ustawisz w routingu, tym bardziej ograniczasz pulę dostępnych endpointów. ZDR, data_collection: deny, only czy wymaganie konkretnej kwantyzacji mogą doprowadzić do sytuacji, w której żaden dostawca nie spełnia warunków. API zwróci wtedy 503.
Ten sam model uruchomiony u różnych dostawców również nie musi zachowywać się identycznie. Endpointy mogą różnić się kwantyzacją i obsługiwanymi parametrami. Służą do tego między innymi quantizations oraz require_parameters.
Nie każde anulowanie żądania oznacza też natychmiastowe zatrzymanie kosztów. Anulowanie jest obsługiwane dla streamingu i tylko u wspierających to dostawców. W pozostałych przypadkach można zostać rozliczonym za całą odpowiedź.
Darmowe modele nie są zamiennikiem infrastruktury produkcyjnej. Limity są celowo niskie.
ZDR także nie oznacza automatycznie zerowej retencji dla wszystkiego, co przechodzi przez request. Pluginy i narzędzia są poza tym mechanizmem.
OpenRouter upraszcza więc warstwę integracji i routingu, ale nie zwalnia z rozumienia tego, do jakiego dostawcy trafia żądanie i jakie wymagania zostały ustawione. Jeśli dopiero układasz sobie obraz tego, czym różnią się poszczególne rodziny modeli, zebraliśmy to osobno w tekście o tym, czym jest LLM. Szerszy przegląd narzędzi, które warto mieć obok, jest w zestawieniu narzędzi AI dla developera.
