Przy jednym agencie kodującym router modeli nie jest specjalnie potrzebny. Klucz API, endpoint i gotowe. Problem zaczyna się, gdy agentów i narzędzi korzystających z modeli jest kilka, każde ma inne potrzeby i inne ograniczenia. U mnie do OmniRoute trafia ruch z OpenCode, z automatyzacji w N8N i z Hermesa. Jeden adres, jeden port, a za nim konfiguracja, która decyduje, którego dostawcę i który model wybrać. Dlatego postanowiłem opisać, jak to wygląda w codziennej eksploatacji.
Czym jest OmniRoute
OmniRoute to lokalna bramka AI, która udostępnia pojedynczy endpoint zgodny z formatem OpenAI (localhost:20128/v1). Klienty nie muszą wiedzieć, z jakiego faktycznie dostawcy korzystają. Router przyjmuje żądanie, decyduje o trasie na podstawie skonfigurowanych reguł i przekazuje je do jednego z ponad 330 dostawców. Projekt jest otwartoźródłowy (licencja MIT), utrzymywany przez społeczność skupioną wokół repozytorium na GitHubie, które zebrało ponad 53 tysiące gwiazdek.
Można go uruchomić przez npm, jako kontener Docker albo jako aplikację desktopową Electron. W moim przypadku jest to Docker.
Jeden punkt dostępowy zamiast wielu kluczy
Przed OmniRoute każde narzędzie musiało mieć wklejone klucze API do konkretnych dostawców. Zmiana backendu z OpenAI na Anthropic albo na Google oznaczała rekonfigurację w każdym kliencie z osobna. Teraz klucze leżą w jednym miejscu, a klienty znają tylko adres routera i swój token uwierzytelniający.
Przeniesienie się z jednego dostawcy na innego nie wymaga dotykania konfiguracji po stronie narzędzi. Dodanie nowego agenta do środowiska ogranicza się do wskazania mu endpointu routera i wygenerowania klucza w panelu.
Combo per rola
Najbardziej przydatnym mechanizmem w mojej konfiguracji są combo przypisane do ról. W OpenCode pracuję z kilkoma wyspecjalizowanymi profilami: Frontend Engineer, Backend Engineer, Research Engineer, QA Engineer, Write Engineer, Blogger, Reviewer i DevOps. Każdy z tych profili ma własny zestaw modeli dobrany pod specyfikę zadań.
Agent odpowiedzialny za infrastrukturę dostaje model, który dobrze radzi sobie ze skryptami powłoki, plikami konfiguracyjnymi i logami systemowymi. Rola badawcza korzysta z modelu z dużym oknem kontekstowym. Pisanie treści trafia do modelu, który lepiej obsługuje dłuższe formy tekstowe. Nie ma jednego idealnego modelu do wszystkiego, ale da się dobrać odpowiedni do konkretnej potrzeby.
Failover i odporność
OmniRoute obsługuje 4-warstwowy failover. Pierwszeństwo ma subskrypcja (jeśli takową mamy), potem wchodzą klucze API do płatnych dostawców, następnie tańsze alternatywy, a na końcu dostawcy z darmowymi limitami. Jeśli dostawca na pierwszej pozycji zwróci błąd albo wyczerpie limit, router przełącza się na kolejnego automatycznie. Czas przełączenia to milisekundy.
Dodatkową warstwą jest wyłącznik obwodowy: jeśli dany dostawca zaczyna regularnie sypać błędami, OmniRoute na jakiś czas przestaje kierować do niego ruch, a potem ostrożnie sprawdza, czy sytuacja się poprawiła. W praktyce oznacza to, że agenty nie zatrzymują się w połowie zadania, bo któryś z dostawców ma chwilowe problemy.
Kompresja tokenów
OmniRoute ma dwa mechanizmy kompresji, które można ze sobą łączyć. RTK (Real-Time Kompression) redukuje powtarzające się tokeny w oknie kontekstowym. Caveman idzie dalej i agresywnie skraca dane z narzędzi, takie jak wyniki diffów, logów czy grepowania. Połączenie obu daje według dokumentacji 15–95% oszczędności, ze średnią rzędu 89% na sesjach z intensywnym użyciem narzędzi.
To nie jest wyłącznie ciekawostka techniczna. Przekłada się wprost na to, ile zapytań zmieści się w darmowym limicie i jak szybko wyczerpie się płatne konto.
Routing przez proxy
Jedna z mniej oczywistych, ale przydatnych funkcji to obsługa serwerów proxy. W mojej konfiguracji wystawiłem kilka instancji Privoxy połączonych z tunelami VPN w różnych lokalizacjach geograficznych. Wybrane konta w OmniRoute kierują ruch przez te proxy. Przydaje się to w sytuacjach, gdy jakiś dostawca blokuje ruch z konkretnego regionu albo gdy chcę rozdzielić źródła zapytań między różne adresy IP.
Na co uważać w codziennej eksploatacji
Oficjalny obraz Docker (diegosouzapw/omniroute:latest) potrafi zostawać w tyle za zmianami w kodzie źródłowym. Jeśli potrzeba natychmiastowej poprawki albo wsparcia dla nowego dostawcy, niekiedy szybciej jest zbudować obraz samodzielnie z repozytorium niż czekać na aktualizację tagu.
Druga kwestia to panel webowy i wbudowane testy stanu. Zdarza się, że testowe zapytania w interfejsie OmniRoute sygnalizują błędy przy konkretnych dostawcach albo modelach, choć ruch z agentów przez skonfigurowane combo przechodzi bez przeszkód. Początkowo wygląda to na problem z konfiguracją, ale szybko okazuje się, że diagnostyka w panelu po prostu nie odzwierciedla w pełni stanu, jaki widzi agent korzystający ze zdefiniowanych reguł routingu. Nie warto tracić czasu na debugowanie wyłącznie na podstawie czerwonych wskaźników z testu.
Podsumowanie
OmniRoute dobrze sprawdza się jako centralna bramka AI w środowisku z wieloma agentami i narzędziami. Wystarczy jeden adres, żeby cały ruch LLM przechodził przez kontrolowane i konfigurowalne reguły. Combo per rola, automatyczny failover, kompresja tokenów i obsługa proxy dają solidną podstawę do codziennej pracy bez ręcznego pilnowania stanów poszczególnych dostawców.
Jeśli ktoś uruchamia więcej niż jednego agenta albo automatyzację korzystającą z modeli, router tego typu szybko przestaje być dodatkiem i staje się rzeczywistą częścią infrastruktury.
