Router modeli w n8n: natywny node OpenRouter czy HTTP Request w produkcji

Node OpenRouter Chat Model w n8n (dostępny od wersji 1.78) w piętnaście minut daje dostęp do ponad 400 modeli przez jeden credential. Przez półtora roku natywny node nie pozwalał ustawiać polityki danych ani wybierać dostawcy per żądanie. Globalne reguły można było wymusić na koncie OpenRoutera, ale jawna polityka w workflow produkcyjnym wymagała HTTP Request z ręcznie pisanym body JSON. Od n8n 2.36 (18 sierpnia 2026) ta granica się przesunęła: node dostał sekcję Provider Routing z ośmioma polami, w tym zdr, data_collection i whitelistą dostawców. Nadal nie ma w nim kaskady modeli models[], parametrów reasoning ani dostępu do tego, co OpenRouter zwraca w odpowiedzi: użytego modelu, dostawcy i kosztu.

Z tego artykułu dowiesz się:

• Gdzie dziś kończy się natywny node i które parametry (models[], reasoning, koszt z odpowiedzi) nadal wymagają HTTP Request.
• Dlaczego wersja n8n jest pierwszym pytaniem: na 2.27 czy 2.30 node nie steruje polityką danych per żądanie (globalnie zrobisz to w ustawieniach konta OpenRoutera), a self-host aktualizuje się wolniej niż Cloud.
• Jak zbudować kaskadę modeli tani → droższy, która sama przełącza się przy błędach 429 i 5xx, i czego nie przełączy.
• Którą pułapkę sub-nodów trzeba znać, zanim puścisz pętlę po rekordach z dynamicznym wyborem modelu.
• Kiedy router modeli w ogóle nie jest dobrym pomysłem: gwarantowane przetwarzanie w regionie, twarde SLA, wymogi on-prem.

Router modeli w n8n: co naprawdę wybierasz między node'em a HTTP Request

Zanim zaczniesz konfigurować cokolwiek, warto rozstrzygnąć jedną rzecz: to nie jest wybór "lepszego" node'a. To wybór między dwoma narzędziami o różnym poziomie kontroli nad żądaniem i odpowiedzią. W wersji 1.78 n8n wprowadził dedykowany node OpenRouter, który pozwala „zmieniać modele w locie" w agentycznym workflow↗, podłączony jako sub-node do AI Agent albo Basic LLM Chain. Konfiguracja to credential z kluczem API, wybór modelu z dynamicznie ładowanej listy i kilka parametrów standardowych: temperature, max tokens, response format, top P. Jeśli dopiero zaczynasz z tym narzędziem, najpierw przeczytaj, czym jest n8n i do czego służy↗, ten tekst zakłada, że masz już działający workflow z modelem.

Do sierpnia 2026 problem był w tym, czego UI nie pokazywało. OpenRouter jako API akceptuje parametry, które decydują o tym, gdzie fizycznie trafia prompt, czy dostawca może go zalogować albo wytrenować na nim model, i co się dzieje, gdy wybrany model akurat nie odpowiada. Żaden z tych parametrów nie miał pola w formularzu sub-node'a. W wydaniu n8n 2.36 zespół dodał do node'a sekcję Provider Routing (pull request n8n-io/n8n #24822↗, scalony 11 sierpnia 2026) z ośmioma polami: order, allowFallbacks, requireParameters, dataCollection, zdr, only, ignore i sort. Pierwsza część problemu zniknęła. Została druga: sub-node nadal eksponuje wspólny, uproszczony interfejs LangChain dla wielu providerów naraz, a nie pełne API OpenRoutera.

Tor A i Tor B: dwa różne przeznaczenia, nie dwa etapy tej samej pracy

Praktyczne kryterium przełączania warto zapisać w standardzie projektowym zespołu, zanim ktoś skopiuje workflow z prototypu do produkcji.

Tor A, natywny node. Klik, klik, credential, model z listy. Na n8n 2.36 i nowszym również polityka danych: zdr, dataCollection: deny, whitelista albo blacklista dostawców, sortowanie po cenie. Dobry do agentów i łańcuchów, w których jeden model obsługuje żądanie, a n8n ma zarządzać retry i timeoutem za Ciebie.

Tor B, HTTP Request z jawnym body JSON. Potrzebny, gdy chcesz kaskady różnych modeli przez models[], sterowania myśleniem modelu przez reasoning, parametrów OpenRoutera niewystawionych w UI, albo pełnej kontroli nad odpowiedzią HTTP: statusem, nagłówkami, polem model z faktycznie użytym modelem i usage.cost z kosztem w dolarach. Na n8n starszym niż 2.36 Tor B jest też jedyną drogą do polityki danych ustawianej per żądanie; globalne wymuszenie ZDR i blokady trenowania robisz wtedy w ustawieniach konta OpenRoutera. Stara wersja na self-hoście zdarza się częściej, niż się wydaje.

Kiedy natywny node OpenRouter wystarcza, a kiedy musisz zejść do HTTP Request

Kryterium przełączania ma dziś dwa kroki. Pierwszy: sprawdź wersję n8n (Help → About w panelu). Poniżej 2.36 node nie steruje polityką danych per żądanie. ZDR i blokadę dostawców trenujących na danych możesz wtedy wymusić globalnie w ustawieniach prywatności konta OpenRoutera (ZDR ma przełącznik per grupa modeli, zgoda na trenowanie osobne przełączniki dla modeli płatnych i darmowych), a HTTP Request bierzesz, gdy polityka ma być jawna w body albo różna dla poszczególnych workflow. Drugi krok, na 2.36 i nowszym: jeśli workflow potrzebuje jednego z trzech elementów, natywny node nie wystarcza. Te trzy elementy to kaskada modeli models[] (automatyczne przełączenie na inny model, gdy pierwszy nie odpowiada), parametry reasoning (ile "myślenia" model wykonuje przed odpowiedzią, co wprost przekłada się na koszt) oraz odczyt odpowiedzi OpenRoutera poza samym tekstem: który model i dostawca faktycznie obsłużyli żądanie i ile to kosztowało.

Co node faktycznie daje

Zestaw opcji dostępnych w UI sub-node'a OpenRouter Chat Model pokrywa standardowe parametry generowania: Frequency Penalty, Max Tokens, Response Format (Text albo JSON), Presence Penalty, Temperature, Timeout, Max Retries i Top P. Modele ładują się dynamicznie z konta podłączonego przez credential, więc lista jest zawsze aktualna względem tego, co OpenRouter właśnie udostępnia.

Od n8n 2.36 dochodzi kolekcja Provider Routing. Według kodu node'a w repozytorium n8n zawiera ona: order (lista slugów dostawców do wypróbowania po kolei), allowFallbacks (domyślnie włączone), requireParameters (tylko dostawcy obsługujący wszystkie parametry żądania), dataCollection (allow albo deny), zdr (tylko endpointy Zero Data Retention), only (whitelista dostawców), ignore (blacklista) oraz sort (price, throughput albo latency). Node tłumaczy te pola na blok provider w żądaniu do API, dokładnie ten sam, który w Torze B piszesz ręcznie. Dokumentacja n8n na stronie node'a w chwili pisania (2 września 2026) jeszcze tych pól nie opisuje, źródłem jest changelog wydania 2.36 i kod.

Czego node nie daje

Node nie ma pola na listę fallbackową models[]. allowFallbacks pozwala OpenRouterowi przełączać się między dostępnymi dostawcami tego samego modelu, gdy główny jest niedostępny, ale nie przełączy na inny model; kaskady "spróbuj Haiku, jak padnie to Gemini Flash" bez models[] nie zbudujesz. Nie eksponuje parametrów reasoning, czyli reasoning.effort i reasoning.max_tokens, ani thinking level dla modeli typu Gemini 3 Pro, gdzie poziom rozumowania wpływa bezpośrednio na koszt i czas odpowiedzi. Nie pokazuje też nagłówków odpowiedzi ani pól model, provider i usage.cost, dostępnych w udanej odpowiedzi Chat Completions. W AI Agent widzisz tekst i liczbę tokenów, nie widzisz, który dostawca obsłużył żądanie i za ile.

Wszystkie te elementy trzeba wysłać i odczytać przez HTTP Request, bo są częścią surowego API OpenRoutera, a nie interfejsu LangChain, który n8n współdzieli między providerami LLM.

Historia dwóch pull requestów

Warto znać ją, żeby nie planować produkcji pod funkcje, które "zaraz wejdą". Pull request n8n-io/n8n #21780↗ (autor @konstantintieber, otwarty 12 listopada 2025) proponuje pole JSON scalane z opcjami sub-node'a, co pozwoliłoby przekazać dowolne parametry OpenRoutera, w tym reasoning. W chwili pisania nadal jest draftem, z ostatnią aktywnością w maju 2026, a blokują go ograniczenia warstwy LangChain. Routing dostawców i politykę danych dowiózł osobny, węższy pull request #24822 (autor @alejandrosnz), scalony 11 sierpnia 2026 i wydany w 2.36 tydzień później. Wniosek dla planowania: to, co jest w 2.36, jest stabilne; na reasoning w natywnym node nie ma sensu czekać, HTTP Request rozwiązuje to dziś.

Pułapka przy wielu itemach

Wyrażenia w sub-nodach modelu zawsze rozwiązują się do pierwszego itemu w batchu, co dokumentacja n8n zaznacza wprost. Jeśli masz pętlę, która przechodzi po rekordach i dynamicznie wybiera model per rekord (na przykład tańszy model dla krótkich tekstów, droższy dla długich), sub-node po cichu weźmie model wyliczony dla pierwszego rekordu i zastosuje go do wszystkich pozostałych. Nie ma błędu, nie ma ostrzeżenia, workflow po prostu zwraca gorsze wyniki dla części danych, a przyczyna nie jest widoczna w logach wykonania.

Rozwiązanie: pętla musi być na poziomie root node, nie w sub-node. Każda iteracja root node'a (na przykład Split In Batches z rozmiarem 1) uruchamia całą gałąź AI Agent od nowa, więc wyrażenie w sub-nodzie dostaje właściwy kontekst dla każdego przebiegu. Kosztuje to więcej wykonań workflow, ale eliminuje ryzyko, że część rekordów zostanie przetworzona przez zły model bez żadnego sygnału ostrzegawczego.

Konfiguracja credentiala i node'a OpenRouter Chat Model krok po kroku

Zanim node w ogóle zapyta o model, potrzebuje credentiala z kluczem API. Procedura jest krótka i jednoetapowa: credential OpenRouter API w n8n obsługuje wyłącznie klucz API generowany w panelu OpenRoutera i nie oferuje logowania OAuth (sama platforma OpenRouter ma OAuth PKCE, ale n8n z niego nie korzysta).

Krok 1: klucz API po stronie OpenRoutera

1. Zaloguj się na openrouter.ai↗.
2. Wejdź na openrouter.ai/keys.
3. Kliknij Create new secret key, nadaj nazwę pozwalającą później zidentyfikować, do jakiego workflow lub klienta klucz należy. Możesz od razu ustawić limit kredytów na klucz, do tego wrócimy przy monitoringu.
4. Skopiuj wygenerowany sekret. Nie zobaczysz go ponownie w pełnej formie po zamknięciu okna.

Krok 2: credential w n8n

1. W n8n przejdź do Credentials, wybierz OpenRouter API.
2. Wklej skopiowany sekret jako API Key.
3. Zapisz. Nazwę credentiala warto ujednolicić z konwencją używaną w innych integracjach, żeby po miesiącach było wiadomo, do którego konta i klienta klucz się odnosi. To wszystko po stronie autoryzacji. Żadnego przekierowania, żadnego zakresu uprawnień do zaznaczenia, żadnego odnawiania tokenów.

Krok 3: node OpenRouter Chat Model jako sub-node

Node dodaje się jako sub-node modelu, podłączony do AI Agent albo Basic LLM Chain. Po podłączeniu credentiala pole Model wypełnia się dynamicznie katalogiem zwracanym przez OpenRouter, nie statyczną listą wpisaną w kod node'a; ostateczna dostępność modelu może zależeć od ustawień konta, guardraili i dostępnych dostawców.

Zestaw opcji dostępnych w panelu na każdej wersji od 1.78:

• Model: lista dynamiczna, ładowana z konta po podłączeniu credentiala.
• Response Format: Text albo JSON.
• Sampling Temperature: kontrola losowości odpowiedzi.
• Max Tokens: limit długości odpowiedzi.
• Timeout (ms): czas oczekiwania na odpowiedź przed przerwaniem żądania.
• Max Retries: liczba automatycznych powtórzeń przy błędzie.
• Top P: alternatywna metoda kontroli losowości względem temperature.
• Frequency Penalty i Presence Penalty: ograniczanie powtórzeń słów i tematów w odpowiedzi. Na n8n 2.36 i nowszym pod Add Option pojawia się dodatkowo Provider Routing z ośmioma polami opisanymi wyżej. Jeśli tej pozycji nie widzisz, masz starszą wersję: politykę danych per żądanie ustawisz tylko w Torze B, globalną w ustawieniach konta OpenRoutera.

Pułapka z Response Format = JSON

Ustawienie Response Format na JSON nie działa samo z siebie. Model musi dostać w promptie wyraźną instrukcję zawierającą słowo "json", inaczej część dostawców zwróci błąd albo zignoruje wymuszony format. Druga zasada dotyczy wyboru modelu: starsze modele nie mają JSON mode w API, więc ustawienie w n8n nic nie da, sprawdź w dokumentacji dostawcy, czy model to obsługuje. Przy debugowaniu "dlaczego JSON mode nie działa" te dwa punkty sprawdzaj jako pierwsze, zanim zaczniesz szukać błędu w konfiguracji node'a.

Self-hosted, cloud i wersja, którą faktycznie masz

Node działa identycznie na n8n self-hosted i n8n Cloud, o ile obie instalacje są na tej samej wersji. Tu leży praktyczna różnica: Cloud aktualizuje się w terminie wybranym przez dostawcę, więc Provider Routing pojawił się tam w ciągu dni od wydania 2.36. Self-host aktualizujesz sam i często z opóźnieniem, bo każda aktualizacja to okno serwisowe i ryzyko regresji. Instancja, na której testowałem ten artykuł, była na 2.27.5, czyli bez Provider Routing, mimo że 2.36 miało już dwa tygodnie. Koszty i utrzymanie obu wariantów porównuję w osobnym tekście o n8n self-hosted czy cloud↗.

Na self-hoście można też zainstalować community node (n8n-nodes-openrouter i pochodne), które dodają dropdown modeli z filtrem modalności albo obsługę request per item. W praktyce sens takiego rozwiązania ogranicza się do bardzo specyficznych potrzeb, bo koszt utrzymania dodatkowej zależności zwykle przewyższa korzyść względem przejścia na HTTP Request.

Przed wersją 1.78 n8n nie miał dedykowanego sub-node'a OpenRouter. Najczęściej używano node'a OpenAI z podmienionym Base URL na https://openrouter.ai/api/v1 albo zwykłego HTTP Request. Wariant z node'em OpenAI działał, ale historycznie zdarzały się błędy w obsłudze niestandardowego Base URL w credentialach OpenAI. Dziś ma sens jako plan B, gdy z jakiegoś powodu natywny sub-node nie jest dostępny w danej instalacji, nie jako domyślna metoda konfiguracji.

HTTP Request w produkcji: zero retention, kaskada fallbacków i koszt z odpowiedzi

Body JSON poniżej to wersja bazowa, przetestowana 2 września 2026 na żywym koncie i gotowa do wklejenia w pole Body node'a HTTP Request (metoda POST, adres https://openrouter.ai/api/v1/chat/completions, nagłówek Authorization: Bearer z klucza). Zmieniasz w niej tylko nazwy modeli, resztę struktury zostawiasz bez ruszania.

{
  "models": ["anthropic/claude-haiku-4.5", "google/gemini-3.5-flash"],
  "messages": [{ "role": "user", "content": "..." }],
  "max_tokens": 1024,
  "provider": {
    "zdr": true,
    "data_collection": "deny",
    "sort": "price"
  }
}

models to uporządkowana kaskada: pierwsza pozycja jest modelem preferowanym, kolejne przejmują żądanie, gdy poprzednia zawiedzie. Osobne pole model nie jest potrzebne, dokumentacja fallbacków używa samej tablicy. provider to blok kontrolujący, gdzie i jak żądanie faktycznie trafia. Dwie rzeczy, o które łatwo się potknąć: identyfikatory modeli muszą istnieć dokładnie w takiej formie, jaką zwraca GET /api/v1/models (na przykład google/gemini-3-flash nie istnieje, jest google/gemini-3-flash-preview), a slugi dostawców w only, ignore i order to małe litery z listy GET /api/v1/providers (anthropic, amazon-bedrock, google-vertex, mistral), nie nazwy handlowe.

Uwaga na provider.only: whitelista dotyczy całego żądania, razem z modelami zapasowymi. Wcześniejsza wersja tego przykładu miała only: ["anthropic", "amazon-bedrock"] i wyglądała rozsądnie, dopóki Haiku odpowiadał. Test z samym Gemini Flash i tą whitelistą zwrócił 404 „No allowed providers are available for the selected model", bo Gemini hostują google-ai-studio i google-vertex, a żaden z nich nie był na liście. Jeśli używasz only, lista musi pokrywać każdy model z kaskady, inaczej fallback jest martwy.

Wymuszanie zero retention i blokada trenowania na danych

OpenRouter umożliwia wymuszenie Zero Data Retention per żądanie przez pole provider.zdr: true oraz zablokowanie dostawców, którzy zbierają dane do trenowania, przez provider.data_collection: "deny"↗. To dwa niezależne przełączniki. zdr wymusza, żeby żądanie poszło tylko do endpointów, które kontraktowo gwarantują brak retencji promptu i odpowiedzi. data_collection: "deny" odcina dostawców, którzy mogą przechowywać dane nieprzejściowo albo trenować na nich modele, nawet jeśli formalnie nie deklarują zero retention. Na n8n 2.36 oba pola ustawisz też w natywnym node, w kolekcji Provider Routing, i trafią do API w identycznej formie.

Przed dodaniem nowego modelu do produkcji warto sprawdzić, czy w ogóle ma endpoint spełniający ZDR, bo lista endpointów z gwarantowanym Zero Data Retention jest udostępniona programatycznie pod adresem openrouter.ai/api/v1/endpoints/zdr↗. Zapytanie GET do tego adresu zwraca aktualny zestaw (2 września 2026: 832 endpointy), który da się wpiąć jako krok walidacyjny przed deploymentem albo jako cykliczny monitoring w n8n, bo lista zmienia się bez zapowiedzi.

Istotny szczegół działania: zdr na poziomie żądania działa jak logika OR względem ustawień konta. Dokłada wymuszenie tam, gdzie go nie było, ale nie nadpisuje bardziej restrykcyjnych reguł ustawionych już na koncie. Tak samo only zawęża listę dostawców w ramach tej, którą dopuszcza konto, a ignore sumuje się z blacklistą konta.

Modele :free a polityka danych

Darmowe warianty modeli (sufiks :free) hostują dostawcy z własnymi politykami danych, a OpenRouter trzyma dla nich osobne ustawienia prywatności niż dla endpointów płatnych. Część darmowych endpointów może trenować na promptach albo je logować, więc data_collection: "deny" potrafi zawęzić listę dostawców do zera. W moim teście z 2 września 2026 model z-ai/glm-5.2:free z data_collection: "deny" zwrócił błąd 429 od dostawcy zamiast odpowiedzi; dokumentacja opisuje w takich sytuacjach także 404 z komunikatem o braku endpointów zgodnych z polityką danych. To wynik dla konkretnego modelu i konkretnej konfiguracji konta, nie uniwersalna reguła platformy.

Wniosek operacyjny jest mimo to prosty: darmowych modeli nie planuj jako fundamentu pod produkcję z danymi klienta. Ich polityki danych zmieniają się z endpointu na endpoint, limity są sztywne, a każda z tych rzeczy może się zmienić bez zapowiedzi. Traktuj :free jako warstwę dev i pierwszą pozycję kaskady na danych syntetycznych albo publicznych.

Fallback models[]: co przełącza, a czego nie

OpenRouter obsługuje fallback modeli przez tablicę models[] w treści żądania; według dokumentacji domyślnie każdy błąd może uruchomić model zapasowy, w tym błąd długości kontekstu, odmowa moderacji, limit zapytań i przestój dostawcy↗. Rozliczenie idzie według modelu faktycznie użytego, który wraca w polu model odpowiedzi. Mechanizm jest wbudowany w routing, nie wymaga własnej logiki retry po Twojej stronie, o ile wystarcza Ci przełączenie na poziomie jednego żądania. Dla formatu Anthropic Messages istnieje też nowszy parametr fallbacks (maksymalnie trzy pozycje, nie łączy się z models), w formacie Chat Completions zostań przy models.

Jedno zastrzeżenie z praktyki: nie zakładaj, że każdy błąd 400 uruchomi model zapasowy. W moim teście z 2 września 2026 model z-ai/glm-5.3 z reasoning.effort: "none" i modelem zapasowym openai/gpt-5.4-mini w models[] zwrócił 400 „Reasoning is mandatory for this endpoint and cannot be disabled", a model zapasowy nie został wywołany. Pusty provider_name w metadanych błędu sugeruje, że żądanie zostało odrzucone przed wywołaniem dostawcy, ale to wniosek z jednego przypadku, nie reguła dla wszystkich błędów 400. Ten sam blok parametrów idzie do każdej pozycji kaskady, osobnego body per model nie ma. Parametry normalizuj więc per model przed wysłaniem i testuj kaskadę także w ścieżce awaryjnej, nie tylko wtedy, gdy pierwszy model odpowiada.

Kaskada darmowy → tani → droższy

Praktyczna strategia budowy models[] pod limity darmowego tieru wygląda tak:

1. Pierwsza pozycja: model :free. Limit 20 zapytań na minutę jest sztywny, a limit dzienny wynosi 50 zapytań, albo 1000 po jednorazowym zakupie kredytów za co najmniej 10 dolarów.
2. Druga pozycja: tani model płatny, na przykład klasy mini albo flash. Ta pozycja przejmuje ruch, gdy darmowy model odmawia z powodu 429 albo nie ma dostawcy zgodnego z polityką danych.
3. Trzecia pozycja: droższy model flagowy jako ostatnia linia obrony, uruchamiana tylko wtedy, gdy dwie pierwsze pozycje zawiodły. Taka kaskada minimalizuje koszt w typowym ruchu, jednocześnie zmniejszając ryzyko, że żądanie skończy się błędem tylko dlatego, że któryś dostawca akurat ma przestój albo limit został wyczerpany.

Backoff przy 429 i 5xx wokół HTTP Request

Kaskada models[] obsługuje przełączenie modelu w ramach jednego żądania, ale nie zastępuje retry na poziomie workflow, zwłaszcza gdy przyczyną błędu jest chwilowe przeciążenie, nie brak dostępnego modelu. Poradnik limitów OpenRoutera zaleca przy błędach 429 zastosować backoff w sekwencji 1s, 2s, 4s, 8s i zaznacza, że dla modeli płatnych OpenRouter nie narzuca własnych dodatkowych limitów↗ poza tymi, które ustala sam dostawca modelu.

W n8n to się implementuje jako pętla wokół node'a HTTP Request: node Wait z rosnącym czasem, warunek IF sprawdzający kod odpowiedzi (429 albo przejściowy 5xx), powrót do HTTP Request przy błędzie, wyjście z pętli po sukcesie albo po wyczerpaniu limitu prób. 404 i 503 wynikające ze statycznej polityki routingu wymagają korekty konfiguracji, nie ślepego retry. Cztery próby z backoffem 1 → 2 → 4 → 8 sekund pokrywają większość chwilowych przeciążeń bez nadmiernego wydłużania czasu odpowiedzi workflow.

Segmentacja danych: kto jedzie przez kaskadę, kto przez whitelistę

Pole provider.only pozwala ograniczyć routing do konkretnych dostawców, na przykład ["mistral", "amazon-bedrock"]. To jest miejsce, gdzie w praktyce dzieli się ruch według charakteru danych:

• Dane osobowe: kieruj przez provider.only do dostawców, których polityki i lokalizacje znasz, z zdr: true i data_collection: "deny", albo przez self-hosted model poza OpenRouterem w ogóle. Tak samo warto rozdzielić workflow, który łączy Notion z n8n↗ i przetwarza dane kontaktowe klientów, od automatów pracujących na treściach publicznych.
• Dane nieosobowe albo pseudonimizowane: mogą iść przez pełną kaskadę, korzystając z sort: "price" i fallbacków bez dodatkowych ograniczeń. Jedno zastrzeżenie, którego provider.only nie rozwiązuje: whitelista dostawcy nie jest gwarancją, że dane zostały przetworzone w konkretnym regionie. Dostawca z only może mieć centra danych w kilku regionach, a OpenRouter zaleca niezależne potwierdzenie lokalizacji u dostawcy. Gwarantowane przetwarzanie w regionie (żądania odszyfrowywane tylko w UE albo tylko w USA i kierowane wyłącznie do dostawców z tego regionu) to osobna funkcja, dostępna przez eu.openrouter.ai w planach Business i Enterprise.

Ten podział trzeba zaszyć w logice workflow przed wysłaniem żądania, nie po fakcie. Jeśli klasyfikacja danych zależy od zawartości rekordu, klasyfikuj i kieruj do odpowiedniej gałęzi zanim body JSON trafi do HTTP Request.

Gdzie router nie jest dobrym pomysłem

Są sytuacje, w których żadna konfiguracja provider.only czy zdr nie rozwiązuje problemu, bo problem jest strukturalny, nie parametryczny:

• Wymóg gwarantowanego przetwarzania w regionie. Umowę powierzenia OpenRouter ma publiczną: regulamin, ostatnio zaktualizowany 31 sierpnia 2026, włącza Data Processing Agreement (ostatnia aktualizacja 26 sierpnia 2026) przez odniesienie dla organizacji i użytkowników komercyjnych, więc sam DPA nie jest już argumentem za Enterprise. Argumentem jest lokalizacja: standardowy plan daje provider.only, a nie gwarancję regionu. Jeśli klient wymaga, żeby dane nie opuściły UE, potrzebujesz in-region routingu z planu Business albo Enterprise, bezpośredniego API dostawcy z rezydencją EU, albo modelu self-hosted. Ocena zgodności z RODO to zawsze analiza konkretnego wdrożenia, nie parametru w body.
• Twarde SLA. Strona statusu pokazuje uptime inference na poziomie około 99,99% w skali 90 dni, a sierpniowa degradacja trwała 2 godziny 42 minuty i dotyczyła panelu webowego, nie inference. Dla projektów z kontraktowym SLA wymagającym gwarancji dostępności, standardowy plan nie daje jednak formalnego zobowiązania, to element oferty Enterprise.
• Środowiska on-prem i air-gapped. Jeśli polityka klienta zakazuje jakiegokolwiek ruchu wychodzącego poza sieć lokalną, router modeli w chmurze jest wykluczony z definicji, niezależnie od tego, ile warstw zabezpieczeń dodasz w body JSON. W tych trzech przypadkach odpowiedzią nie jest lepsza konfiguracja HTTP Request, tylko inna architektura: self-hosted model, plan z in-region routingiem i SLA, albo bezpośrednie API dostawcy bez pośrednictwa routera.

Rozliczenia po stronie OpenRoutera działają na modelu prepaid: doładowujesz kredyty, płacisz tylko za zużyte tokeny, bez miesięcznej subskrypcji. Aktualne stawki i progi doładowań sprawdzaj bezpośrednio w cenniku OpenRoutera↗, zmieniają się częściej niż ten tekst.

Kaskadę z tego artykułu, razem z node'ami Wait i IF ustawionymi pod backoff 1 → 2 → 4 → 8 sekund, mam jako gotowy workflow do importu.

Monitoring kosztów, limitów i 5 pułapek routera modeli w n8n

Kaskada modeli i wymuszony zero retention rozwiązują problem niezawodności i zgodności w momencie wysłania żądania. Nie rozwiązują innego problemu: co się dzieje, gdy budżet klucza kończy się w środku batcha, albo gdy saldo konta spada poniżej zera bez żadnego wcześniejszego ostrzeżenia. Te dwa scenariusze wymagają osobnej warstwy monitoringu, uruchamianej przed właściwym żądaniem, nie po jego niepowodzeniu.

Budżet klucza sprawdzaj przed requestem, nie po błędzie

Stan klucza sprawdzasz przez zapytanie GET do /api/v1/key↗. Odpowiedź opisuje budżet klucza, nie liczbę zapytań: limit to limit kredytów ustawiony dla klucza (null, gdy nie ma limitu), limit_remaining to kredyty, które zostały do wyczerpania tego limitu, limit_reset mówi, kiedy limit się odnawia (na przykład co miesiąc), a usage, usage_daily, usage_weekly i usage_monthly pokazują zużycie w dolarach. Pole rate_limit w tej odpowiedzi jest oznaczone jako przestarzałe. Klucz z limitem 14 dolarów i limit_remaining równym 11,39 oznacza, że po wydaniu kolejnych 11,39 dolara żądania z tego klucza zaczną wracać z błędem 402, niezależnie od salda całego konta.

Praktyczny wzorzec w n8n wygląda tak: node HTTP Request do /api/v1/key na starcie workflow, następnie IF sprawdzający, czy limit_remaining spadł poniżej ustalonego progu w dolarach, na przykład poniżej kosztu jednego pełnego przebiegu batcha. Gdy warunek jest spełniony, gałąź prowadzi do node'a Slack albo Send Email z alertem zawierającym limit_remaining i limit_reset, zanim ktokolwiek zorientuje się, że batch przestał przetwarzać rekordy. Dopiero druga gałąź IF prowadzi do właściwego żądania modelu. Saldo całego konta czytasz osobno z /api/v1/credits (pola total_credits i total_usage), które wymaga klucza zarządzającego, nie zwykłego klucza API.

Dziennego licznika zapytań dla modeli darmowych API nie wystawia. Jeśli kaskada zaczyna się od :free, limit 50 albo 1000 zapytań dziennie obsługujesz przez reakcję na 429 i przełączenie na płatną pozycję, nie przez odpytywanie stanu.

402, 429 platformy i 429 dostawcy: trzy różne błędy

Błędy limitów z OpenRoutera nie oznaczają tego samego. Trzeba rozróżnić trzy źródła, bo każde wymaga innej reakcji:

• 402 Payment Required. Według dokumentacji błędów: konto albo klucz API ma za mało kredytów. Tu ląduje wyczerpany budżet klucza (limit_remaining na zerze) i ujemne saldo konta. Reakcja: doładuj konto albo podnieś limit klucza, retry nic nie da.
• 429 platformy. Limit zapytań narzucony przez samego OpenRoutera, na przykład 20 zapytań na minutę i limit dzienny modeli darmowych. Dotyczy konta niezależnie od modelu. Reakcja: backoff i czekanie, albo przełączenie na płatną pozycję kaskady.
• 429 dostawcy. Limit narzucony przez dostawcę modelu pod maską OpenRoutera, na przykład gdy Anthropic albo OpenAI mają własny throttling w danej chwili. Ten typ błędu jest opisany w treści odpowiedzi: error.metadata.error_type podaje klasę błędu, a error.metadata.provider_code kod dostawcy, jeśli został udostępniony. Reakcja: kaskada models[] przełącza na inny model, bo problem dotyczy jednego dostawcy, nie całego konta. Osobną klasą są błędy routingu. Brak endpointu spełniającego politykę może zwrócić 503, a niektóre niedopasowania modelu i provider.only zwracają 404, jak w teście z Gemini i whitelistą wyżej. 503 bywa też przejściowe (dostawca przeciążony) i wtedy kwalifikuje się do retry, często z nagłówkiem Retry-After. Decyzję o retry opieraj na error_type, komunikacie i Retry-After, nie tylko na statusie HTTP; błąd wynikający ze statycznej polityki routingu naprawia korekta konfiguracji, nie ponowna próba.

Node HTTP Request daje pełny dostęp do statusu, nagłówków i treści błędu, więc rozróżnienie tych dwóch źródeł da się zaimplementować jako osobna gałąź IF zaraz po węźle żądania. Natywny sub-node pokazuje w AI Agent tylko komunikat błędu, więc to rozróżnienie w praktyce wymaga HTTP Request, tak samo jak odczyt model i usage.cost.

Ujemne saldo działa także na modelach darmowych

Ujemne saldo konta zwraca błąd 402, nawet gdy żądanie idzie do modelu z sufiksem :free. To zaskakujące dla części wdrożeń, bo intuicyjnie darmowy model kojarzy się z brakiem zależności od salda, a w praktyce konto z ujemnym saldem blokuje wszystkie żądania, płatne i darmowe, jednakowo.

Konsekwencja dla monitoringu: sprawdzanie samego limit_remaining klucza nie wystarcza przed pętlą batchową, bo klucz bez limitu zwróci null, a klucz z limitem nic nie wie o saldzie konta. Trzeba dołożyć drugi warunek, sprawdzający saldo, zanim pętla ruszy po kilkuset albo kilku tysiącach rekordów. Batch, który zatrzyma się na rekordzie 50 z 500 z powodu 402, jest trudniejszy do posprzątania niż batch, który w ogóle nie wystartował, bo warunek wstępny go zablokował.

5 pułapek routera modeli w n8n

1. Wyrażenie w sub-nodzie bierze pierwszy item. Dynamiczny wybór modelu per rekord w pętli po cichu stosuje model wyliczony dla pierwszego elementu batcha do wszystkich pozostałych, bez błędu i bez ostrzeżenia w logach. Rozwiązanie: pętla na poziomie root node, nie w sub-node.
2. Nie zakładaj, że każdy błąd 400 uruchomi fallback. Dokumentacja mówi, że domyślnie każdy błąd może przełączyć model, w tym błąd długości kontekstu. W moim teście parametr odrzucony z kodem 400 wrócił jako błąd bez wywołania modelu zapasowego, a ten sam blok parametrów idzie do każdej pozycji kaskady. Normalizuj parametry per model i testuj ścieżkę awaryjną.
3. Wersja n8n decyduje, co node potrafi. Provider Routing istnieje od 2.36. Workflow zaprojektowany na Cloudzie z zdr w natywnym node może stracić tę ochronę po przeniesieniu na self-host z 2.30: starsza wersja może nie zastosować tej konfiguracji, więc po imporcie porównaj ustawienia node'a i przetestuj. Bezpiecznik na starszej wersji to globalne ustawienia prywatności konta OpenRoutera. Sprawdzaj wersję przed przenoszeniem i przy każdym audycie.
4. 429 z dwóch różnych źródeł traktowane jednakowo. Limit platformy (zapytania na minutę i dzień, np. modeli darmowych) i limit dostawcy (error.metadata.provider_code) wymagają różnej reakcji: backoff i czekanie kontra przełączenie modelu w kaskadzie. Brak kredytów to z kolei 402, nie 429, i retry go nie naprawi. Reagowanie identycznie na oba prowadzi albo do niepotrzebnego czekania, albo do niepotrzebnego przełączania modelu.
5. Zaszycie się na jednym endpoincie bez planu B. Architektura oparta wyłącznie na jednym routerze modeli, bez warstwy OpenAI-compatible i bez fallbacku na bezpośrednie API dostawcy, jest krucha wobec zmian po stronie rynku routerów: fuzje, przejęcia, zmiany warunków. Workflow produkcyjny powinien dać się przełączyć na bezpośrednie API bez przepisywania całej logiki, nie tylko na inny model w ramach tego samego dostawcy. Piąta pułapka nie jest teoretyczna. Rynek routerów modeli zmienia się w tempie, które trudno przewidzieć na etapie projektowania workflow, a zmiana właściciela albo warunków usługi potrafi wpłynąć na cennik i dostępność modeli z dnia na dzień. Struktura body JSON oparta na standardzie OpenAI-compatible ogranicza koszt takiej migracji do zmiany endpointu i mapowania nazw modeli, nie do przepisania całej logiki kaskady i obsługi błędów od zera.

Workflow, które już działają na produkcji, warto zweryfikować pod kątem tych pięciu punktów niezależnie od tego, jak dawno zostały wdrożone: audyt sprawdzający retencję danych, koszt per przebieg i odporność na błędy 429 zwykle wykrywa co najmniej dwie z pięciu pułapek w każdej instalacji, która rosła organicznie od prototypu do produkcji bez rewizji architektury.

Podsumowanie

Natywny node OpenRouter na n8n 2.36 i nowszym obsługuje politykę danych i routing dostawców: zdr, dataCollection: deny, whitelistę, blacklistę, kolejność i sortowanie po cenie. Do prototypów, agentów i większości workflow na jednym modelu to wystarcza. HTTP Request z jawnym body JSON pozostaje obowiązkowy w trzech sytuacjach: kaskada różnych modeli models[], parametry reasoning i odczyt tego, co OpenRouter zwraca poza tekstem (model, dostawca, koszt). Na n8n starszym niż 2.36 politykę danych per żądanie ustawisz tylko przez HTTP Request, a globalnie w ustawieniach konta OpenRoutera.

Kluczowe wnioski z całego materiału:

• Kryterium przełączania zaczyna się od wersji n8n, a potem od trzech pytań: kaskada, reasoning, kontrola odpowiedzi. Jeśli któraś odpowiedź brzmi tak, HTTP Request jest obowiązkowy, niezależnie od skali projektu.
• Kaskada darmowy → tani → droższy w models[] to standard odporności na 429 i niedostępność dostawcy. Whitelista provider.only musi pokrywać każdy model kaskady, a parametry trzeba normalizować per model, bo nie każdy błąd 400 uruchomi fallback.
• Monitoring GET /api/v1/key przed pętlą batchową mierzy budżet klucza w dolarach, nie liczbę zapytań. Saldo konta sprawdzaj osobno, brak kredytów wraca jako 402, a limity dzienne modeli darmowych obsługuj reakcją na 429.
• DPA OpenRouter ma publiczny i włączony do regulaminu. To, czego standardowy plan nie daje, to gwarancja przetwarzania w regionie i kontraktowe SLA.
• Pięć pułapek (pierwszy item w sub-nodzie, błąd 400 bez gwarancji fallbacku, wersja n8n, dwa źródła 429, brak planu B poza jednym routerem) warto sprawdzić w każdym istniejącym workflow, nie tylko w nowych wdrożeniach. Jeśli masz już działające automatyzacje z LLM i nie jesteś pewien, czy retencja danych, koszt per przebieg i odporność na błędy 429 są ustawione poprawnie, audyt istniejących workflow zwykle wykrywa te problemy szybciej niż przepisywanie ich od zera.

Zrodla

• OpenRouter Chat Model | Nodes | n8n Docs↗
• OpenRouter credentials | Nodes | n8n Docs↗
• n8n release notes: 2.36 (lmChatOpenRouter Node: Add provider routing options)↗
• n8n-io/n8n #24822 feat(lmChatOpenRouter Node): Add provider routing options↗
• n8n-io/n8n #21780 feat(Openrouter Node): Support setting chat model options as JSON (draft)↗
• LmChatOpenRouter.node.ts (kod node'a, master)↗
• Zero Data Retention - OpenRouter↗
• Provider Selection - OpenRouter Docs↗
• Model Fallbacks - OpenRouter Docs↗
• Provider Logging - Provider Data Retention Policies↗
• API Credit & Rate Limits - Handle 402 and 429 Errors↗
• Errors and debugging - OpenRouter Docs↗
• In-Region Routing - OpenRouter Docs↗
• Sovereign AI - OpenRouter Docs↗
• OpenRouter Terms of Service (31.08.2026)↗
• OpenRouter Data Processing Agreement↗
• OpenRouter Status↗
• OpenRouter Rate Limits: What You Need to Know - Zendesk Help Center↗
• Feature Request: Custom Parameters for OpenRouter Model Node - n8n Community↗
• Use OpenRouter in n8n (versions below 1.78)↗