OpenAI/Anthropic API: jak liczyć koszty i latency

Koszty OpenAI i Anthropic API to największa nieprzewidywalna pozycja w budżetach contentowych i produktowych w 2026 roku. Firma, która w styczniu planuje 8 000 PLN/mc, w październiku płaci 34 000 PLN — i nikt nie wie dlaczego. Ten poradnik pokazuje, jak liczyć koszty i opóźnienia API (latency) zanim wdrożycie feature, jak je monitorować na produkcji i jak zbić rachunek o 40–70% bez utraty jakości odpowiedzi.

Opisujemy konkretne cenniki GPT-4.1, GPT-4o-mini, Claude Opus 4.5, Claude Sonnet 4.5 i Claude Haiku 4 w wersjach aktualnych na 2026 rok – wraz z realnymi rachunkami z wdrożeń content ops i asystentów B2B. Podajemy wzory, arkusz kontrolny i trzy wzorce optymalizacji, które w zespołach polskich agencji dały średnio 55% redukcji kosztu na zapytanie bez pogorszenia ocen jakości.

Tekst jest praktyczny, nie marketingowy – żadnego „AI zmienia wszystko”. Jeśli zarządzacie budżetem LLM w firmie lub negocjujecie z klientem cennik za usługi oparte o AI, to jest lektura obowiązkowa.

Anatomia rachunku — jak OpenAI i Anthropic liczą pieniądze

Zarówno OpenAI, jak i Anthropic rozliczają się w modelu „per milion tokenów”, osobno dla wejścia i wyjścia. Token to około 0,75 słowa w języku polskim (gorzej niż w angielskim – polski ma większą gęstość tokenów na znak przez odmianę i znaki diakrytyczne), więc tekst 1 000 słów to zwykle 1 300–1 500 tokenów. Wzór uniwersalny:

koszt_USD = (tokeny_in / 1 000 000) × cena_in + (tokeny_out / 1 000 000) × cena_out

Cennik referencyjny 2026 (USD za 1 mln tokenów)

Model	Input	Output	Cache read	Kontekst
GPT-4.1	2,00	8,00	0,50	1M
GPT-4o	2,50	10,00	1,25	128k
GPT-4o-mini	0,15	0,60	0,075	128k
Claude Opus 4.5	15,00	75,00	1,50	200k–1M
Claude Sonnet 4.5	3,00	15,00	0,30	200k–1M
Claude Haiku 4	0,30	1,50	0,03	200k

Zauważcie dysproporcję input/output – output kosztuje 4–5 razy drożej. To podstawa pierwszej reguły optymalizacji: model ma mówić zwięźle, nie rozwlekle. Każdy niepotrzebny akapit odpowiedzi to pieniądze realne, nie hipotetyczne. Warto poznać też porównanie Ahrefs vs Semrush vs Sistrix 2026.

Dlaczego polski jest droższy niż angielski

Tokenizer GPT i Claude to wariant BPE (byte-pair encoding) wytrenowany głównie na angielskim. Polskie słowo „przedsiębiorstwo” to 4–6 tokenów, podczas gdy angielskie „enterprise” – 1 token. W praktyce identyczny tekst po polsku zjada 1,4–1,8× więcej tokenów niż po angielsku. Dla pipeline’u produkującego 500 artykułów miesięcznie oznacza to realny narzut 40–60% rachunku – warto to uwzględniać w wycenach.

Wzór kalkulacyjny, który powinien znać każdy PM

Nie wystarczy znać cennik, żeby policzyć rachunek. Produkcyjny wzór ma pięć składników – trzy techniczne, dwa operacyjne. Każdy z nich potrafi przekroczyć budżet dwukrotnie, jeśli zostanie pominięty.

Pięć zmiennych produkcyjnego kosztu

1. Średnie tokeny wejściowe na zapytanie – system prompt + kontekst RAG + historia + wiadomość użytkownika. Dla asystenta B2B realnie 4 000–14 000 tokenów.
2. Średnie tokeny wyjściowe na zapytanie – 200–1 500 zależnie od zadania. Klasyfikacja – 50. Generacja artykułu – 4 000+.
3. Liczba zapytań miesięcznie – DAU × zapytań/dzień × dni aktywne + batch pipelines.
4. Retry factor – średnio 8–15% zapytań wymaga ponowienia (rate limit, timeout, błąd walidacji odpowiedzi).
5. Cache hit ratio – procent zapytań, w których część kontekstu trafia w cache (zwraca 0,10 ceny input).

Praktyczny wzór miesięczny:

budżet_miesięczny = N × (T_in × cena_in × (1 - C + C × 0,10) + T_out × cena_out) × (1 + R)

gdzie N = zapytania/mc, T_in/out = tokeny, C = cache hit ratio, R = retry factor.

Przykład — asystent B2B na Sonnet 4.5

Scenariusz: 800 użytkowników, średnio 6 zapytań/dzień każdy, 22 dni robocze. N = 105 600 zapytań/mc. T_in = 8 500 (system prompt 1 200 + kontekst RAG 5 500 + historia 1 800), T_out = 700. Cache hit 45%, retry 10%.

Koszt per zapytanie bez cache: 8 500 / 1M × 3,00 + 700 / 1M × 15,00 = 0,0255 + 0,0105 = 0,036 USD.

Z cache 45%: input efektywny = 8 500 × (0,55 × 3,00 + 0,45 × 0,30) / 1M = 8 500 × 1,785 / 1M = 0,0152 USD. Razem 0,0257 USD.

Miesięcznie: 105 600 × 0,0257 × 1,10 = 2 985 USD ~ 12 100 PLN. Bez cache byłoby 4 180 USD ~ 16 900 PLN. Różnica 28% tylko przez uruchomienie prompt caching.

Latency — co się liczy i jak to mierzyć

Opóźnienie API nie jest jedną liczbą. To trzy zupełnie osobne metryki, z których każda wpływa na inne doświadczenie użytkownika i na inne decyzje architektoniczne.

Trzy metryki latency, które trzeba znać

• TTFT (time to first token) – czas od wysłania zapytania do pierwszego tokena odpowiedzi. Decyduje o wrażeniu „szybkości” w interfejsie streamingu. Realne 2026: Haiku 4 – 600–900 ms, Sonnet 4.5 – 1,2–2,0 s, Opus 4.5 – 2,5–4,5 s, GPT-4o-mini – 400–700 ms, GPT-4.1 – 1,5–3,0 s.
• TPS (tokens per second) – prędkość generowania po starcie. Haiku 4 – 180–260 tps, Sonnet 4.5 – 70–110 tps, Opus 4.5 – 35–60 tps. Dla długich odpowiedzi to najważniejsza metryka.
• Total latency – TTFT + (tokeny_out / TPS). Dla odpowiedzi 1 000 tokenów na Opus: 3,5 s + 1000/45 = 25 s. Dla tego samego na Haiku: 0,8 + 1000/220 = 5,3 s.

Kiedy latency bije koszt w rankingu decyzji

Wszędzie tam, gdzie użytkownik czeka synchronicznie. Czat – tak, czat z ekranem ładowania powyżej 3 s ma retention gorsze o 25%. Panel autocomplete – absolutnie, TTFT powyżej 400 ms jest odczuwalny. Backend pipeline, który wrzuca 5 000 artykułów do kolejki przez noc – latency nie ma znaczenia, liczy się tylko koszt i throughput.

Trzy wzorce optymalizacji, które naprawdę działają

Nie ma magicznej flagi, która obniża rachunek o 80%. Są trzy wzorce, które w kombinacji dają łącznie 50–75% oszczędności w typowym wdrożeniu B2B.

Wzorzec 1 — router model-fit

Zamiast wysyłać wszystkie zapytania na Opus/GPT-4.1, klasyfikujcie intencję prostym klasyfikatorem na Haiku 4 lub GPT-4o-mini (koszt 0,001 USD/zapytanie) i routujcie do właściwego modelu. Rozkład typowy: 60% zapytań trafia do Haiku/Mini (proste fakty, klasyfikacje, parafrazy), 30% do Sonnet 4.5 (średnio złożone zadania generatywne), 10% do Opus 4.5 (reasoning złożony, kod, strategia).

Realna redukcja: z 15 USD/1M tokenów średnio spada do 3,5 USD/1M tokenów. Oszczędność 76% przy identycznej lub lepszej jakości percepcji użytkownika (prostsze modele odpowiadają szybciej – więc subiektywnie lepiej).

Wzorzec 2 — prompt caching i context caching

Anthropic prompt caching i OpenAI context caching pozwalają oznaczyć długi, powtarzalny prefix promptu jako „cachable”. Przy ponownym zapytaniu z identycznym prefixem tokeny wejściowe z prefixu kosztują 10% standardowej stawki. System prompt 2 000 tokenów + instrukcje 3 000 tokenów + 3 przykłady few-shot 2 500 tokenów = 7 500 tokenów cache’owalnych per zapytanie.

Dla API Anthropic cache ważny jest 5 minut (rolling window), więc działa świetnie dla ruchu burstowego. Dla OpenAI cache jest automatyczny i pasuje w oknie 1 godziny. Koszt: wpis do cache to 1,25× normalny input (raz), odczyt 0,10× input (każdy kolejny raz).

Wzorzec 3 — kompresja kontekstu RAG

Klasyczny RAG wysyła 10 fragmentów po 500 tokenów = 5 000 tokenów kontekstu. Optymalny RAG używa reranker (np. Cohere Rerank, Voyage Rerank) i wysyła 3–4 najlepsze fragmenty po 400 tokenów = 1 500 tokenów. Jakość odpowiedzi – niezmieniona lub lepsza (mniej szumu), koszt wejścia – 70% niższy.

Dodatkowo warto stosować tzw. contextual compression – drugi tani model (Haiku) skraca fragmenty do esencji przed wysłaniem do modelu głównego. To dodatkowe 30–50% redukcji tokenów na dłuższych kontekstach. Szczegóły integracji RAG z platformami danych znajdziecie w cheat sheet WordPress REST API dla marketerów.

Monitoring — co logować, kiedy alertować

Bez monitoringu LLM-a nie da się prowadzić. Ceny mogą zmienić się z dnia na dzień (Anthropic obniżył Sonnet o 30% między 2024 a 2025, OpenAI obniżył GPT-4o dwa razy w 2025), a zapytania mogą wybuchnąć przy jednej nieprzetestowanej pętli rekurencyjnej.

Minimalny zestaw metryk na produkcji

1. Koszt per endpoint – ile każdy endpoint API kosztuje na zapytanie i dziennie łącznie. Dashboard + alert przy 1,5× odchyleniu od baseline.
2. P95 i P99 TTFT – percentyle opóźnień, nie średnia. Średnia ukrywa ogon rozkładu, w którym siedzą userzy, którzy porzucają produkt.
3. Tokens per request – histogram wejściowych i wyjściowych. Skok p95 sygnalizuje zmianę w promptach albo wzrost danych RAG.
4. Error rate – per typ błędu: rate_limit, context_too_long, timeout, content_filter. Każdy ma inny remedy.
5. Retry ratio – procent zapytań, które poszły drugi raz. Powyżej 15% to sygnał, że coś się psuje w upstream.
6. Cache hit ratio – osobno per endpoint. Spadek poniżej 40% na endpoincie czatowym zwykle oznacza, że ktoś zmienił system prompt.

Alerting — budżetowy i jakościowy

Konfigurujcie co najmniej trzy alerty. Miękki budżetowy – 80% miesięcznego capu – do Slacka na kanał eng. Twardy budżetowy – 100% capu – automatyczny throttling do tanich modeli. Jakościowy – P95 TTFT rośnie o więcej niż 40% dzień do dnia – on-call. Bez tych alertów rachunek skoczy nim zdążycie go zauważyć.

OpenAI vs Anthropic — kiedy co wybrać w 2026

Oba providery konwergują. Oba mają dobre flagowce, dobre tanie modele, prompt caching, vision, tool use, batch API. Różnice są taktyczne, nie strategiczne.

Kryterium	OpenAI	Anthropic
Najlepszy model ogólny	GPT-4.1 (1M context)	Opus 4.5 (reasoning)
Najtańszy użyteczny model	GPT-4o-mini	Haiku 4
Prompt caching	automatyczny, 1 h TTL	jawny, 5 min TTL
Batch API	50% rabatu	50% rabatu
Tool use / JSON mode	strict mode, stabilny	stabilny, lepszy w złożonych
Latency TTFT 2026	szybszy dla mini	porównywalny dla Haiku
Rate limits default	Tier-based, elastyczny	Tier-based, sztywniejszy
Polski język	4o – b. dobry, 4o-mini – dobry	Opus/Sonnet – b. dobry, Haiku – dobry

Praktyczna rekomendacja 2026: jeśli dopiero zaczynacie, trzymajcie się jednego providera, żeby nie mnożyć abstrakcji. Jeśli obsługujecie klienta korporacyjnego, miejcie fallback na drugiego (regulacje, uptime, rate limity). Dla content ops – Anthropic wygrywa jakością outputu w polskim, dla aplikacji czatowych – OpenAI wygrywa taniością mini i szybszym TTFT.

Rate limits i throttling — czego nie ma w dokumentacji

Oficjalne limity to tylko sufit. Realny limit zależy od tier konta, burstowości ruchu i „zachowania” na platformie. Konto z dwumiesięczną historią stabilnego wzrostu dostaje wyższe limity niż świeże konto z nagłym skokiem – nawet przy tym samym zużyciu.

Strategie obchodzenia limitów

• Exponential backoff z jitterem – retry po 1s, 2s, 4s, 8s, 16s, z losowym odchyleniem ±30%. Bez jitteru tysiąc retry-ów uderza w API w tej samej sekundzie po restarcie serwera.
• Token bucket po stronie aplikacji – nie polegajcie na rate limit providera. Licz z góry, ile wysyłacie, i kolejkujcie sami.
• Dual-provider fallback – jeśli OpenAI zwróci 429, automatycznie retry na Anthropic z identycznym promptem. Zwykle kosztuje 20% więcej, ale ratuje SLA.
• Queue offload do Batch API – wszystko, co nie musi być real-time, wysyłajcie przez /v1/batches. 50% rabatu i osobna pula limitów.

Rzeczywiste limity na Tier 4 (2026)

OpenAI Tier 4 (miesięczne zużycie 250+ USD): GPT-4o 10 000 RPM, 30M TPM. Anthropic Tier 4 (400+ USD/mc): Sonnet 4.5 – 4 000 RPM, 800k TPM. Dla większości aplikacji B2B te limity są wystarczające – problemy zaczynają się przy batch processing, gdzie 30M tokenów/min skończą się w 4 minuty przy normalnej pracy. Podobnie ograniczenia czasowe dotyczą integracji GA4 i Ads – praktyczne zastosowania API GA4, Search Console, Ads mają swoje własne limity.

Jak budżetować wdrożenie AI dla klienta

Agencje popełniają systematycznie dwa błędy przy wycenie projektów AI: niedoszacowanie skali zapytań i zerowy zapas na wzrost. Efekt – po 3 miesiącach produkcji rachunek wynosi 3× budżet i trzeba tłumaczyć klientowi, dlaczego.

Framework wyceny LLM w 5 krokach

1. Estymacja N na podstawie POC – przepuśćcie prawdziwy ruch przez API przez 2 tygodnie w trybie test, zanotujcie rzeczywiste zapytania i tokeny.
2. Ekstrapolacja z zapasem – pomnóżcie POC × 3 (bo produkcja ma 3× więcej edge case’ów niż test).
3. Dobranie modelu i cache – obliczcie koszt na trzech wariantach: flagowiec, średni, tani – i wybierzcie ten, który daje 95% jakości przy najniższym koszcie.
4. Zapas wzrostu 30% – bo produkt skaluje się, bo marketing włącza nowe kampanie, bo ktoś zawsze zapomni o limitach.
5. Kwartalna rewizja – ceny spadają średnio 40%/rok, więc co kwartał robi się tańsze przy identycznej konfiguracji. Wasz klient tego nie wie – to jest pole do negocjacji.

Przykład wyceny — chatbot dla polskiego SaaS

Klient: SaaS B2B, 2 500 użytkowników, 8 zapytań/dzień każdy, 22 dni. N = 440 000 zapytań/mc. Model – Sonnet 4.5 dla 60% ruchu, Haiku 4 dla 40%. Cache hit 50%. Tokens: T_in = 6 500, T_out = 550. Rachunek netto – 2 400 USD/mc ~ 9 700 PLN. Z zapasem 30% – 3 120 USD/mc ~ 12 600 PLN. Do tego infra (Vercel, bazy, observability) 800–1 500 PLN. Suma: 13 000–14 000 PLN/mc. To jest liczba, którą wpiszecie w umowę.

Najczęstsze błędy — czego unikać

• Liczenie tokenów w słowach – polski ma 1,4× gorszy współczynnik. Używajcie tiktoken lub SDK providera do precyzyjnego liczenia.
• Trzymanie całej historii czatu w każdym zapytaniu – po 20 turach kontekst puchnie do 15k+ tokenów. Stosujcie sliding window 10 tur + podsumowanie.
• Brak timeoutów po stronie klienta – zapytanie wisi 180s, a użytkownik już dawno poszedł. Twardy timeout 30–45s, retry z krótszym kontekstem.
• Model „Opus dla wszystkiego” – droższy ~5× od Sonnet, a dla 70% zadań daje identyczny wynik.
• Ignorowanie output tokens w limitach – rate limit liczy in+out łącznie. Długie odpowiedzi zjadają throughput szybciej niż myślicie.
• Brak logowania tokenów per zapytanie – nie da się potem zrobić retrospektywy kosztu; logujcie usage z każdej odpowiedzi.
• Streaming bez backpressure – 1 000 userów jednocześnie streamujących dusi serwer Node’a. Stosujcie queue.
• Ignorowanie Batch API – 50% rabatu dla nic nie-real-time to grzech zaniechania.

Narzędzia do kalkulacji i monitoringu

Nie musicie budować wszystkiego od zera. Ekosystem narzędzi 2026 jest gęsty – problem polega raczej na wybraniu kilku, które ze sobą współpracują.

Kalkulatory cen

• OpenAI Tokenizer (platform.openai.com/tokenizer) – podstawa, ale liczy tylko dla GPT. Dla polskiego średnio precyzyjny.
• Anthropic Token Counter API – dedykowany endpoint /v1/messages/count_tokens, precyzyjny.
• llm-pricing.com – porównywarka cen wszystkich dostępnych API, aktualizowana co tydzień.
• openrouter.ai – agregator API z jednym billingiem, dobra opcja dla testów wielu modeli.

Observability i tracing

• Langfuse (open source, self-host lub cloud) – pełny trace, koszty, evaluations, datasets. Standard 2026 dla zespołów ML.
• Helicone – proxy + dashboard, zero-code integracja, dobry dla MVP.
• Braintrust – lepszy dla eval-driven development, drogi ale świetny dla enterprise.
• LangSmith (LangChain) – jeśli jesteście na LangChain, naturalny wybór.
• OpenTelemetry + GenAI semantic conventions – dla zespołów z własnym stackiem obs (Datadog, Grafana, New Relic).

FAQ — najczęstsze pytania

Czy naprawdę warto płacić za Opus 4.5 zamiast Sonnet 4.5?

Tylko dla zadań wymagających złożonego rozumowania – analiza strategiczna, kod wielomodułowy, planowanie w wielu krokach. Dla 80% realnych zadań content ops Sonnet 4.5 daje odpowiedź o jakości porównywalnej. Różnica cenowa 5× oznacza, że Opus ma sens tylko wtedy, kiedy jakość Sonnet realnie blokuje proces – a nie jest to często.

Jak szybko ceny API spadają z roku na rok?

Od 2023 do 2026 ceny flagowców OpenAI spadły o 85% (GPT-4 w 2023 kosztował 30 USD/1M input, GPT-4.1 w 2026 – 2 USD). Anthropic – podobnie. Średnie tempo spadku to 40–50% rok do roku. Planując budżet roczny, realnie można założyć 20–25% spadku kosztu przy niezmienionym zużyciu – albo 25% wzrostu zużycia przy niezmienionym budżecie.

Prompt caching czy fine-tuning — co bardziej opłacalne?

Prompt caching dla 90% przypadków. Fine-tuning ma sens tylko wtedy, gdy macie 10k+ przykładów wysokiej jakości i specyficzny format odpowiedzi. Koszt fine-tuning GPT-4o-mini to 3 USD/1M tokenów treningowych + 0,30 USD/1M tokenów inference. Dla typowego use case’u content ops oszczędności nie przewyższają czasu na przygotowanie datasetu. Cache jest darmowy do skonfigurowania i daje efekt natychmiast.

Jak mierzyć jakość odpowiedzi, żeby nie zdegradować jej po optymalizacji?

Zbudujcie dataset 100–300 reprezentatywnych zapytań z oczekiwanymi odpowiedziami (ground truth albo „preferowane” vs „niepreferowane”). Po każdej zmianie modelu/cache/promptu puszczajcie eval – LLM-as-a-judge (tańszy model ocenia odpowiedzi drożego w trzech wymiarach: poprawność, zwięzłość, ton). Langfuse i Braintrust mają to out-of-the-box. Bez evalu optymalizacja jest ślepa.

Czy trzymać klucze API po stronie klienta w aplikacji?

Nigdy. Klucz API w kodzie frontendowym to gwarancja utraty go w tygodniu. Wszystkie zapytania przez własny backend, który trzyma klucz w zmiennej środowiskowej lub w managerze sekretów (AWS Secrets Manager, GCP Secret Manager, Vault). Dodatkowo – rate limiting i auth per użytkownik, żeby jeden klient nie zużył budżetu wszystkich.

Ile realnie kosztuje obsługa 1 000 DAU chatbota B2B?

Realnie 1 800–3 500 USD/mc ~ 7 300–14 200 PLN/mc dla konfiguracji Sonnet 4.5 + cache + RAG. Zmienne: długość kontekstu, liczba zapytań/user/dzień, cache hit ratio, udział Haiku w ruchu. Każde zapytanie to 0,02–0,05 USD – mnożone przez 100 000–200 000 zapytań/mc daje taki rząd wielkości. Bez cache i z samym Opus – łatwo 3–4× tyle.

Czy Batch API naprawdę wpływa na czas dostarczenia odpowiedzi?

Tak – Batch API gwarantuje dostarczenie w ciągu 24 godzin, realnie zwykle 2–8 godzin. Nie pasuje do real-time, ale idealnie do generacji artykułów, transkrypcji, masowych ocen, kompresji RAG offline. 50% rabatu to nie błąd zaokrąglenia – to realna różnica, która przy masowym content ops robi z rachunku 5 000 PLN rachunek 2 500 PLN.

Jak liczyć latency dla streamingu vs non-streaming?

Dla streamingu liczy się TTFT – użytkownik widzi pierwszy token i ma wrażenie, że coś się dzieje. Dla non-streaming liczy się total latency – żadnej odpowiedzi aż do końca. Non-streaming jest o 5–15% szybszy w sumarycznym czasie (brak overhead protokołu), ale subiektywnie użytkownik myśli, że streaming jest 2× szybszy. Dla UI zawsze streaming, dla backend pipeline – non-streaming prostszy w obsłudze błędów.

Co dalej

Jeśli chcesz pogłębić temat, sprawdź Stack marketingowy 2026: narzędzia, API i automatyzacje. Przydatne będzie też WordPress REST API dla marketerów — oba materiały dobrze uzupełniają powyższy artykuł.