W niedzielę 18 października Jared Siegel opublikował na swoim blogu esej, którego tytuł w oryginale zawiera mocne przekleństwo. W spokojnej wersji: jeśli nie prowadzisz własnego proxy do modeli językowych, to skąd wiesz, co się dzieje z twoim ruchem. Na Hacker News tytuł wygładzono, a wątek urósł do 182 punktów i 128 komentarzy, które przeczytałem w całości dzień później. Teza jest krótka: panele analityczne laboratoriów wyglądają jak narzędzia dla inżynierów, a służą do oglądania.
Siegel kupuje subskrypcje dostawców i nie namawia do ich odstawienia. Twierdzi za to, że realną widoczność kosztów i błędów dostaje się dopiero wtedy, kiedy cały ruch do modeli przechodzi przez proxy we własnej infrastrukturze. Z tego tekstu zostaje rozumienie argumentów, mapa głosów z dyskusji, w tym krytycznych, oraz droga startu z LiteLLM według dokumentacji z odczytu 19.10.
- Najważniejsze informacje
- Panel dostawcy to rozrywka, nie narzędzie
- Pięć powodów z eseja, po polsku
- Co na to Hacker News
- Jak zacząć: LiteLLM wg dokumentacji
- Co z tego dla kogoś płacącego z Polski
- Najczęstsze pytania
Najważniejsze informacje
| Co daje własny proxy | Po co ci to | Gdzie haczyk |
|---|---|---|
| Jeden endpoint dla wielu dostawców | Zmiana modelu bez przepinania kodu aplikacji | Trzeba postawić i utrzymać usługę |
| Logi: klucz, model, klient, czas, status | Diagnoza awarii i kosztów w sekundy | Logi zajmują miejsce i zawierają treść rozmów |
| Wirtualne klucze API | Główny klucz dostawcy zostaje tylko u ciebie | Pełna funkcjonalność wymaga bazy danych |
| Budżety i limity per klucz | Wydatek widać na bieżąco, nie z faktury | Bez bazy dokumentacja wprost ostrzega: limit nie zadziała |
| Szybka zmiana dostawcy | Podmiana wpisu w konfiguracji | Jakość i zachowanie modeli się różnią |
| Kontrola nad danymi | Ruch nie idzie przez kolejnego pośrednika | Administracja i aktualizacje spadają na ciebie |
Panel dostawcy to rozrywka, nie narzędzie
Siegel nie straszy cenami: sam płaci za subskrypcje, bo to produkt, który firmy sprzedają. Dashboard laboratorium z kolorowym wykresem użycia komentuje zdaniem tłumaczonym niemal dosłownie: „To jest rozrywka. To nie są statystyki użycia tokenów z danymi czasowymi dla inżynierów”. W oryginale: „That is a distraction. That is not token usage statistics with time series data meant for engineers”. Dopowiada w mocniejszym słownictwie, że nie podejmie na takim panelu żadnej decyzji.
Autor przewiduje pierwszą ripostę: przecież są eksporty OTel. Odpowiada lakonicznym „Cool, I guess”. Sprawdziłem u źródła: Claude Code od Anthropicu eksportuje metryki i zdarzenia przez OpenTelemetry po ustawieniu zmiennych jak CLAUDE_CODE_ENABLE_TELEMETRY oraz adresu kolektora (dokumentacja, odczyt 19.10). To jednak telemetria narzędzia, a nie logi żądań: który klucz, jaki model, jaki klient, kiedy i z jakim statusem.
Ciekawe, że Siegel nie poleca żadnego gotowego narzędzia. Prosi o jedno: uruchom cokolwiek tam, gdzie masz kontrolę, i zmieniaj pod siebie; swój proxy przerobił o lepszą diagnostykę i własne endpointy MCP. Na koniec przykład: kiedy widzi cache miss w trakcie sesji kodowania, ustala przyczynę ręcznie w dwadzieścia sekund. Nie zautomatyzował tego, ale jego proxy ma API, więc da się.
Pięć powodów z eseja, po polsku
Autor wypisuje je jednym tchem. Rozwijam po kolei, bo dopiero przy konkrecie widać ich wagę.
Pierwszy: jeden endpoint dla wielu dostawców i modeli. Twoje skrypty, edytory i agenci AI mówią do jednego adresu w formacie OpenAI, a za nim siedzi tyle modeli, ile wpiszesz w konfiguracji. Zmiana dostawcy to edycja pliku, nie poprawki w pięciu projektach. Siegel pisze o szybkim pivocie „bez ustawiania wszystkiego od zera”; każdy, kto przenosił kod między API dwóch firm, wie, o co chodzi.
Drugim powodem są logi: pełne zapisy żądań z kluczem, modelem, klientem, czasem i statusem. Cache miss przestaje być zagadką, bo widać, który agent co wysłał i dlaczego nie trafiło do pamięci podręcznej. viccis opisuje drugą stronę tej samej monety: 5-minutowy TTL cache w subskrypcji Claude, który jego podagenci rozjeżdżali czekaniem na dziesięciominutowe testy. Bez logów dowiedział się o tym po fakcie, patrząc na wypalone limity.
Trzeci: wirtualne klucze. Zamiast wklejać główny klucz dostawcy w każdy skrypt, wystawiasz z proxy osobne, pożyczalne klucze z własnym budżetem i zakresem. hoppp stawia taką bramkę przed agentami w sandboxach i tłumaczy, że „provider API keys never go near the sandbox”, czyli klucze dostawców nigdy nie trafiają do izolowanego środowiska. To logika znana z MCP: pośrednik decyduje, co z czym się łączy.
Czwarty: infrastruktura pod twoją kontrolą. Alternatywą jest bramka u firmy trzeciej, jak OpenRouter; impure potwierdza na HN, że to wygodne, przyznaje jednak, że dla własnych aplikacji dokłada jeszcze jeden serwer, żeby klient nie zobaczył klucza API. Przy bramce trzeciej strony twój ruch i klucze trafiają do kogoś innego. Własne proxy tę zależność usuwa, administrację zostawia tobie.
Piąty: szybkość zmiany decyzji. Kiedy wychodzi nowy model albo dostawca podnosi ceny, w konfiguracji przesuwasz alias na inny wpis i aplikacje dalej wołają ten sam adres. Haczyk, którego Siegel nie rozwija: jakość nowych modeli bywa różna, więc sam pivot trwa chwilę, a sprawdzenie, czy nic się nie posypało, już niekoniecznie.
Co na to Hacker News
Dyskusja zebrała trzy obozy. Pierwszy to praktycy, którzy tak już pracują; kennywinker skraca całą debatę do jednego zdania: homelab z LiteLLM albo gomodel. TuxedoBuddy przywołuje porównanie: jedni są zadowoleni z routera od dostawcy internetu, bo działa, a inni stawiają pfSense, choćby po to, żeby zajrzeć do środka.
Drugi obóz to sceptycy i mają argumenty. jubilanti pyta, co by było, gdyby LiteLLM i podobne narzędzia nie były „buggy vibecoded messes”, i podejrzewa przy tempie wydawnictw luki bezpieczeństwa. zaptheimpaler poleca w zamian Bifrosta jako „quality piece of software, unlike LiteLLM”. chopete3 uważa, że proxy to dodatkowy punkt awarii i wskazuje agentsview, narzędzie do podglądu pracy agentów bez pośrednika. vasco wytyka pozę przy ręcznym oglądaniu trafień cache, a crossroadsguy nazywa to zjawisko „setup-theatre as a hobby”. jakozaur dorzuca niuans: proxy ma sens przy płatności za tokeny, bo przy subskrypcjach lepiej zbierać pliki sesji z ~/.claude/projects/.
Trzeci wątek to pieniądze. NeutralWanted liczy na swoim przykładzie: subskrypcja za 200 dolarów miesięcznie, którą maksuje co tydzień, spaliła równowartość 200 dolarów na API w dwa, trzy dni. dcss_gardener tłumaczy, dlaczego tak wychodzi: subskrypcje są dotowane, a tanie tokeny to „acquisition tool”, narzędzie zdobywania rynku, nie produkt. nl, mając wgląd w kilka zespołowych subskrypcji Claude, szacuje, że maksuje je ledwie 10% ludzi, i przywołuje 90% marżę na API. Darkphibre wylicza, że jego cztery dni pracy w cenach API kosztowałyby ponad 3000 dolarów. Wniosek nie brzmi „proxy jest tańsze”. Brzmi: dopóki płacisz ryczałt, nie musisz wiedzieć; kiedy przechodzisz na płatność za tokeny, musisz.
Jak zacząć: LiteLLM wg dokumentacji
Do sekcji praktycznej wybrałem LiteLLM. W wątku pada najczęściej, licencja MIT, dokumentacja kompletna i świeża, a etykiety i komendy poniżej pochodzą z odczytu 19.10. Uczciwie: część komentujących woli Bifrosta.
Najszybsza droga z dokumentacji prowadzi przez Dockera. Quickstart składa dwie usługi: bramkę na porcie 4000 i Postgresa, który trzyma modele, klucze oraz logi wydatków.
curl -sSLO https://github.com/BerriAI/litellm/raw/main/docker/docker-compose.quickstart.yml
printf 'LITELLM_MASTER_KEY=sk-%s\nLITELLM_SALT_KEY=sk-%s\n' "$(openssl rand -hex 32)" "$(openssl rand -hex 32)" > .env
docker compose -f docker-compose.quickstart.yml up -dLITELLM_MASTER_KEY to główne hasło administracyjne, traktowane w dokumentacji jak hasło roota; ma nie trafić do repozytorium. LITELLM_SALT_KEY szyfruje klucze dostawców zapisane w bazie, a jego późniejsza zmiana czyni je nieczytelnymi, więc plik .env zostaje na miejscu. Jest też jednolinijkowy skrypt startowy; to nadal kod z internetu, przeczytaj go przed odpaleniem.
Panel administracyjny siedzi pod adresem http://localhost:4000/ui, login to admin, a hasłem jest wartość LITELLM_MASTER_KEY z pliku. W zakładce „Models + Endpoints” wybierasz dostawcę i modele z katalogu, wklejasz klucz dostawcy, przycisk „Test Connect” weryfikuje go u źródła, po czym model ląduje na liście z zamapowanym cennikiem. „Playground” pozwala wysłać wiadomość testową, a odpowiedź pokazuje latencję i liczbę tokenów.
Wirtualne klucze zakładasz w sekcji „Virtual Keys” przyciskiem „Create New Key”. Każdy dostaje własny budżet, limity i zakres modeli, a wydatki są liczone automatycznie; klucz pokazywany jest jednorazowo. Programowo wygenerujesz go żądaniem POST na endpoint /key/generate z kluczem głównym w nagłówku autoryzacji. Aplikacje wołają potem bramkę jak zwykłe API OpenAI, tylko z adresem http://localhost:4000 i wirtualnym kluczem.
Haczyk zapisany czarno na białym: bez bazy danych budżety nie działają. Dokumentacja wprost pisze, że max_budget bez bazy nie zostanie wymuszony i proxy będzie serwować żądania po przekroczeniu limitu. Dlatego quickstart stawia Postgresa od razu, a nie jako opcję.
Co z tego dla kogoś płacącego z Polski
Po pierwsze: gdzie to postawić. Wystarczy maszyna pracująca w domu albo niewielki VPS w Unii; cen tu nie podam, bo nie zbierałem ofert i nie chcę zgadywać. Jeśli instancja ma być osiągalna spoza twojej sieci, dochodzi HTTPS i porządne hasło, bo na bramce wisi twój klucz dostawcy.
Po drugie: dane osobowe. lionkor przypomina w wątku, że w Unii chaty mogą zawierać PII, nawet pojedyncze zdanie o czyjejś dysleksji, i radzi traktować takie zapisy jak dane osobowe, nie jak kod. Logując pełną treść żądań zostajesz opiekunem tego zbioru. Dopiszę od siebie: logi lokalnie, retencja krótka, zero kopii w przypadkowej chmurze.
Po trzecie: pieniądze. Proxy sam z siebie rachunku nie obniży: daje widoczność i ograniczniki, a oszczędzanie zaczyna się od decyzji, co przeciąć i który agent idzie na tańszy model. O rachunku za tokeny versus ryczałt pisaliśmy przy tekście o tym, czy warto płacić za ChatGPT; liczba NeutralWanteda, 200 dolarów w dwa, trzy dni, pokazuje, jak szybko API potrafi przebić abonament.
Najczęstsze pytania
LLM proxy co to jest?
Pośrednik między twoimi programami a dostawcami modeli. Aplikacje wysyłają żądania w znanym formacie OpenAI na jeden lokalny adres, proxy przekazuje je do wybranego dostawcy, zapisuje log i pilnuje limitów. W kodzie zmienia się adres i klucz, nic więcej.
Czy proxy zadziała z subskrypcją Claude Code?
W dokumentacji LiteLLM jest osobny tutorial o podpięciu Claude Code z subskrypcją Max; link wkleił w wątku selcuka, treści nie weryfikowałem na żywo. Przy subskrypcjach, jak podkreśla jakozaur, część danych wyciągniesz prościej z plików sesji na dysku niż z ruchu przez bramkę.
Jaki open source proxy wybrać na start?
LiteLLM, jeśli chcesz od razu panel, wirtualne klucze i budżety. Bifrost, jeśli przekonuje cię ocena części komentujących na HN, że jest stabilniejszy. Ja biorę LiteLLM dla dokumentacji, bez roszczeń do uniwersalności.
Źródła
- Jared Siegel, esej o własnym proxy do modeli LLM, jrdsgl.com, odczyt 2026-10-19: https://jrdsgl.com/if-you-dont-run-your-own-llm-proxy-how-the-fuck-do-you-even-know-whats-going-on/
- Wątek na Hacker News, pełne drzewko komentarzy przez Algolia API, odczyt 2026-10-19: https://hn.algolia.com/api/v1/items/50145507
- LiteLLM, Quickstart: instalacja, Admin UI, pierwszy klucz, odczyt 2026-10-19: https://docs.litellm.ai/docs/proxy/quick_start
- LiteLLM, Virtual Keys: master key, baza danych, generowanie kluczy, odczyt 2026-10-19: https://docs.litellm.ai/docs/proxy/virtual_keys
- Anthropic, Monitoring Claude Code, eksport OpenTelemetry, odczyt 2026-10-19: https://docs.claude.com/en/docs/claude-code/monitoring-usage
Aktualizacja z 21 października 2026: wersja 1.107.0 paczki litellm na PyPI przez około dwie godziny niosła złodzieja kluczy API i backdoor, wstrzyknięte skradzionymi tokenami OAuth do procesu wydawniczego. Poradnik powyżej pozostaje aktualny, ale przypnij wersję (1.106.2 jest czysta) i rotuj klucze, jeśli instalowałeś coś w tym oknie; szczegóły ataku rozkładam we wpisie zainfekowana paczka litellm na PyPI.