import OpenAI from "openai";
const client = new OpenAI({
baseURL: "https://api.odnoga.com/v1", // <- the AI gateway
apiKey: process.env.ODNOGA_API_KEY, // <- your odnoga key
});
const res = await client.chat.completions.create({
model: "auto", // or "gpt-5-mini", "claude-haiku-4-5", ...
messages: [{ role: "user", content: "Hello" }],
});
Routing przed wywołaniem, rozliczenie po odpowiedzi.
Jeden endpoint zgodny z OpenAI
Skieruj dowolne SDK lub agenta do odnogi i korzystaj z OpenAI, Anthropic, Gemini, Mistral, Groq i innych przez jeden adres bramki AI.
Polityki routingu i failover
Kieruj ruch według kosztu, czasu odpowiedzi, możliwości lub rezydencji danych, z automatycznym przełączeniem, gdy dostawca ma problemy.
Budżety, limity i współbieżność
Twarde i miękkie limity wydatków dla organizacji, obszaru roboczego, użytkownika końcowego i modelu oraz wspólna pula równoległych wywołań dla organizacji.
Wykryj zatrzymany proces
odnoga poznaje typowy ruch każdej aplikacji i funkcji, a następnie alarmuje, gdy proces po cichu się zatrzyma lub nagle zacznie wysyłać znacznie więcej wywołań. W tym samym widoku zobaczysz historię ruchu i wywołania zakończone błędem, dzięki czemu od razu wiesz, od czego zacząć diagnostykę.
Księga kosztów każdego wywołania
Każde wywołanie tworzy dokładny wpis w księdze: tokeny wejściowe i wyjściowe, koszt dostawcy, opłatę odnogi oraz odbiorcę rozliczenia.
Routing regionalny z dowodem
Wybierz punkty końcowe w UE lub USA i zachowaj dowód miejsca, w którym rzeczywiście obsłużono każde wywołanie.
Wersjonowane prompty i A/B
Prompty żyją w bramce, nie w repo — wersjonuj, testuj A/B, cofaj jednym kliknięciem.
odnoga vs Kong vs Portkey
Kong routuje HTTP. Portkey routuje LLMy. odnoga routuje obciążenia AI z billingiem multi-tenant i natywną integracją Supabase.
| Możliwość | odnoga | Kong | Portkey |
|---|---|---|---|
| Integracja z Supabase | |||
| Billing i portfele multi-tenant | Częściowo | ||
| Przypisanie kosztu per end user | Częściowo | ||
| Egzekwowanie rezydencji EU/US | |||
| Endpoint zgodny z OpenAI | |||
| Zarządzanie promptami i A/B | |||
| Warstwa transformacji API |
Porównanie odzwierciedla publicznie udokumentowane możliwości na dzień publikacji. Skontaktuj się z nami, jeśli coś wymaga aktualizacji.
Jak działa bramka AI — krok po kroku
Bramka jest warstwą sterowania przed dostawcami modeli. Aplikacja uwierzytelnia się raz, a bramka stosuje ustalone zasady, wybiera model, wywołuje dostawcę zapisanym kluczem i rejestruje rozliczenie przed zwróceniem odpowiedzi.
Uwierzytelnienie i identyfikacja
Klucz API bramki rozstrzyga tenanta, workspace i — gdy wyślesz nagłówek end usera — konkretnego klienta, do którego należy wywołanie.
Kontrola dopuszczenia
Budżet, limity i współbieżność są sprawdzane przed kontaktem z dostawcą, dlatego przekroczenie zostaje zablokowane, zamiast pojawić się dopiero na fakturze.
Decyzja routingu
Zasady routingu przypisują alias do konkretnego modelu na podstawie kosztu, czasu odpowiedzi, możliwości i rezydencji danych oraz zachowują ustaloną kolejność modeli zapasowych.
Ujednolicone wywołanie dostawcy
Jedno wywołanie w formacie OpenAI jest tłumaczone na format dostawcy — obsługa narzędzi, obrazów, rozumowania i wyszukiwania w sieci różni się między usługami.
Pomiar i zapis do księgi
Liczba tokenów i cennik dostawcy tworzą dokładny wpis w księdze: koszt dostawcy, opłatę odnogi i kwotę do rozliczenia, przypisane do obszaru roboczego lub użytkownika końcowego.
Obserwowalność i dowód
Logi wywołań zapisują użyty model, ścieżkę modeli zapasowych, region obsługi i czas odpowiedzi, zapewniając dane potrzebne podczas incydentów i audytów.
your app ──▶ AI gateway ──▶ auth + budget check ──▶ routing policy ──▶ vendor (EU/US endpoint)
│ │
└──────────── ledger entry + request log ◀───────────────┘Kiedy jej nie potrzebujesz: aplikacja korzystająca z jednego modelu, bez potrzeby rozliczania klientów i wymogów zgodności, zwykle może łączyć się bezpośrednio z dostawcą. Bramka zarabia na siebie, gdy pojawia się drugi model, drugi klient albo druga osoba zmieniająca prompty.
Dwa rodzaje cache, nazwane uczciwie
Większość bramek reklamuje „cache” jako jedną funkcję. To dwie rzeczy, oszczędzają inaczej, i tylko jedna może zmienić to, co czytają Twoi użytkownicy. Każdą włączasz osobno i widzisz, ile dała.
Cache odnoga — zwracamy zapamiętaną odpowiedź
Identyczne zapytanie dostaje odpowiedź, którą już mamy. Bez wywołania dostawcy, więc bez kosztu. Uczciwy haczyk: to wcześniejsza odpowiedź, nie nowa — dlatego domyślnie dotyczy tylko wywołań deterministycznych.
Cache promptu dostawcy — tańszy odczyt
Dostawca pamięta długi prompt, który wciąż wysyłasz, i taniej go odczytuje. Odpowiedź zawsze powstaje od nowa, więc to nigdy nie zmieni wyniku.
- Tryb bezpieczny: zwracamy z pamięci tylko wywołania deterministyczne (temperatura 0 lub stały seed).
- Zasięg per workspace lub per klient końcowy, żeby jeden klient nigdy nie zobaczył odpowiedzi drugiego.
- Ważność do wyboru: 5 minut, godzina lub 24 godziny — plus wyjątki per funkcja i per prompt.
- Sterowanie per wywołanie nagłówkiem: pomiń zapamiętaną odpowiedź, odśwież ją lub wyłącz cache.
- Każda zwrócona z pamięci odpowiedź wraca oznaczona swoim wiekiem — nic nie jest po cichu nieaktualne.
- Oba rodzaje liczone w tej samej księdze: czego uniknięto, na której funkcji, po jakiej stawce modelu.
Cache odpowiedzi nie jest wyłączną cechą odnoga — mają go też OpenRouter i Portkey. Dokładamy nadzór i dowód: kogo dotyczy, kiedy odmawiamy zwrotu z pamięci i kwotę oszczędności wyprowadzoną z Twoich własnych zapytań, a nie z marketingowego mnożnika.
Sygnały, że bezpośrednie wywołania dostawcy już nie wystarczają
- Nazwy modeli i prompty są zaszyte w edge functions i nikt nie wie, która wersja jest na produkcji.
- Nie potrafisz powiedzieć, ile jeden klient kosztuje Cię w AI w tym miesiącu.
- Awaria dostawcy albo wyczerpanie środków na kluczu wyłącza funkcję bez modelu zapasowego.
- Potrzebujesz routingu EU dla części klientów i nie umiesz udowodnić, gdzie obsłużono requesty.
- Dodanie nowego dostawcy oznacza kolejne SDK, kolejny magazyn kluczy i kolejną pozycję na fakturze.
Pytania o bramkę AI
Czym jest bramka AI (AI gateway)?
Bramka AI jest warstwą sterowania między Twoją aplikacją a dostawcami modeli. Zapewnia jeden punkt dostępu do API, wspólne uwierzytelnianie, egzekwowanie zasad, przypisywanie kosztów i monitoring wielu dostawców. W odróżnieniu od tradycyjnej bramki API rozumie tokeny, prompty, tryby rozumowania, embeddingi, obrazy i wymagania dotyczące regionu przetwarzania.
Czym bramka AI różni się od Konga lub bramki API?
Tradycyjne bramki API, takie jak Kong, zarządzają ruchem, limitami i transformacjami na poziomie HTTP. Nie rozumieją specyfiki AI: cen za token, możliwości modeli, wersjonowania promptów ani tego, któremu klientowi przypisać koszt wywołania. Bramka AI dodaje tę warstwę i pozwala kierować, mierzyć oraz rozliczać wywołania AI.
Czym odnoga różni się od Portkey?
Portkey to rozbudowana bramka LLM. odnoga powstała z myślą o aplikacjach SaaS na Supabase, które obsługują wielu klientów. Oferuje budżety organizacji, portfele użytkowników końcowych, rozliczenia wielu klientów, integrację z Supabase Edge Functions oraz egzekwowanie regionu przetwarzania w UE lub USA.
Czy muszę zmieniać kod?
Wystarczy zmienić adres bazowy i klucz API. Interfejsy do czatu i embeddingów są zgodne z OpenAI, więc oficjalne SDK, LangChain, n8n i większość narzędzi działa bez zmian.
Czyje klucze dostawców są używane?
Twoje. Dodajesz własne klucze OpenAI, Anthropic lub Gemini do obszaru roboczego, a odnoga kieruje przez nie ruch — zachowujesz własne ceny i limity u dostawcy.
Czy mogę przez nią fakturować własnych klientów?
Tak. Jeden nagłówek identyfikujący użytkownika końcowego wystarczy, aby przypisać i rozliczyć każde wywołanie. Zobacz stronę o rozliczeniach wielu klientów.
Czy cache bramki AI zwraca te same odpowiedzi?
Cache to dwie różne rzeczy. Cache odpowiedzi zapamiętuje odpowiedź i zwraca ją ponownie dla identycznego zapytania — model nie jest wołany, więc wywołanie jest darmowe, ale dostajesz wcześniejszą odpowiedź, nie nową. Cache promptu u dostawcy nigdy nie zwraca odpowiedzi: dostawca jedynie taniej odczytuje tekst promptu, który już ma. odnoga prowadzi oba jako dwa osobne przełączniki pod Twoją kontrolą.
Czy cache zmieni moje odpowiedzi?
Może, i mówimy to wprost. Gdy model ma być kreatywny, to samo pytanie zadane dwa razy nie ma jednej poprawnej odpowiedzi, więc zwrócenie zapamiętanej to inny wynik niż nowe wywołanie. Dlatego domyślnie zwracamy zapamiętaną odpowiedź tylko dla wywołań deterministycznych — temperatura 0 albo stały seed. Zwracanie zapamiętanych odpowiedzi dla wywołań kreatywnych jest możliwe, ale to Twój świadomy wybór, nie nasze domyślne ustawienie.
Cache promptu czy cache odpowiedzi — co oszczędza więcej?
Zwrócona z pamięci odpowiedź usuwa cały koszt wywołania; cache promptu u dostawcy obniża tylko koszt powtarzanego tekstu promptu, zwykle sporej części długiego promptu systemowego. Cache odpowiedzi oszczędza więcej na trafienie, ale dotyczy dużo mniejszej liczby wywołań. odnoga liczy oba z Twojej własnej historii zapytań, per funkcja i per workspace, więc widzisz, co realnie się opłaca. Oszczędność to koszt, którego uniknięto, nigdy zwrot pieniędzy.
Powiązane: czym jest bramka LLM · katalog modeli i ceny · multi-tenant billing · bezpieczeństwo i rezydencja · porównanie odnogi