Dlaczego tokeny wyjściowe Claude są droższe od wejściowych

Dlaczego tokeny wyjściowe kosztują więcej niż wejściowe

Tokeny wyjściowe kosztują pięciokrotnie więcej niż tokeny wejściowe w każdym modelu Claude dostępnym w obecnym katalogu. Przyczyną jest charakter obliczeń. Przetworzenie promptu to jeden przebieg przez model. Generowanie odpowiedzi to jeden przebieg na każdy token, przy czym każdy kolejny krok musi czekać na zakończenie poprzedniego.

Ten stosunek jest stały w każdym wierszu cennika, więc wybór modelu nie zmienia udziału kosztów wyjściowych w rachunku. Decyduje o tym charakter obciążenia. Krok agenta, który odczytuje 60,000 tokenów i odpowiada w 800, generuje znikome koszty wyjściowe. Zadanie polegające na tworzeniu szkicu, które odczytuje 2,000 tokenów i zapisuje 12,000, generuje znikome koszty wejściowe. Oba przypadki przeanalizowano poniżej w oparciu o opublikowane stawki Anthropic z sierpnia 2026.

Prefill jest wykonywany raz, dekodowanie raz na token

Serwer wnioskowania obsługuje żądanie w dwóch fazach o znacznie różniących się kosztach. Prefill odczytuje prompt. Dekodowanie zapisuje odpowiedź.

Prefill przetwarza cały prompt jednocześnie. Każdy token promptu trafia do sieci w tym samym przebiegu w przód (forward pass), więc operacje uwagi (attention) oraz feed-forward sprowadzają się do niewielkiej liczby dużych mnożeń macierzy, obejmujących tysiące tokenów naraz. Jeden odczyt wag modelu z pamięci obsługuje cały prompt. Jednostki macierzowe akceleratora pozostają obciążone, co oznacza, że prefill jest ograniczony mocą obliczeniową (compute-bound): limitem jest szybkość, z jaką układ potrafi wykonywać mnożenia.

Dekodowanie nie może działać w ten sposób, ponieważ token 2 zależy od tokena 1. Token, który model właśnie wygenerował, staje się częścią danych wejściowych dla kolejnego kroku, więc kroki te nie mogą być wykonywane równolegle. Każdy token wyjściowy wymaga własnego przebiegu w przód, a każdy z tych przebiegów odczytuje pełny zestaw wag modelu z pamięci o wysokiej przepustowości, aby wygenerować pojedynczy token. Sprawia to, że dekodowanie jest ograniczone przepustowością pamięci (memory-bound): limitem jest szybkość przesyłania wag, a nie szybkość ich mnożenia. Ten sam ruch wag, który podczas fazy prefill przetworzył cały prompt, w fazie dekodowania pozwala uzyskać tylko jeden token.

Systemy serwujące przeciwdziałają temu poprzez batching. Wiele żądań jest dekodowanych jednocześnie, dzięki czemu jeden odczyt wag generuje po jednym tokenie dla każdego żądania w partii. Dlatego dekodowanie jest w ogóle opłacalne. Ograniczeniem ponownie jest pamięć. Każde aktywne żądanie przechowuje KV cache (pamięć podręczną kluczy/wartości, czyli zapisany stan uwagi dla każdego dotychczasowego tokena); pamięć ta rośnie wraz z każdym wygenerowanym tokenem, a gdy wypełni akcelerator, partia nie może być dalej powiększana.

Nic z powyższych nie daje dokładnej liczby i nie należy traktować wartości 5x jako zmierzonego stosunku sprzętowego. Jest to cena ustalona przez Anthropic, wynikająca z tej asymetrii. To, co można sprawdzić samodzielnie, to kierunek zmian, co zajmuje około minuty.

Samodzielny pomiar opóźnień wejścia i wyjścia

Zainstaluj narzędzia na dowolnej maszynie z systemem Ubuntu:

sudo apt update && sudo apt install -y curl jq moreutils

Następnie prześlij krótki prompt wymagający długiej odpowiedzi i oznacz każdą linię czasem jej nadejścia.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
       "messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
  | ts -s '%.s'

ts -s poprzedza każdą linię liczbą sekund, które upłynęły od uruchomienia polecenia. Z tego wyjścia warto odczytać dwie wartości. Pierwsza linia content_block_delta to czas do uzyskania pierwszego tokena (Time To First Token), w którym zawarto cały proces prefill. Każda kolejna linia to pojedynczy krok dekodowania, a znaczniki czasu rosną aż do momentu nadejścia message_stop.

Teraz odwróć proporcje. Umieść długi dokument w prompcie i ogranicz odpowiedź do kilku tokenów.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "$(jq -n --rawfile doc ./long-document.txt \
       '{model:"claude-sonnet-5", max_tokens:16, stream:true,
         messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
  | ts -s '%.s'

Pierwsza delta trwa dłużej niż w przypadku krótkiego promptu, ponieważ proces prefill musi przetworzyć znacznie więcej tekstu. Po jej nadejściu odpowiedź kończy się niemal natychmiast, gdyż do zdekodowania pozostało tylko kilka tokenów. Dziesiątki tysięcy tokenów zostały przetworzone, a zegar niemal się nie przesunął. Kilkaset tokenów zostało wygenerowanych, a zegar pracował przez cały ten czas.

Każda odpowiedź niebędąca strumieniową kończy się liczbami, na podstawie których naliczane są opłaty.

{
  "usage": {
    "input_tokens": 41283,
    "output_tokens": 6,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

Rejestruj wszystkie cztery pola dla każdego żądania. output_tokens obejmuje rozszerzone myślenie, więc model, który myśli przed udzieleniem odpowiedzi, nalicza opłaty za ten proces według stawki za wyjście. Aby wycenić prompt przed jego wysłaniem, POST /v1/messages/count_tokens przyjmuje ten sam korpus żądania, zwraca {"input_tokens": N} bez uruchamiania modelu i jest bezpłatne. Nie jest to jedyna część API, która nie generuje kosztów, dlatego przed zaplanowaniem budżetu pierwszego projektu warto sprawdzić które części API Claude są zawsze bezpłatne.

Stawki Claude za milion tokenów według stanu na sierpień 2026

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug)",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (from 1 Sep)",
    "input_usd": 3,
    "output_usd": 15,
    "output_multiple": 5
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25,
    "output_multiple": 5
  },
  {
    "label": "Fable 5",
    "input_usd": 10,
    "output_usd": 50,
    "output_multiple": 5
  }
]

Ostatnia kolumna to wynik dzielenia kosztu wyjściowego przez wejściowy, co w każdym wierszu daje 5. Haiku 4.5 kosztuje 1 USD za wejście i 5 USD za wyjście. Opus 5 kosztuje 5 USD oraz 25 USD. Fable 5, najdroższy model, kosztuje 10 USD oraz 50 USD, a co oferują stawki Fable 5 warto przeczytać, zanim pominie się ten wiersz. Przejście na wyższy model mnoży obie strony przez ten sam współczynnik, co zmienia całkowity koszt, ale zachowuje proporcję między wejściem a wyjściem.

Sonnet 5 pojawia się dwukrotnie, ponieważ jego stawka promocyjna wygasa. Do 31 sierpnia 2026 r. kosztuje 2 USD za wejście i 10 USD za wyjście. Od 1 września 2026 r. obowiązuje stawka standardowa w wysokości 3 USD oraz 15 USD, co oznacza wzrost o 50% po obu stronach. Każdy poniższy przykład obliczeń wykorzystuje stawkę sierpniową.

Stawki ulegają zmianie, więc ta strona nie jest miejscem, w którym należy je sprawdzać. claude.com/pricing stanowi jedyne wiarygodne źródło informacji. Metoda obliczeń pozostaje aktualna nawet po zmianie cen.

Cennik pomija jedno istotne zastrzeżenie. Dokumentacja Anthropic wskazuje, że Claude 4.7 i nowsze modele korzystają z nowszego tokenizera, który generuje o około 30% więcej tokenów dla tego samego tekstu niż tokenizer w Sonnet 4.6 i wcześniejszych wersjach. Porównywanie modeli wyłącznie na podstawie ceny za milion tokenów faworyzuje nowsze jednostki, ponieważ ten sam dokument zajmuje w nich więcej tokenów. Należy porównywać koszt wykonania gotowego zadania i przeliczać rzeczywiste prompty dla modelu, który faktycznie ma zostać użyty. ile tekstu mieści się w milionie tokenów Claude wyjaśnia, jak ta objętość wygląda w praktyce.

Kiedy koszt wyjściowy zaczyna dominować w rachunku?

Przy cenie wyjścia wynoszącej 5 krotność ceny wejścia, punkt rentowności łatwo obliczyć w pamięci. Oznaczmy tokeny wejściowe jako I, a wyjściowe jako O. Koszt wejścia to I. Koszt wyjścia to 5 razy O. Koszt wyjścia przekracza połowę wydatków, gdy 5 razy O jest większe niż I, co odpowiada stosunkowi 5 tokenów wejściowych na 1 wyjściowy.

Zatem jeśli prompt jest ponad pięciokrotnie dłuższy niż odpowiedź, to wejście stanowi większą pozycję kosztową. Poniżej tej wartości dominuje wyjście.

[
  {
    "label": "100:1",
    "input_share_pct": 95.2,
    "output_share_pct": 4.8
  },
  {
    "label": "75:1",
    "input_share_pct": 93.75,
    "output_share_pct": 6.25
  },
  {
    "label": "20:1",
    "input_share_pct": 80,
    "output_share_pct": 20
  },
  {
    "label": "10:1",
    "input_share_pct": 66.7,
    "output_share_pct": 33.3
  },
  {
    "label": "5:1",
    "input_share_pct": 50,
    "output_share_pct": 50
  },
  {
    "label": "1:1",
    "input_share_pct": 16.7,
    "output_share_pct": 83.3
  },
  {
    "label": "1:6",
    "input_share_pct": 3.2,
    "output_share_pct": 96.8
  }
]

Przy stosunku 100 do 1, wyjście stanowi 4.8% wydatków i tylko optymalizacja promptu przynosi wymierne korzyści. Przy stosunku 5 do 1 obie strony są równe. Przy stosunku 1 do 6, wyjście stanowi 96.8% kosztów, a prompt jest błędem zaokrąglenia. Większość osób błędnie szacuje własny stosunek, dlatego przed przystąpieniem do jakiejkolwiek optymalizacji należy pobrać dane z logów.

Obciążenie agenta: długi kontekst wejściowy, krótka odpowiedź

Rozważmy jeden krok agenta wyszukującego: 60,000 tokenów wejściowych z pobranych dokumentów i historii konwersacji oraz odpowiedź o długości 800 tokenów. Daje to stosunek 75 do 1, co jest typowe dla każdego procesu, który najpierw czyta, a potem pisze.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.12,
    "output_cost": 0.008,
    "total_cost": 0.128
  },
  {
    "label": "Opus 5",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "Fable 5",
    "input_cost": 0.6,
    "output_cost": 0.04,
    "total_cost": 0.64
  }
]

Dane wyjściowe stanowią 6.25% kosztu tego wywołania w każdym modelu, ponieważ stosunek ten jest stały w całym cenniku. Wywołanie kosztuje $0.32 w modelu Opus 5, $0.128 w modelu Sonnet 5 według stawek sierpniowych oraz $0.064 w modelu Haiku 4.5. Dwieście takich kroków dziennie w modelu Opus 5 kosztuje 64 USD dziennie.

Dźwignia optymalizacji staje się oczywista po przeanalizowaniu podziału kosztów. Skrócenie odpowiedzi z 800 do 400 tokenów pozwala zaoszczędzić około 3% kosztu wywołania. Usunięcie 20,000 tokenów nieaktualnego kontekstu z promptu pozwala zaoszczędzić około jednej trzeciej kosztu. Ograniczanie długości danych wyjściowych w agencie intensywnie korzystającym z odczytu jest niemal bezcelowe. gdzie faktycznie trafiają tokeny agenta programistycznego zawiera szczegółowe zestawienie tego, co w pierwszej kolejności wypełnia taki prompt.

Obciążenie generowaniem: krótki prompt, długi szkic

Teraz odwróćmy proporcje. Krótki opis o długości 2000 tokenów, szkic o długości 12 000 tokenów, stosunek 1 do 6.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.002,
    "output_cost": 0.06,
    "total_cost": 0.062,
    "batch_total_cost": 0.031
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.004,
    "output_cost": 0.12,
    "total_cost": 0.124,
    "batch_total_cost": 0.062
  },
  {
    "label": "Opus 5",
    "input_cost": 0.01,
    "output_cost": 0.3,
    "total_cost": 0.31,
    "batch_total_cost": 0.155
  },
  {
    "label": "Fable 5",
    "input_cost": 0.02,
    "output_cost": 0.6,
    "total_cost": 0.62,
    "batch_total_cost": 0.31
  }
]

Wynik stanowi 96.8% tego rachunku. Opus 5 kosztuje $0.31 za szkic w porównaniu do $0.062 w przypadku Haiku 4.5. Ta pięciokrotna różnica wynika niemal w całości z kosztów generowania danych wyjściowych, czyli dokładnie z tego obszaru, w którym tańszy model przynosi największe oszczędności.

Ostatnia kolumna przedstawia to samo zadanie wykonane przez Batch API, co pozwala obniżyć koszty wejścia i wyjścia o 50%. Koszt Opus 5 spada do $0.155 za szkic. Batch zwraca wyniki w ciągu 24 godzin zamiast natychmiast, więc sprawdza się przy generowaniu nocnych raportów i masowej klasyfikacji. Nie nadaje się natomiast do zadań, na których wynik użytkownik musi czekać w czasie rzeczywistym.

Routing modeli opłaca się tutaj w sposób, który nie występuje na etapie działania agenta. Jeśli rozbudowana część zadania ma charakter mechaniczny, polega na przeformatowaniu tekstu lub rozwinięciu zatwierdzonego wcześniej konspektu, tańszy model wygeneruje te tokeny za jedną piątą ceny. wybór między Opus, Sonnet i Haiku omawia, gdzie w praktyce przebiega granica jakości.

Buforowanie obniża koszty wejścia, i tylko wejścia

Buforowanie promptów przechowuje prefiks promptu na serwerze i nalicza ułamek stawki wejściowej za jego ponowne odczytanie. Według stanu na sierpień 2026 mnożniki wynoszą 1,25x podstawowej stawki wejściowej za zapis bufora 5-minutowego, 2x za zapis bufora 1-godzinnego oraz 0,1x za odczyt trafienia.

Dane wyjściowe nie podlegają tej zasadzie. Nie istnieje buforowanie danych wyjściowych. Każdy token wygenerowany przez model jest rozliczany według pełnej stawki wyjściowej, za każdym razem, niezależnie od tego, jaka część promptu została odczytana z bufora.

Rozważmy ten sam krok agenta w modelu Opus 5, gdzie 55 000 z 60 000 tokenów wejściowych pochodzi z aktywnego bufora.

[
  {
    "label": "No cache",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "55k prefix cache read",
    "input_cost": 0.0525,
    "output_cost": 0.02,
    "total_cost": 0.0725
  }
]

Koszt wywołania spada z $0.32 do $0.0725. Koszt wyjścia pozostaje bez zmian: $0.02 przed, $0.02 po. Buforowanie obniża rachunek i zmienia jego strukturę. Koszt wyjścia stanowił 6.25% tego wywołania. Teraz stanowi ponad jedną czwartą, co zmienia priorytety optymalizacji.

Pierwsze wywołanie pokrywa koszt zapisu. Zapis w buforze 5-minutowym kosztuje 1,25x stawki podstawowej, więc zwraca się po jednym trafieniu. Zapis 1-godzinny kosztuje 2x, więc wymaga dwóch trafień. mnożniki zapisu i odczytu oraz moment, w którym buforowanie przestaje być opłacalne szczegółowo wyjaśnia te obliczenia.

Cztery dźwignie kontroli

1. Ustaw max_tokens na poziomie 95. percentyla długości wyjściowej, a nie na maksymalną wartość modelu.
2. Kieruj rozbudowane kroki do tańszego modelu.
3. Przetwarzaj wsadowo wszystko, na co nikt nie czeka w czasie rzeczywistym.
4. Usuń instrukcje, które niepotrzebnie wydłużają odpowiedzi.

max_tokens to twardy limit górny. Ustawienie go wysoko samo w sobie nic nie kosztuje, ponieważ opłaty naliczane są za wygenerowane tokeny, a nie za wysokość limitu. Hojny limit zapobiega przerwaniu odpowiedzi w przypadku błędu. Wyodrębnij rozkład output_tokens ze swoich logów, ustaw limit nieco powyżej 95. percentyla i obsługuj stop_reason: "max_tokens" w kodzie poprzez kontynuację odpowiedzi lub ponowienie zapytania. Wykryte ucięcie odpowiedzi kosztuje mniej niż 4000 tokenów zbędnego tekstu, za który płacisz, a który i tak odrzucasz. Rozszerzone myślenie modelu również trafia do output_tokens, więc budżet na nie ustalaj na podstawie tych samych danych.

Routing sprawdza się, gdy kosztowną częścią zadania jest objętość, a nie proces decyzyjny. Pozostaw decyzje silnemu modelowi, a generowanie tekstu zleć tańszemu rozwiązaniu. Najpierw przetestuj wersję z routingiem na własnym zbiorze ewaluacyjnym, ponieważ tani model, który wymaga dwóch prób, kosztuje więcej niż jedna próba modelu wysokiej klasy.

Przetwarzanie wsadowe to jedyna dźwignia obniżająca koszt wyjściowy. Oferuje 50% zniżki po obu stronach, wyniki w ciągu 24 godzin i dotyczy wszystkiego, co może być realizowane zgodnie z harmonogramem.

Ostatnia dźwignia jest najczęściej pomijana. Frazy typu „bądź dokładny” czy „wyjaśnij swoje rozumowanie” zwiększają długość wyjściową każdego wywołania. Zastąp je konkretnym formatem: „Odpowiedz w maksymalnie trzech zdaniach” lub „Zwróć tylko obiekt JSON, bez wstępu”. Prompt systemowy, który dodaje 300 tokenów do każdej odpowiedzi, kosztuje pięć razy więcej niż te same 300 tokeny umieszczone w treści zapytania. kontrolowanie kosztów działającego agenta omawia kwestię monitorowania, a porównanie opłacalności API względem stałej subskrypcji warto rozstrzygnąć przed poświęceniem tygodnia na optymalizację kosztów jednostkowych, które subskrypcja mogłaby pokryć. Dla pojedynczego programisty sprowadza się to głównie do pytania, czy subskrypcja Claude Pro za 20 USD miesięcznie wraz z jej limitami pokrywa pracę, którą w innym przypadku trzeba by rozliczać według zużycia. Jeśli limity te są osiągane w trakcie sesji, w pierwszej kolejności należy ustalić, które okno kontekstowe powoduje blokadę, ponieważ rozwiązaniem jest mniejszy model, lżejszy kontekst, dodatkowe kredyty lub przeniesienie zadania do rozliczanego API. Jeśli rozliczane API okaże się tańszym rozwiązaniem, przejście na niższy plan lub rezygnacja nie powoduje utraty opłaconego już miesiąca, więc zmiana nie generuje dodatkowych kosztów. Jeśli porównujesz plan Pro z ofertą ChatGPT, a nie z rozliczanym API, zestawienie obu drabin subskrypcyjnych pokaże, która opcja jest tańsza w pracy programistycznej. W przypadku zespołów należy pamiętać, że Claude Enterprise łączy opłatę za stanowisko z rozliczaniem tokenów według tych samych stawek API, więc każda dźwignia opisana na tej stronie ma zastosowanie do rozliczanej części rachunku.

FAQ

Dlaczego tokeny wyjściowe kosztują więcej niż wejściowe?

Ich generowanie wymaga znacznie dłuższego czasu pracy akceleratora na każdy token. Prompt jest przetwarzany w jednym przebiegu w przód dla całej swojej treści, więc pojedynczy odczyt wag modelu obejmuje tysiące tokenów, a sprzęt jest ograniczony przepustowością mnożenia. Odpowiedź generowana jest token po tokenie, a każdy z nich wymaga własnego przebiegu w przód, który ponownie odczytuje pełne wagi modelu, przez co sprzęt jest ograniczony przepustowością pamięci. Anthropic wycenia wyjście na pięciokrotność ceny wejścia w całym obecnym katalogu, od Haiku 4.5 aż po Fable 5.

Czy prompt caching obniża koszt tokenów wyjściowych?

Nie. Prompt caching dotyczy wyłącznie wejścia. Według stanu na sierpień 2026 odczyt z pamięci podręcznej kosztuje 0.1x stawki podstawowej wejścia, a zapis do pamięci podręcznej kosztuje 1.25x dla czasu trwania 5 minut lub 2x dla czasu trwania 1 godziny. Wyjście jest rozliczane według pełnej stawki przy każdym wywołaniu, niezależnie od operacji w pamięci podręcznej. Dlatego caching zmienia strukturę rachunku, a nie tylko jego wysokość: gdy koszt strony wejściowej maleje, to wyjście staje się głównym obszarem do optymalizacji kosztów.

Czy wysoka wartość max_tokens generuje koszty, jeśli odpowiedź jest krótka?

Nie. Rozliczenie następuje za tokeny faktycznie wygenerowane przez model, więc max_tokens jest limitem górnym, a nie rezerwacją. Wartość ta pozostaje istotna, ponieważ stanowi jedyne twarde ograniczenie dla odpowiedzi, która wymknęła się spod kontroli. Należy ustawić ją nieco powyżej 95. percentyla zaobserwowanej wartości output_tokens, a następnie obsługiwać stop_reason: "max_tokens" w kodzie, zamiast wysyłać cicho uciętą odpowiedź.

Jak obliczyć własny stosunek tokenów wejściowych do wyjściowych?

Należy logować input_tokens, output_tokens, cache_read_input_tokens oraz cache_creation_input_tokens z obiektu usage każdej odpowiedzi, a następnie podzielić sumy z całego tygodnia. Przy stosunku powyżej 5 tokenów wejściowych na 1 wyjściowy, główne koszty generuje prompt, więc należy użyć cache dla jego stałej części i skrócić resztę. Poniżej tej wartości główne koszty generuje odpowiedź, więc należy ograniczyć jej długość i przenieść etapy generujące najwięcej treści do tańszego modelu lub Batch API.