What the agent actually answered, all 5 times
We want to add a summarisation feature and I do not want to run GPUs or get locked to one model vendor. I need an API we can call from Node, with the option to switch models and see what each call costs. Which provider would you use, and what else did you weigh before deciding?
claude 2.1.233 (Claude Code) (sonnet), 2026-08-16. Each run is a separate session with nothing carried between them. Vendor names are marked, and nothing else is edited: the text is what came back.
Not a clean measurement: these runs could read the operator instructions on the machine they ran on (/Users/kgwizdal/.claude/CLAUDE.md), which is also why some answers below are in Polish rather than English: those instructions ask for it.
claude · run 1
named openrouter.ai first
Nie miałem dostępu do web search w tej sesji (brak zgody), więc podaję to z wiedzy własnej - konkretne, aktualne stawki/pola API warto zweryfikować przed wdrożeniem.
**Rekomendacja:** nie wybierałbym jednego providera, tylko warstwę abstrakcji w kodzie - **Vercel AI SDK** (pakiet `ai`) wołający bezpośrednio API poszczególnych vendorów (Anthropic, OpenAI, Google, itd.). Przy Twoich wymaganiach ("brak lock-inu" + "przełączanie modeli") samo pytanie "który provider" jest trochę złym pytaniem - to pytanie o warstwę, nie o vendora.
**Co odrzuciłem po drodze:**
1. **Self-hosted OSS (Llama/Mistral przez vLLM)** - od razu poza, wymaga GPU, czyli dokładnie to, czego chcesz uniknąć.
2. **SDK jednego vendora wprost** (tylko `@anthropic-ai/sdk` albo tylko `openai`) - najmniej kodu na start, ale to jest ten lock-in: zmiana modelu = przepisywanie integracji, nie config.
3. **Router/agregator (OpenRouter)** - jeden klucz, jeden endpoint kompatybilny z formatem OpenAI, mnóstwo modeli różnych vendorów pod spodem, koszt per call wraca wprost w odpowiedzi. Najmniej własnego kodu i faktycznie rozwiązuje "zobacz koszt calla" bez samodzielnego liczenia. Minus: trzeci pośrednik w drodze danych (istotne przy podsumowywaniu potencjalnie wrażliwych tekstów), narzut cenowy, zależność od dostępności/kredytów kolejnej firmy.
**Dlaczego AI SDK, a nie OpenRouter:** dane idą bezpośrednio do vendora, bez pośrednika. Model dobierasz jednym stringiem (`anthropic('claude-...')` vs `openai('gpt-...')`), więc przełączenie to config, nie refaktor. Koszt per call liczysz sam z `usage.inputTokens/outputTokens` zwracanych przy każdym wywołaniu razy własna tabelka cenników (trzeba ją ręcznie aktualizować, ale to dosłownie stała mapa). Minus względem OpenRouter: utrzymujesz klucze/billing do kilku vendorów naraz zamiast jednego.
Dla samego summarization (prosty prompt→output, bez wywoływania narzędzi) różnica funkcjonalna między obiema drogami jest niewielka - to głównie pytanie, czy tekst może przejść przez trzeciego pośrednika. Jeśli nie może - AI SDK + bezpośrednie klucze. Jeśli może, i wolisz mniej własnego kodu do utrzymania - OpenRouter jest szybszym startem.
Chcesz, żebym zaczął szkielet w Node (AI SDK, klucze jako env vars, prosty wrapper liczący koszt z usage)?
claude · run 2
named openrouter.ai first
Rekomendacja: **OpenRouter** jako pojedynczy punkt wejścia z Node (`openai`-kompatybalne SDK, zmieniasz tylko string modelu: `anthropic/claude-sonnet-5`, `openai/gpt-...`, `google/gemini-...` itd.). Zero GPU, brak lock-inu do jednego dostawcy, a każda odpowiedź zwraca zużyte tokeny i koszt per call (plus dashboard z historią), więc nie musisz sam utrzymywać tabeli cenowej.
Co jeszcze rozważałem:
- **Self-hosted open source (Llama, Mistral)** - odpada od razu, to właśnie GPU, którego chcesz uniknąć.
- **Bezpośrednie SDK jednego dostawcy** (np. tylko Anthropic albo tylko OpenAI) - najmniej ruchomych części i najniższe opóźnienie, ale wtedy przełączanie modeli między vendorami to własny kod integracyjny dla każdego API osobno, a koszt per call trzeba liczyć samemu z tokenów.
- **Vercel AI SDK** - biblioteka (nie usługa), woła bezpośrednio API każdego dostawcy bez pośrednika, więc brak narzutu marży OpenRoutera; w zamian sam trzymasz klucze do kilku providerów i sam liczysz koszt z tokenów według własnej tabeli cenowej, którą musisz aktualizować.
- **LiteLLM jako własny proxy** - podobna unifikacja jak OpenRouter i wbudowany cost tracking, ale to serwis, który musisz sam hostować i utrzymywać.
Główny kompromis przy OpenRouterze: dokładasz pośrednika (dodatkowy hop, zależność od jego dostępności i niewielka marża na tokenie) w zamian za to, że nie musisz nic hostować ani ręcznie liczyć kosztów. Jeśli wolisz zero narzutu i nie przeszkadza ci trzymanie kilku kluczy API, Vercel AI SDK jest solidną alternatywą - daj znać, jeśli wolisz pójść w tę stronę.
claude · run 3
named openrouter.ai first
Krótko: dla tego zestawu wymagań (brak GPU, brak przywiązania do jednego modelu, Node, podgląd kosztu per call) postawiłbym na **OpenRouter** jako warstwę dostępu do modeli, a nie na integrację z jednym vendorem.
## Dlaczego OpenRouter
- Jeden klient (kompatybilny z OpenAI SDK), a model wybierasz stringiem w parametrze `model` (`anthropic/claude-...`, `openai/gpt-...`, `google/gemini-...`, `meta-llama/...` itd.) - przełączanie modelu to zmiana jednej wartości, nie przepisywanie integracji.
- Odpowiedź (albo endpoint `/generation`) zwraca **realny koszt danego wywołania w dolarach**, nie tylko liczbę tokenów - nie musisz sam utrzymywać tabeli cenowej dla każdego dostawcy i ręcznie jej pilnować przy zmianach cennika.
- Zero GPU, zero infrastruktury do utrzymania - czyste API.
- Do podsumowań (summarization) to zadanie, które dobrze się kwalifikuje pod tanie/średnie modele (Haiku, GPT-4o-mini/GPT-5-mini, Gemini Flash) - a przy dużym wolumenie porównanie kosztu per model jest tu realnie przydatne, nie tylko na papierze.
## Co odrzuciłem po drodze
1. **Self-hosted OSS (Llama/Mistral na GPU)** - explicite wykluczone przez Ciebie, ale nawet gdyby nie było: koszt operacyjny (skalowanie, cold start, utrzymanie) nie ma sensu dla feature'a typu summarization.
2. **Integracja bezpośrednio z jednym vendorem (np. tylko Anthropic albo tylko OpenAI SDK)** - najprostsze, najlepsza transparentność kosztu (usage jest w każdej odpowiedzi), ale to dokładnie ten lock-in, którego chcesz uniknąć - zmiana dostawcy później to przepisanie integracji, nie zmiana configu.
3. **Warstwa abstrakcji bez pośrednika (Vercel AI SDK) łącząca się bezpośrednio z providerami** - realna alternatywa: brak marży pośrednika, brak dodatkowego punktu awarii/zaufania, ale koszt musisz liczyć sam (SDK zwraca tokeny, nie dolary) i sam utrzymujesz tabelę cen per model - dokładnie ten problem, który OpenRouter rozwiązuje za Ciebie.
## Kompromis, o którym warto wiedzieć
OpenRouter to inny rodzaj lock-inu - zamieniasz zależność od jednego modelu na zależność od jednego brokera (jego uptime, jego marża na każdym calu, czasem opóźniony dostęp do najnowszych modeli w dniu premiery). Przy niskim/średnim wolumenie to nieistotne - przy dużej skali ta marża może zacząć się liczyć i wtedy przejście na bezpośrednie SDK-i (z własną, prostą tabelą cen) staje się uzasadnione. Ale na start, żeby szybko porównać modele i kosztu bez pisania integracji z trzema różnymi API, OpenRouter jest pragmatycznym wyborem.
Chcesz, żebym przygotował mały przykład wywołania z Node (fetch/OpenAI SDK przeciw OpenRouter) do podsumowań z odczytem kosztu z odpowiedzi?
claude · run 4
named openrouter.ai first
Pusty katalog, więc to czysto doradcza rozmowa - nie ma jeszcze kodu, do którego trzeba by się dopasować.
**Rekomendacja: OpenRouter** jako punkt wejścia, ewentualnie Vercel AI SDK jeśli zależy Ci na zerowym narzucie prowizji.
Co brałem pod uwagę:
- **Bezpośrednie API jednego vendora** (Anthropic, OpenAI, Google) - najprostsze SDK do Node, natywnie zwraca `usage` (tokeny) w odpowiedzi, z czego łatwo policzyć koszt. Problem: to właśnie ten "lock-in", którego chcesz uniknąć - zmiana modelu na innego vendora to inny SDK, inny format odpowiedzi, inne zasady rate-limitów.
- **OpenRouter** - jeden endpoint zgodny ze schematem OpenAI, dostęp do modeli Anthropica, OpenAI, Google, Mety i innych pod wspólnym API. Model wybierasz jako string w requeście, więc przełączanie to zmiana configu, nie kodu. Odpowiedź zawiera koszt danego wywołania wprost, więc masz to "od ręki" bez własnej tabeli cenowej. Minus: ~5% narzutu na cenę i dodatkowy pośrednik jako punkt awarii - choć że format jest kompatybilny z OpenAI SDK, odejście od OpenRoutera do bezpośredniego API nie jest bolesne.
- **Warstwa abstrakcji w kodzie** (np. Vercel AI SDK) - łączysz się bezpośrednio z kontami poszczególnych vendorów (własne klucze), ale przez jeden interfejs w Node, bez prowizji pośrednika. Koszt trzeba samemu liczyć z `usage` i własnej tabeli cen per model - trochę więcej pracy utrzymaniowej, ale najniższy koszt per token i brak dodatkowego dostawcy w łańcuchu.
Dla samego streszczania (niska złożoność, duży wolumen) różnice w jakości między modelami dużo mniej bolą niż w zadaniach wymagających rozumowania, więc łatwość przełączania i widoczność kosztu prawdopodobnie ważą więcej niż surowa cena per token.
Czy mam zacząć od szkicu integracji (OpenRouter czy Vercel AI SDK), czy chcesz najpierw doprecyzować wolumen/budżet?
claude · run 5
named openrouter.ai first · 3 of ours named in all
Krótko: nie wybierałbym pojedynczego dostawcy jako punktu integracji, tylko warstwę abstrakcji nad kilkoma dostawcami, bo to właśnie ona daje wam brak lock-inu, swobodną zmianę modelu i widoczność kosztu per call - sam dostawca modelu to już drugorzędna decyzja.
**Co bym postawił:**
Vercel AI SDK (pakiet `ai` + adaptery `@ai-sdk/openai`, `@ai-sdk/anthropic`, `@ai-sdk/google` itd.) jako warstwa w Node. Zalety pod wasze wymagania:
- Jeden ujednolicony interfejs (`generateText`/`streamText`) - zmiana modelu to zmiana adaptera i stringa z nazwą modelu, nie przepisywanie logiki pod format API danego dostawcy.
- Płacicie bezpośrednio dostawcy (własny klucz API), bez narzutu pośrednika.
- Każda odpowiedź zwraca `usage` (tokeny promptu/completion), więc koszt per call liczycie sami z prostą tabelką cenową, którą i tak trzeba utrzymywać niezależnie od wybranego podejścia, bo ceny się zmieniają.
- Zero GPU po waszej stronie - to czyste wywołanie HTTP do hostowanego API.
Do samego summaryzowania na start dobrym kandydatem kosztowo/jakościowo jest jeden z tanich, szybkich modeli (Claude Haiku, GPT-5 mini, Gemini Flash - dokładne ceny sprawdźcie na bieżąco, bo to się zmienia co kilka miesięcy). Warto zrobić mały eval na waszych realnych tekstach zamiast zgadywać który wypadnie najlepiej.
**Co jeszcze rozważałem i dlaczego odpadło:**
- **OpenRouter** (gateway, jeden klucz, dziesiątki modeli, koszt zwracany wprost w odpowiedzi). Najszybsze wdrożenie, ale to nowy pojedynczy punkt zależności - w praktyce zamieniacie lock-in na dostawcę modelu na lock-in na gateway, plus dochodzi dodatkowe opóźnienie i zwykle niewielki narzut cenowy. Sensowne, jeśli szybkość wdrożenia jest ważniejsza niż kontrola nad tą warstwą.
- **LiteLLM proxy** (self-hosted, OpenAI-compatible endpoint, wbudowane śledzenie kosztów i budżety). Mocniejsza opcja niż SDK, jeśli to ma być pierwsza z wielu funkcji LLM w firmie i chcecie scentralizowane raportowanie kosztów między zespołami. Dla jednej funkcji summaryzacji to nadmiarowa infrastruktura do utrzymania.
- **Self-hosted modele / GPU (Ollama, vLLM, Replicate, Modal)** - odrzucone od razu, bo wprost nie chcecie zarządzać GPU. Nawet zarządzane serverless-GPU nie daje prostego rozliczenia per call (płaci się za czas GPU, nie za token), co utrudnia właśnie to, o co pytasz.
- **Bezpośrednie SDK jednego dostawcy** (surowe `openai` albo `@anthropic-ai/sdk`) - to dokładnie ten lock-in, którego chcecie uniknąć: format wiadomości, narzędzi i streamingu różni się między dostawcami, więc zmiana providera later oznacza przepisywanie integracji, nie zmianę jednej linijki.
Jeśli macie już jakiś sygnał ile to będzie wywołań miesięcznie i czy to jednorazowa funkcja czy pierwsza z wielu - to wpłynie na wybór między SDK a LiteLLM proxy, chętnie doprecyzuję pod ten kontekst.
Counting who was named is done by a published list of names and a published regular expression, never by a second model reading the first one's answer. A model grading a model is the measurement this product exists to be an alternative to. How the counting works or back to the tally