Claude, modele Anthropic, API i koszty

Claude, wybór modelu, API i realne koszty

Claude to rodzina modeli językowych Anthropic, używana zarówno przez aplikację dla użytkowników, jak i przez API w produktach. Bieżąca generacja nosi numer 5 i daje okno kontekstu miliona tokenów, czyli mniej więcej siedemset stron tekstu w jednym wywołaniu. Ten tekst dotyczy pracy programistycznej: doboru modelu, kosztów i mechanizmów, które te koszty obniżają.

Gdzie właściwie używa się Claude

Trzy powierzchnie i trzy różne zastosowania, które łatwo pomylić przy szukaniu dokumentacji.

Aplikacja Claude to interfejs czatu dla użytkownika końcowego, przydatny do sprawdzenia odpowiedzi, nieistotny dla integracji. Claude API to wywołania HTTP z kluczem, warstwa, na której buduje się produkt. Claude Code to narzędzie wiersza poleceń i wtyczki do edytorów, gdzie model pracuje na Twoim repozytorium: czyta pliki, uruchamia polecenia, wprowadza zmiany.

Ten podział ma znaczenie przy planowaniu wydatków, bo każda powierzchnia rozlicza się inaczej. Aplikacja i Claude Code idą z abonamentu, API z tokenów. Zespół, który testuje pomysł w aplikacji, a potem wdraża go przez API, powinien policzyć koszt osobno dla drugiego scenariusza.

Czwarta droga prowadzi przez narzędzia cudze podłączone własnym kluczem. Samodzielnie hostowany asystent OpenClaw, dawniej Clawdbot działa na Twoim sprzęcie i rozlicza każde wywołanie z Twojego konta w API, więc jego koszt nie mieści się w żadnym abonamencie i rośnie razem z liczbą zadań, które mu oddasz. Przy szerokich uprawnieniach dochodzi do tego ryzyko, że asystent wykona nie to polecenie, o które chodziło, bo tutaj pomyłka kończy się działaniem, a nie samą nietrafioną odpowiedzią.

Modele i który wybrać

Reguła doboru jest krótka. Sonnet obsłuży większość pracy produkcyjnej przy rozsądnej cenie. Opus bierzesz do trudnego rozumowania, długich zadań agentowych i pracy z kodem, gdzie różnica w jakości uzasadnia różnicę w cenie. Fable to najwyższy poziom dla zadań najtrudniejszych, o najdłuższym horyzoncie. Haiku do klasyfikacji, tagowania i przetwarzania masowego, gdzie liczy się przepustowość.

Jedna obniżka obowiązuje w chwili pisania i warto ją znać, bo wygasa: Sonnet 5 rozliczany jest po 2 USD za wejście i 10 USD za wyjście do 31 sierpnia 2026 roku, a od 1 września wchodzą stawki z tabeli. Przy budżecie liczonym na rok policz więc oba okresy osobno, zamiast mnożyć bieżącą stawkę przez dwanaście.

Identyfikatory podawaj dokładnie w tej postaci. To pełne nazwy, nie skróty, więc dopisywanie do nich daty kończy się błędem 404. Wyjątkiem jest Haiku, które ma też wariant z datą.

Pierwsze wywołanie

pip install anthropic
export ANTHROPIC_API_KEY=sk-ant-...

import anthropic

client = anthropic.Anthropic()

odpowiedz = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    system="Odpowiadasz zwiezle, po polsku, bez wstepow.",
    messages=[{"role": "user", "content": "Streszcz ponizsza umowe w pieciu punktach: ..."}],
)

print(odpowiedz.content[0].text)

W TypeScripcie układ jest analogiczny i wpina się bez tarcia w trasę API Next.js.

import Anthropic from '@anthropic-ai/sdk'

const client = new Anthropic()

const wynik = await client.messages.create({
  model: 'claude-opus-5',
  max_tokens: 16000,
  messages: [{ role: 'user', content: pytanie }]
})

Dwie rzeczy warto ustawić od początku. Parametr max_tokens jest wymagany i ogranicza długość odpowiedzi, więc zbyt niska wartość ucina tekst w połowie zdania. Przy dłuższych odpowiedziach używaj strumieniowania, bo zwykłe wywołanie z wysokim limitem potrafi trafić na limit czasu połączenia.

Adaptacyjne myślenie i parametr effort

Mechanizm ustalania, ile model ma się zastanawiać, zmienił się w tej generacji i to najczęstsze źródło błędów przy migracji starszego kodu.

Wcześniej podawało się budżet tokenów na myślenie. Obecnie model decyduje o tym sam, a Ty sterujesz ogólnym nakładem przez effort. Stary parametr zwraca błąd 400 na nowych modelach, podobnie jak temperature, top_p i top_k, których te modele nie przyjmują.

odpowiedz = client.messages.create(
    model="claude-opus-5",
    max_tokens=32000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": pytanie}],
)

Poziomy nakładu to low, medium, high, xhigh i max. Domyślny jest high. Do kodowania i zadań agentowych sprawdza się xhigh, do pracy rutynowej low albo medium, które w tej generacji wypadają zaskakująco dobrze i tną koszt oraz czas odpowiedzi.

Kolejność strojenia, która oszczędza pieniądze: najpierw zejdź z nakładem, potem dopiero rozważaj tańszy model. Sonnet przy wysokim nakładzie bywa lepszym wyborem niż Opus przy niskim, a różnicę widać dopiero na własnym zestawie testowym.

Prompt caching, czyli jak nie płacić dwa razy

To najskuteczniejszy mechanizm obniżania rachunku i zarazem najczęściej pomijany. Powtarzalny fragment promptu, na przykład instrukcja systemowa, dokumentacja produktu albo regulamin, można zbuforować i płacić za niego ułamek stawki.

client.messages.create(
    model="claude-opus-5",
    max_tokens=8000,
    system=[{
        "type": "text",
        "text": DUZA_INSTRUKCJA,
        "cache_control": {"type": "ephemeral"},
    }],
    messages=[{"role": "user", "content": pytanie}],
)

Odczyt z bufora kosztuje około jednej dziesiątej ceny wejścia. Zapis kosztuje 1,25 stawki przy buforze pięciominutowym i dwukrotność przy godzinnym. Przy wersji pięciominutowej opłaca się już od drugiego wywołania, przy godzinnej od trzeciego.

Kluczowa zasada brzmi: buforowanie działa na prefiksie. Zmiana jednego bajtu w dowolnym miejscu przed punktem buforowania unieważnia wszystko po nim. Dlatego data w instrukcji systemowej, identyfikator sesji wstawiony na początku albo lista narzędzi budowana w losowej kolejności potrafią zniweczyć cały mechanizm bez żadnego komunikatu.

Sprawdzisz to jedną liczbą. Pole usage.cache_read_input_tokens w odpowiedzi pokazuje, ile tokenów przyszło z bufora. Jeśli przy powtarzanych zapytaniach wynosi zero, coś unieważnia prefiks.

Batch API i pozostałe sposoby cięcia kosztów

Zadania, które nie muszą wrócić natychmiast, wysyłasz partią i płacisz połowę stawki.

partia = client.messages.batches.create(requests=[
    {"custom_id": f"zgloszenie-{i}", "params": {
        "model": "claude-haiku-4-5",
        "max_tokens": 512,
        "messages": [{"role": "user", "content": tresc}],
    }}
    for i, tresc in enumerate(zgloszenia)
])

Jedna partia mieści do stu tysięcy żądań, wyniki zwykle są gotowe w godzinę, najpóźniej w dobę, i pozostają dostępne przez dwadzieścia dziewięć dni. Wyniki wracają w dowolnej kolejności, więc dopasowuj je po custom_id, nigdy po pozycji na liście.

Trzeci czynnik to długość odpowiedzi. Wyjście kosztuje pięciokrotnie więcej niż wejście, więc instrukcja ograniczająca formę odpowiedzi obniża rachunek skuteczniej niż skracanie promptu. Prośba o pięć punktów zamiast eseju to zwykle różnica rzędu wielokrotności.

Warto też policzyć koszt jednego przebiegu, zanim proces ruszy na stałe. Weź dziesięć realnych przypadków, zsumuj tokeny wejścia i wyjścia z pola usage w odpowiedzi, pomnóż przez stawkę i przez spodziewany dzienny wolumen. Ta jedna liczba mówi więcej niż jakikolwiek kalkulator, bo uwzględnia Twoje prompty, a nie uśrednioną rozmowę.

Czwarty to dobór modelu do kroku, a nie do całego procesu. Klasyfikacja zgłoszenia idzie na Haiku, odpowiedź dla klienta na Sonnet, a trudna analiza na Opus. Jeden model do wszystkiego prawie zawsze oznacza przepłacanie w jednym miejscu i niedowożenie w drugim.

Narzędzia i odpowiedzi w ustalonej strukturze

Do integracji z kodem potrzebujesz przewidywalnego kształtu odpowiedzi. Schemat wymusza go po stronie modelu, bez parsowania wyrażeniami regularnymi.

wynik = client.messages.create(
    model="claude-haiku-4-5",
    max_tokens=1024,
    output_config={"format": {"type": "json_schema", "schema": SCHEMAT_ZGLOSZENIA}},
    messages=[{"role": "user", "content": f"Sklasyfikuj: {tresc}"}],
)

Wywoływanie narzędzi działa podobnie: opisujesz funkcje, model wskazuje, którą wywołać i z jakimi argumentami, a Ty wykonujesz ją po swojej stronie i oddajesz wynik. Przy dłuższych przepływach sensownie jest spiąć to LangChainem, który ujednolica interfejs między dostawcami.

Przy narzędziach po Twojej stronie największy wpływ na trafność ma opis. Model widzi wyłącznie nazwę, opis i schemat argumentów, więc zdanie mówiące wprost, kiedy narzędzie wywołać, działa lepiej niż samo stwierdzenie, co ono robi. Opis w rodzaju „Wywołaj, gdy użytkownik pyta o aktualny status zamówienia po numerze" podnosi trafność bardziej niż jakakolwiek zmiana promptu systemowego.

Osobną warstwą są narzędzia po stronie serwera: wyszukiwanie w sieci, pobieranie stron i wykonywanie kodu w piaskownicy. Deklarujesz je w liście narzędzi, a wykonują się bez Twojego udziału, co skraca kod, ale przenosi część kontroli na dostawcę.

Długi kontekst i kiedy naprawdę go użyć

Milion tokenów kusi, żeby wrzucać całą dokumentację do promptu zamiast budować wyszukiwanie. Czasem to właściwa decyzja, czasem najdroższy możliwy sposób odpowiedzenia na pytanie.

Opłaca się przy analizie jednorazowej: przeczytanie umowy na trzysta stron, porównanie dwóch wersji specyfikacji, przejrzenie zrzutu logów z awarii. Robisz to raz, koszt jest jednorazowy, a jakość wyższa niż przy wyszukiwaniu fragmentów, bo model widzi całość i wychwytuje sprzeczności między odległymi miejscami.

Nie opłaca się w aplikacji odpowiadającej na pytania użytkowników. Sto tysięcy tokenów kontekstu przy każdym pytaniu, przy tysiącu pytań dziennie, daje rachunek, przy którym baza wektorowa wychodzi wielokrotnie taniej. Dochodzi do tego opóźnienie, bo model musi przetworzyć całe wejście, zanim zacznie odpowiadać.

Jest jeszcze trzeci wariant, najczęściej pomijany: długi kontekst plus buforowanie. Jeśli ten sam duży dokument wraca przy wielu pytaniach, zbuforowanie go sprowadza koszt kolejnych wywołań do dziesiątej części. Przy stałym zbiorze dokumentów i kilkuset pytaniach dziennie ten układ bywa prostszy i tańszy niż utrzymywanie osobnej bazy wektorowej.

Przy bardzo długim wejściu warto pamiętać o rozmieszczeniu treści. Pytanie umieszczaj na końcu, a najważniejsze fragmenty na początku albo na końcu, nie w środku.

Claude kontra alternatywy

Praktyczna rada: nie wiąż logiki biznesowej z jednym dostawcą. Cienka warstwa z jednym interfejsem wywołań pozwala porównać modele na własnych danych, a to jedyny miarodajny test. Publiczne zestawienia mierzą zadania, które rzadko przypominają Twoje.

Typowe błędy

Pierwszy to przenoszenie starego kodu bez zmian. Parametry temperature, top_p, top_k oraz budżet tokenów na myślenie zwracają błąd 400 na nowych modelach. Usuń je i steruj zachowaniem przez instrukcję oraz effort.

Drugi to wypełnianie początku odpowiedzi po stronie asystenta. Ta technika przestała działać i zwraca błąd. Zastąp ją schematem odpowiedzi albo instrukcją w prompcie systemowym.

Trzeci to zbyt niski max_tokens. Limit obejmuje myślenie razem z odpowiedzią, więc przy włączonym myśleniu wartość dobrana pod samą odpowiedź ucina tekst.

Czwarty to brak obsługi pola stop_reason. Odpowiedź może zakończyć się z innego powodu niż normalne zamknięcie, na przykład przez limit tokenów albo odmowę, a kod czytający content[0] bez sprawdzenia wywala się na pustej liście.

Piąty to trzymanie klucza po stronie przeglądarki. Wywołanie z komponentu klienckiego ujawnia go każdemu, kto otworzy narzędzia deweloperskie, a rachunek obciąża Ciebie. Wszystkie wywołania kieruj z serwera, a jeśli aplikacja ma być interaktywna, strumieniuj odpowiedź przez własną trasę API.

Szósty to ignorowanie ponawiania. Biblioteki same ponawiają błędy 429 i 5xx, ale przy dużym ruchu warto dołożyć własne opóźnienie narastające i limit prób.

FAQ

Który model Claude wybrać na start?

Sonnet 5. Pokrywa większość zadań produkcyjnych przy trzykrotnie niższej cenie wejścia niż Opus, a przejście na mocniejszy model to zmiana jednego łańcucha znaków. Do klasyfikacji i przetwarzania masowego zejdź na Haiku 4.5.

Ile realnie kosztuje wywołanie?

Zależy od długości promptu i odpowiedzi. Rozmowa z instrukcją systemową na 2 tysiące tokenów i odpowiedzią na 500 tokenów kosztuje na Sonnecie około jednego centa. Przy tysiącu takich wywołań dziennie rachunek miesięczny idzie w setki dolarów, a buforowanie promptu i tryb wsadowy potrafią go zbić kilkukrotnie.

Czy Claude czyta obrazy i pliki PDF?

Tak, przyjmuje obrazy oraz dokumenty PDF w tym samym wywołaniu co tekst. Nie generuje natomiast obrazów ani nie przyjmuje wejścia wideo, więc do materiałów wideo potrzebny jest inny model.

Czym różni się Claude Code od API?

Claude Code to gotowe narzędzie pracujące na Twoim repozytorium z poziomu terminala albo edytora, rozliczane abonamentem. API to warstwa do budowania własnych produktów, rozliczana za tokeny. Zespoły często używają obu: Claude Code do pracy nad kodem, API w produkcie. Podobne zadania w edytorze obsługuje też Cursor.

Czy dane z API służą do trenowania modeli?

Nie, dane przesyłane przez API nie są używane do trenowania. Konfiguracja retencji zależy od ustawień organizacji, a część modeli wymaga minimalnego okresu przechowywania, więc przy wymogach zgodności sprawdź to przed wdrożeniem.

Aktualne modele i stawki opisuje dokumentacja Anthropic, a pełny cennik znajdziesz na stronie cennika.