OpenRouter — jedno API do wszystkich modeli AI. Czym jest, jak działa i kiedy się opłaca

OpenRouter — jedno API do wszystkich modeli AI. Czym jest, jak działa i kiedy się opłaca

Jeszcze trzy lata temu wybór modelu językowego był decyzją na lata: podpisujesz się pod jednym dostawcą, przepisujesz kod pod jego SDK i żyjesz z jego cennikiem, limitami i awariami. Dziś nowy model, który zmienia układ sił, pojawia się co kilka tygodni. OpenRouter powstał po to, żeby ta zmienność przestała być problemem inżynierskim – jedno API, ponad 400 modeli, automatyczne przełączanie między dostawcami. W maju 2026 firma zamknęła rundę B na 113 mln dolarów przy wycenie 1,3 mld dolarów.

Czym jest OpenRouter

OpenRouter to brama (gateway) do modeli AI: warstwa pośrednia między Twoją aplikacją a dostawcami modeli językowych. Zamiast integrować się osobno z OpenAI, Anthropikiem, Google, xAI, Mistralem czy DeepSeekiem, integrujesz się raz – z OpenRouterem – a on zajmuje się resztą: doborem dostawcy, przełączaniem na zapasowego przy awarii, rozliczeniem i statystykami.

Kluczowa decyzja projektowa: API OpenRoutera jest zgodne z SDK OpenAI. W praktyce oznacza to, że w istniejącym kodzie zmieniasz adres bazowy i klucz, a reszta działa bez zmian. To najniższy możliwy próg wejścia i główny powód, dla którego platforma rozeszła się tak szybko wśród zespołów produktowych.

Skala rośnie szybciej, niż firma zdąża aktualizować liczby na stronie: przychód w ujęciu rocznym wzrósł z ok. 19 mln dolarów na koniec 2025 roku do ok. 50 mln dolarów w marcu 2026. Model biznesowy jest przy tym wyjątkowo prosty – OpenRouter dolicza ok. 5% do kosztu inferencji. Nie ma abonamentu, nie ma opłaty za dostęp, nie ma minimum.

Jaki problem to rozwiązuje

Firma, która buduje cokolwiek na modelach językowych, prędzej czy później uderza w ten sam zestaw ścian.

1. Każdy dostawca to osobna integracja

Inne SDK, inny format wiadomości, inne nazwy parametrów, inne kody błędów, inny sposób obsługi strumieniowania. Dodanie drugiego dostawcy to nie jest kwestia zmiany jednej linijki – to osobna warstwa abstrakcji, którą trzeba napisać i utrzymywać.

2. Uzależnienie od jednego dostawcy

Gdy cała aplikacja stoi na jednym API, każda podwyżka cen, zmiana limitów, wycofanie modelu albo zaostrzenie polityki treści jest problemem, na który nie masz odpowiedzi. Migracja kosztuje tygodnie pracy, więc zwykle jej nie robisz – i to jest właśnie definicja uzależnienia od dostawcy.

3. Dostępność

Modele mają awarie. Dostawcy mają przeciążenia, kolejki i limity szybkości. Jeśli Twój produkt zwraca użytkownikowi błąd za każdym razem, gdy jeden konkretny endpoint ma zły dzień, to nie masz produktu – masz demo.

4. Koszty bez kontroli

Różnice cenowe między modelami o zbliżonej jakości potrafią być dziesięciokrotne. Bez warstwy, która pozwala łatwo przełączyć ruch albo skierować część zapytań na tańszy model, płacisz stawkę premium za zadania, które jej nie wymagają.

5. Rozproszone rozliczenia i brak wglądu

Pięciu dostawców to pięć faktur, pięć paneli, pięć limitów i zero wspólnego widoku na to, ile realnie kosztuje konkretna funkcja w produkcie.

OpenRouter odpowiada na każdy z tych pięciu punktów jednym rozwiązaniem: wspólnym interfejsem z inteligentnym routingiem pod spodem.

Jak działa routing

Routing to serce platformy i jednocześnie ta część, która najbardziej odróżnia OpenRouter od zwykłego proxy. Ten sam model bywa udostępniany przez kilku różnych dostawców inferencji, po różnych cenach, z różną przepustowością i różną stabilnością. OpenRouter wybiera między nimi automatycznie.

Domyślne równoważenie obciążenia

Bez żadnej konfiguracji platforma stosuje trzy zasady w tej kolejności:

1. Odrzuca dostawców z aktualną awarią – brany pod uwagę jest tylko ten, który nie miał przestoju w ciągu ostatnich 30 sekund.
2. Waży wybór odwrotnością kwadratu ceny – dostawca za 1 USD za milion tokenów jest ok. dziewięć razy bardziej prawdopodobny niż ten za 3 USD.
3. Przechodzi do kolejnego, jeśli wybrany zwróci błąd.

W efekcie ruch domyślnie płynie tam, gdzie jest taniej i stabilniej, bez ręcznej konfiguracji.

Auto Router

Ustawienie modelu na openrouter/auto przekazuje decyzję dalej: platforma sama dobiera model (nie tylko dostawcę) do konkretnego zapytania. Mechanizm oparty jest o NotDiamond, a odpowiedź zawiera informację, który model faktycznie odpowiedział – można więc śledzić i weryfikować te decyzje, zamiast ufać im na słowo.

Sterowanie routingiem parametrami

Kiedy potrzebujesz kontroli zamiast automatu, przekazujesz obiekt provider:

Są też dwa skróty, które załatwiają 90% przypadków: dopisek :floor do nazwy modelu sortuje po cenie (najtaniej), a :nitro po przepustowości (najszybciej). To jedna z tych rzeczy, które w rozmowie z zespołem tłumaczy się w dziesięć sekund, a które realnie zmieniają rachunek na koniec miesiąca.

Wysoka dostępność, czyli po co to naprawdę wdrażają

Zapytaj zespołów, które wdrożyły bramę AI, co dała im najbardziej – rzadko odpowiedzą, że oszczędności. Zwykle odpowiadają, że przestali dostawać zgłoszenia o błędach 503.

Mechanizm jest prosty. Możesz przekazać nie jeden model, lecz tablicę modeli. Jeśli pierwszy jest niedostępny, przeciążony albo odmówi obsługi zapytania, OpenRouter automatycznie sięga po kolejny – w tym samym wywołaniu, bez logiki ponawiania po Twojej stronie. To samo dzieje się na poziomie dostawców tego samego modelu.

Dla produktu, w którym asystent AI jest częścią ścieżki sprzedaży albo obsługi klienta, to nie jest funkcja techniczna, tylko biznesowa. Formularz, który nie odpowiada, to utracony lead – niezależnie od tego, czyja infrastruktura zawiodła.

Koszty: jak wygląda rachunek

Model rozliczenia

Płacisz za tokeny po cenach dostawców plus ok. 5% narzutu. Rozliczasz się kredytami, które działają na dowolny model i dowolnego dostawcę – jedno doładowanie zamiast pięciu umów i pięciu faktur. Dla zespołu, który testuje modele co tydzień, sam ten punkt bywa wystarczającym uzasadnieniem wdrożenia.

BYOK – własne klucze dostawców

Jeśli masz już wynegocjowane stawki albo zobowiązania wolumenowe u dostawcy, możesz wpiąć swoje klucze do OpenRoutera i dalej korzystać z routingu, fallbacków i statystyk. Opłata wynosi wtedy 5% tego, ile to samo zapytanie kosztowałoby normalnie na platformie – ale pierwszy milion zapytań BYOK miesięcznie jest bez opłaty. Klucze można ustawiać jako priorytetowe (używane przed współdzielonymi endpointami platformy) albo zapasowe (dopiero gdy tamte zawiodą).

Cache promptów – największa dźwignia oszczędności

Najbardziej niedoceniana funkcja. Jeśli w każdym zapytaniu wysyłasz ten sam długi kontekst – instrukcję systemową, dokumentację, cennik, regulamin – płacisz za niego raz za razem. Cache promptów sprawia, że płacisz ułamek.

Żeby cache faktycznie działał, kolejne zapytania muszą trafiać do tego samego endpointu – OpenRouter robi to sam (tzw. sticky routing), a przy rozmowach wieloetapowych można to dodatkowo wymusić parametrem session_id. Przy asystencie z rozbudowaną instrukcją systemową różnica w rachunku bywa kilkukrotna.

Bezpieczeństwo i polityki danych

Najczęstszy zarzut wobec bram AI brzmi: dokładasz kolejny podmiot do łańcucha przetwarzania danych. To prawda i trzeba to policzyć w analizie ryzyka. OpenRouter daje jednak narzędzia, których przy bezpośredniej integracji zwykle nie masz.

• Polityki danych na poziomie zapytania – ustawienie data_collection: "deny" wyklucza dostawców, którzy zbierają lub przechowują treść zapytań.
• Białe i czarne listy dostawców – parametry order i ignore pozwalają dopuścić wyłącznie tych, których dział prawny zaakceptował.
• Jeden punkt kontroli – klucze API, limity wydatków i uprawnienia zespołu w jednym miejscu, zamiast w pięciu panelach różnych dostawców.
• Pełna statystyka użycia – widzisz, która aplikacja, który klucz i który model generuje jaki koszt.

Dla firm w Unii Europejskiej wniosek jest praktyczny: OpenRouter upraszcza egzekwowanie polityk, ale nie zastępuje analizy zgodności. Przy danych osobowych i wrażliwych nadal trzeba przejść ścieżkę powierzenia przetwarzania – z tą różnicą, że listę dopuszczonych dostawców egzekwujesz technicznie, jednym parametrem, a nie zaufaniem do dyscypliny programistów.

Dlaczego firmy z tego korzystają

Ten ostatni punkt jest w praktyce ważniejszy, niż wygląda na liście. Tempo premier modeli jest dziś takie, że przewaga konkurencyjna trwa tygodnie. Zespół, który może przetestować nowy model w środę, ma inną pozycję niż ten, który musi najpierw założyć konto, przejść weryfikację i napisać adapter.

Zastosowania

Przykładowe zastosowania w praktyce

1. Narzędzia agentowe dla programistów

Największymi konsumentami tokenów na platformie są od dawna agenci kodujący – narzędzia typu Cline, Roo Code czy Kilo Code, działające jako wtyczki do edytora. Powód jest strukturalny: taki agent czyta repozytorium, planuje, pisze kod, uruchamia testy i poprawia błędy, a każdy z tych kroków to osobne zapytanie z dużym kontekstem. Brama daje im dwie rzeczy naraz – użytkownik podaje jeden klucz zamiast pięciu, a twórca narzędzia nie musi pisać integracji z każdym nowym modelem osobno.

2. Kaskada modeli w obsłudze klienta

Typowy układ w produktach SaaS: pierwsza linia to tani, szybki model, który obsługuje 80% powtarzalnych pytań. Jeśli pewność odpowiedzi jest niska albo temat jest złożony, zapytanie eskaluje do modelu z górnej półki. Bez bramy to dwie integracje i własna logika przełączania. Z bramą – jedna integracja i tablica modeli. Efekt: koszt spada wielokrotnie przy praktycznie niezmienionej jakości odbieranej przez klienta.

3. RAG na dokumentacji firmowej

Firma wrzuca do bazy wektorowej regulaminy, cenniki, umowy i dokumentację techniczną, a asystent odpowiada na ich podstawie. Tani model wybiera i streszcza fragmenty, mocny model formułuje ostateczną odpowiedź. Cache promptów obejmuje niezmienną instrukcję systemową i schemat odpowiedzi, więc każde kolejne zapytanie kosztuje ułamek pierwszego. Po stronie backendu taki układ najczęściej stoi dziś na PostgreSQL z rozszerzeniem wektorowym – opisaliśmy to szerzej w tekście o Supabase jako kompletnym backendzie dla aplikacji AI.

4. Masowa produkcja treści w agencji

Opisy produktów, warianty nagłówków reklamowych, meta title i description dla setek podstron, treści na karty lokali. Zadanie wysokowolumenowe i powtarzalne – czyli takie, w którym różnica między modelem za 15 dolarów a za 1,5 dolara za milion tokenów przekłada się bezpośrednio na marżę projektu. Dopisek :floor kieruje ruch do najtańszego dostawcy danego modelu, a jeśli jakość na testach okazuje się niewystarczająca, zmiana modelu to jedna linijka.

5. Asystent w portalu klienta dewelopera

Przykład z naszego podwórka. Portal klienta w inwestycji mieszkaniowej: kupujący pyta o harmonogram płatności, standard wykończenia, terminy odbioru czy zakres zmian lokatorskich. Asystent odpowiada na podstawie dokumentacji konkretnej inwestycji i konkretnego lokalu. Wymagania są tu zawsze te same: musi działać zawsze (bo jest częścią obsługi sprzedaży), musi być tani w utrzymaniu (bo pytań są tysiące) i nie może wysyłać danych klienta gdziekolwiek. Fallback, cache i polityka data_collection: "deny" odpowiadają dokładnie na te trzy punkty.

Kiedy OpenRouter nie jest dobrym wyborem

Uczciwie: nie w każdym projekcie brama ma sens.

• Bardzo duży, stabilny wolumen na jednym modelu – przy wynegocjowanym kontrakcie bezpośrednio u dostawcy 5% narzutu przestaje być zaokrągleniem. Wtedy zostaje BYOK albo integracja bezpośrednia.
• Twarde wymogi compliance i rezydencji danych – gdy dział prawny wymaga umowy powierzenia z konkretnym podmiotem i przetwarzania w konkretnym regionie, chmura dostawcy bywa prostszą ścieżką formalną.
• Funkcje specyficzne dla jednego dostawcy – najświeższe, niszowe możliwości API pojawiają się najpierw u źródła i nie zawsze są dostępne przez bramę.
• Skrajna wrażliwość na opóźnienie – dodatkowy element w ścieżce zapytania to dodatkowe milisekundy. Zwykle nieistotne, ale nie zawsze.

OpenRouter na tle alternatyw

Jak zacząć

1. Załóż konto i doładuj kredyty – do testów wystarczy kwota rzędu kilkudziesięciu złotych.
2. Wygeneruj klucz API i podmień w kodzie adres bazowy oraz klucz. Jeśli używasz SDK OpenAI, to cała migracja.
3. Uruchom ten sam prompt na trzech modelach z różnych półek cenowych i porównaj wyniki na swoich danych, nie na benchmarkach.
4. Ustaw tablicę modeli zapasowych i sprawdź zachowanie przy wymuszonym błędzie.
5. Dodaj cache promptów dla stałej części kontekstu i porównaj rachunek przed i po.
6. Ustaw polityki dostawców i limity wydatków, zanim wpuścisz ruch produkcyjny.

Co zmierzyć, żeby wiedzieć, czy się opłaca

Wdrożenie bramy bywa oceniane wrażeniowo – „wydaje się szybsze”, „chyba taniej”. To za mało, żeby obronić decyzję przed zarządem. Cztery wskaźniki wystarczą, żeby rozmowa była konkretna.

Warto zmierzyć je przed wdrożeniem bramy, na obecnej integracji. Bez punktu odniesienia każda późniejsza dyskusja o opłacalności kończy się wymianą opinii.

Brama a zwykłe proxy – gdzie jest różnica

Część zespołów zamiast bramy stawia własne proxy: jeden endpoint, prosta warstwa mapowania formatów, gotowe. To działa i przez pierwsze miesiące wygląda na tańsze rozwiązanie. Różnica ujawnia się później, w czterech miejscach.

• Wiedza o stanie dostawców. Własne proxy nie wie, że konkretny endpoint ma właśnie podwyższoną liczbę błędów – dowiaduje się o tym dopiero po nieudanym zapytaniu. Brama obserwuje ruch z setek tysięcy aplikacji i omija problem, zanim on Cię dotknie.
• Ceny i wybór dostawcy tego samego modelu. Ten sam model bywa dostępny u kilku dostawców po różnych stawkach, które się zmieniają. Utrzymywanie własnej, aktualnej mapy cen to praca ciągła, nie jednorazowa.
• Nadążanie za nowymi modelami. Każda premiera to dla własnego proxy zadanie w backlogu. Dla bramy – nowy wpis na liście.
• Cache i sticky routing. Żeby cache promptów działał, kolejne zapytania muszą trafiać do tego samego endpointu. To logika, którą trzeba świadomie zaimplementować i utrzymać.

Własne proxy ma sens, gdy masz jednego, stabilnego dostawcę i chcesz tylko centralizacji kluczy. Przy dwóch i więcej dostawcach koszt utrzymania zaczyna przewyższać 5% narzutu – zwykle szybciej, niż zakładał zespół.

Najczęstsze pytania o OpenRouter

Ile kosztuje OpenRouter?

Nie ma abonamentu. Płacisz za zużyte tokeny po cenach dostawców plus ok. 5% narzutu. Przy własnych kluczach dostawców (BYOK) opłata to 5% wartości zapytania, przy czym pierwszy milion zapytań BYOK miesięcznie jest bez opłaty.

Czy trzeba przepisywać aplikację?

Nie. API jest zgodne z SDK OpenAI – w większości projektów wystarczy zmiana adresu bazowego i klucza. To był świadomy wybór projektowy i główny powód szybkiej adopcji platformy.

Co się dzieje, gdy model jest niedostępny?

Możesz podać tablicę modeli zamiast jednego. Jeśli pierwszy zawiedzie, platforma automatycznie użyje kolejnego w tym samym wywołaniu. Analogicznie działa przełączanie między dostawcami tego samego modelu – domyślnie pomijani są ci, którzy mieli awarię w ostatnich 30 sekundach.

Czy OpenRouter przechowuje treść moich zapytań?

Politykę danych ustawiasz sam. Parametr data_collection: "deny" wyklucza dostawców zbierających treść zapytań, a listy order i ignore pozwalają dopuścić wyłącznie zaakceptowanych dostawców. Przy danych osobowych i tak konieczna jest własna analiza zgodności z RODO.

Czy da się wymusić najtańszego albo najszybszego dostawcę?

Tak. Dopisek :floor do nazwy modelu sortuje dostawców po cenie, :nitro po przepustowości. Można też użyć parametru sort z wartością price, throughput lub latency. Uwaga: ustawienie sortowania wyłącza domyślne równoważenie obciążenia.

Czy to rozwiązanie dla dużych firm, czy dla małych zespołów?

Dla obu, ale z różnych powodów. Małe zespoły kupują szybkość wdrożenia i dostęp do wszystkich modeli bez zakładania kont. Duże organizacje kupują governance: jeden punkt kontroli kluczy, limitów, polityk danych i kosztów w podziale na aplikacje i zespoły.

Podsumowanie

OpenRouter nie jest kolejnym modelem AI – jest warstwą, która sprawia, że wybór modelu przestaje być decyzją nieodwracalną. Jedno API zgodne z SDK OpenAI, ponad 400 modeli, automatyczne przełączanie przy awarii, routing po cenie lub szybkości, cache promptów i wspólne rozliczenie. Koszt tego komfortu to ok. 5% narzutu – w większości projektów mniej, niż kosztuje utrzymywanie własnej warstwy abstrakcji nad kilkoma dostawcami.

Jeśli budujesz produkt, w którym AI jest elementem obsługi klienta albo ścieżki sprzedaży, i zastanawiasz się, jak wpiąć to sensownie w istniejący system – napisz do nas. Projektujemy takie wdrożenia razem z resztą stosu: stroną, portalem klienta, lejkiem i CRM-em, żeby asystent nie był ciekawostką obok systemu, tylko jego częścią.

Źródła

• openrouter.ai – strona główna i dokumentacja (routing dostawców, Auto Router, cache promptów, BYOK), sierpień 2026
• TechCrunch – informacja o rundzie Series B i wycenie, maj 2026
• Sacra – dane o przychodach, modelu rozliczeń i segmentach klientów, 2026