Claude Output Tokens: Bakit 5x ang Gastos sa Input

Bakit mas mahal ang output tokens kaysa input tokens

Ang output tokens ay nagkakahalaga ng limang beses ng input tokens sa bawat Claude model sa kasalukuyang catalogue. Ang dahilan ay nasa paraan ng computation. Isang pass lang sa model ang kailangan para basahin ang prompt. Sa pagsulat ng reply, isang pass ang kailangan para sa bawat token, at kailangang hintayin ng bawat pass ang nauna rito.

Pareho ang ratio na ito sa bawat row ng price list, kaya hindi binabago ng model na pipiliin mo kung gaano kalaki sa bill mo ang napupunta sa output. Ang workload shape ang nagtatakda nito. Ang agent step na nagbabasa ng 60,000 tokens at sumasagot gamit ang 800 ay halos walang gastos sa output. Ang drafting job na nagbabasa ng 2,000 tokens at nagsusulat ng 12,000 ay halos walang gastos sa input. Ipinapakita sa ibaba ang dalawang sitwasyong ito gamit ang mga rate ng Anthropic na inilathala noong August 2026.

Ang prefill ay isang beses lang tumatakbo, samantalang ang decoding ay isang beses para sa bawat token

Pinoproseso ng inference server ang isang request sa dalawang phase na magkaiba ang gastos. Binabasa ng prefill ang prompt. Isinusulat naman ng decoding ang reply.

Pinoproseso ng prefill ang buong prompt nang sabay-sabay. Pumapasok ang bawat prompt token sa network sa iisang forward pass, kaya nagiging maliit na bilang ng malalaking matrix multiplication ang attention at feed-forward work na sumasaklaw sa libo-libong token bawat pagkakataon. Isang pagbasa sa model weights mula sa memory ang sapat para sa buong prompt. Patuloy na abala ang matrix units ng accelerator, kaya compute-bound ang prefill: ang limitasyon ay kung gaano kabilis makapag-multiply ang chip.

Hindi maaaring gumana nang ganito ang decoding dahil nakadepende ang token 2 sa token 1. Nagiging bahagi ng input sa susunod na step ang token na kakagawa lang ng model, kaya hindi maaaring patakbuhin nang sabay-sabay ang mga step. May sariling forward pass ang bawat output token, at binabasa ng bawat pass ang buong set ng model weights mula sa high-bandwidth memory upang makagawa ng isang token. Dahil dito, memory-bound ang decoding: ang limitasyon ay kung gaano kabilis maililipat ang weights, hindi kung gaano kabilis ma-multiply ang mga ito. Ang parehong weight traffic na nakapagproseso ng buong prompt sa prefill ay isang token lamang ang nagagawa sa decoding.

Lumalaban dito ang mga serving system sa pamamagitan ng batching. Sabay-sabay na nagde-decode ang maraming request, kaya sa isang pagbasa ng weights ay nakakagawa ng isang token para sa bawat request sa batch. Ito ang dahilan kung bakit praktikal pa rin ang decoding. Memory pa rin ang nagtatakda ng ceiling. May KV cache (key/value cache, ang nakaimbak na attention state para sa bawat token hanggang sa kasalukuyan) ang bawat request na nasa flight. Lumalaki ang cache sa bawat nabuong token, at kapag napuno nito ang accelerator, hindi na maaaring palakihin pa ang batch.

Wala sa mga ito ang nagbibigay ng eksaktong numero, at hindi mo dapat ituring ang 5x bilang nasukat na hardware ratio. Presyo ito na itinakda ng Anthropic at ibinatay sa asymmetry na ito. Ang maaari mong suriin mismo ay ang direksiyon ng pagkakaiba, at matatapos ito sa loob ng humigit-kumulang isang minuto.

Sukatin mismo ang input at output gap

I-install ang mga tool sa anumang Ubuntu box:

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

Ngayon, mag-stream ng maikling prompt na humihingi ng mahabang sagot, at lagyan ng oras ng pagdating ang bawat linya.

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'

Nilalagyan ng ts -s ang bawat linya ng lumipas na segundo mula nang simulan ang command. Dalawang bagay ang mahalagang basahin mula sa output na iyon. Ang unang linya na may content_block_delta ang oras bago dumating ang unang token, at doon nangyari ang buong prefill. Ang bawat kasunod na linya ay isang maliit na hakbang ng decoding, at patuloy na tumataas ang mga timestamp hanggang dumating ang message_stop.

Baligtarin naman ang hugis. Maglagay ng mahabang dokumento sa prompt at limitahan ang sagot sa ilang token.

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'

Mas matagal ang unang delta kaysa noong maikli ang prompt dahil mas marami pang text ang kailangang basahin sa prefill. Pagdating nito, halos agad natatapos ang response dahil kaunti lamang ang natitirang ide-decode na token. Sampu-sampung libong token ang pumasok, pero bahagya lamang gumalaw ang orasan. Ilang daang token ang lumabas, pero buong oras na tumakbo ang orasan.

Nagtatapos ang bawat non-streaming response sa mga numerong ginagamit sa billing.

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

I-log ang lahat ng apat na field sa bawat request. Kasama sa output_tokens ang extended thinking, kaya kung nag-iisip muna ang model bago sumagot, sisingilin ang thinking na iyon sa output rate. Para malaman ang presyo ng prompt bago ito ipadala, tinatanggap ng POST /v1/messages/count_tokens ang parehong request body, ibinabalik ang {"input_tokens": N} nang hindi pinapatakbo ang model, at libre ito. Hindi lang ito ang bahagi ng API na walang bayad, kaya sulit suriin kung aling bahagi ng Claude API ang hindi kailanman sinisingil sa iyo bago magtakda ng budget para sa unang proyekto.

Magkano ang singil ni Claude sa bawat isang milyong token noong Agosto 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
  }
]

Ang huling column ay output na hinati sa input, at 5 ang nakalagay sa bawat row. Naniningil ang Haiku 4.5 ng $1 para sa input at $5 para sa output. Naniningil ang Opus 5 ng $5 at $25. Ang Fable 5, na pinakamahal, ay naniningil ng $10 at $50, at sulit basahin ang kung ano ang makukuha mo sa mga rate ng Fable 5 bago mo isantabi ang unang row na iyon. Habang umaakyat sa range, parehong minumultiply ang input at output ng iisang factor. Kaya nagbabago ang kabuuang halaga, pero nananatiling pareho ang hatian ng input at output.

Dalawang beses lumilitaw ang Sonnet 5 dahil nag-e-expire ang introductory rate nito. Hanggang 31 Agosto 2026, naniningil ito ng $2 at $10. Mula 1 Setyembre 2026, ang standard rate na $3 at $15 ang iiral. 50% itong mas mataas sa magkabilang panig. Gamit ng lahat ng worked example sa ibaba ang August rate.

Nagbabago ang mga rate, at hindi ang page na ito ang dapat mong gawing sanggunian para tingnan ang mga ito. Ang claude.com/pricing ang source of truth. Ang hindi nagbabago kapag nagbago ang presyo ay ang paraan ng pagkukuwenta.

May isang caveat na hindi ipinapakita ng price list. Ayon sa documentation ng Anthropic, gumagamit ang Claude 4.7 at mga mas bagong model ng bagong tokenizer. Nagpo-produce ito ng humigit-kumulang 30% mas maraming token para sa parehong text kaysa sa tokenizer ng Sonnet 4.6 at mga mas naunang bersyon. Kapag presyo kada isang milyong token lang ang ikinumpara, mas maganda ang lalabas na halaga ng mas bagong model. Mas marami kasing token ang parehong document dito. Ikumpara ang cost sa bawat natapos na task, at bilangin ang aktuwal mong prompt laban sa model na talagang gagamitin mo. Pareho ring problema ang umiiral sa pagitan ng mga provider, dahil mas malaki pa sa ganoon ang pagkakaiba ng kanilang mga tokenizer. Kaya mas maraming impormasyon ang makukuha sa pagkenta ng isang aktuwal na trabaho sa Claude at ChatGPT kaysa sa pagtatabi ng dalawang rate card. Ipinapaliwanag ng kung ano ang halaga ng isang milyong Claude token sa aktuwal na text kung ano ang hitsura ng volume na iyon sa praktikal na paggamit.

Kailan nagsisimulang mangibabaw ang output sa bill mo?

Kapag ang presyo ng output ay 5 beses ng input, madaling kalkulahin ang break-even. Tawagin nating I ang input tokens at O ang output tokens. Ang halaga ng input ay I. Ang halaga ng output ay 5 beses ng O. Lalampas sa kalahati ng kabuuang gastos ang output kapag mas malaki ang 5 beses ng O kaysa I. Katumbas ito ng ratio na 5 input sa 1 output.

Kaya kung mahigit limang beses na mas mahaba ang prompt kaysa sa reply, input ang mas malaking bahagi ng gastos. Kapag mas mababa rito, output naman.

[
  {
    "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
  }
]

Sa ratio na 100 sa 1, 4.8% ng gastos ang output, kaya ang pagbabawas sa prompt ang tanging sulit na gawin. Sa ratio na 5 sa 1, magkapantay ang dalawang panig. Sa ratio na 1 sa 6, 96.8% ang output at rounding error na lang ang prompt. Kadalasan, mali ang tantiya ng mga tao sa sarili nilang ratio, kaya kunin muna ito sa logs bago mag-optimize.

Isang agent workload: mahaba ang context, maikli ang sagot

Magsagawa ng isang hakbang ng retrieval agent: 60,000 input token mula sa mga na-retrieve na dokumento at conversation history, at isang sagot na 800 token. Ratio itong 75 sa 1, na normal para sa anumang sistemang nagbabasa muna bago sumulat.

[
  {
    "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
  }
]

Ang output ay 6.25% ng call na iyon sa bawat model, dahil fixed ang ratio sa buong price list. Ang call ay nagkakahalaga ng $0.32 sa Opus 5, $0.128 sa Sonnet 5 batay sa rate noong August, at $0.064 sa Haiku 4.5. Ang 200 ganoong hakbang bawat araw sa Opus 5 ay nagkakahalaga ng $64 bawat araw.

Malinaw ang pinakamabisang lever kapag nakita mo ang paghahati. Ang pagbawas sa sagot mula 800 token tungo sa 400 ay nakakatipid ng humigit-kumulang 3% ng call. Ang pag-aalis ng 20,000 token ng luma o hindi na kailangang context mula sa prompt ay nakakatipid ng humigit-kumulang isang-katlo ng gastos nito. Ang paghihigpit sa haba ng output ng read-heavy agent ay halos walang naidudulot na pagtitipid. Ipinapakita ng kung saan talaga napupunta ang mga token ng coding agent kung ano ang pumupuno sa prompt na iyon.

Isang generation workload: maikling prompt, mahabang draft

Ngayon, baligtarin ang hugis. Isang 2,000-token na brief, isang 12,000-token na draft, at ratio na 1 sa 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
  }
]

Ang output ay 96.8% ng bill na ito. Ang Opus 5 ay nagkakahalaga ng $0.31 bawat draft, kumpara sa $0.062 gamit ang Haiku 4.5. Halos buong-buo mula sa output side ang limang-beses na agwat na ito. Dito rin pinakamalaki ang matitipid kapag mas murang model ang ginamit.

Ang huling column ay ang parehong workload gamit ang Batch API, na nagbabawas ng 50% sa input at output. Bumaba ang halaga ng Opus 5 sa $0.155 bawat draft. Ibinabalik ng Batch ang mga resulta sa loob ng 24 oras sa halip na agad, kaya angkop ito sa overnight report generation at bulk classification. Hindi ito angkop sa anumang gawain na hinihintay agad ng isang tao.

Malaki ang naitutulong ng model routing dito, hindi gaya sa agent step. Kung mekanikal ang verbose na bahagi ng gawain, gaya ng pagre-reformat ng text o pagpapalawak ng outline na naaprubahan mo na, nagagawa ng murang model ang mga token na iyon sa ikalimang bahagi ng presyo. Sinasaklaw ng pagpili sa pagitan ng Opus, Sonnet at Haiku kung saan talaga matatagpuan ang hangganan ng kalidad.

Ang caching ay nagpapababa lamang sa gastos ng input

Iniimbak ng prompt caching ang prefix ng prompt sa server at naniningil lamang ng bahagi ng input rate kapag muli itong binasa. Noong August 2026, ang mga multiplier ay 1.25x ng base input rate para magsulat ng 5 minute cache, 2x para magsulat ng 1 hour cache, at 0.1x para magbasa ng cache hit.

Hindi kasama sa alok na ito ang output. Walang cached output. Bawat token na isinusulat ng model ay sinisingil sa buong output rate sa bawat pagkakataon, gaano man karami sa prompt ang nagmula sa cache hit.

Gamitin ang parehong agent step sa Opus 5, kung saan 55,000 sa 60,000 input token ang nagmula sa warm cache.

[
  {
    "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
  }
]

Bumababa ang singil mula $0.32 tungo sa $0.0725. Hindi nagbabago ang output line: $0.02 bago, at $0.02 pagkatapos. Binabawasan ng caching ang bill at binabago ang komposisyon nito. 6.25% ng call na iyon ang output. Ngayon, higit na ito sa isang-kapat ng kabuuan, kaya nagbabago kung aling lever ang sulit gamitin sa susunod.

Ang unang call ang nagbabayad para sa write. Ang 5 minute cache write ay nagkakahalaga ng 1.25x ng base input, kaya nababawi nito ang gastos pagkatapos ng isang hit. Ang 1 hour write ay nagkakahalaga ng 2x, kaya kailangan nito ng dalawang hit. Ipinapakita sa mga multiplier para sa write at read, at kung kailan hindi na sulit ang caching ang kalkulasyong iyon.

Apat na lever na kontrolado mo

1. Itakda ang max_tokens batay sa iyong p95 output length, hindi sa maximum ng model.
2. I-route ang mahahabang hakbang sa mas murang model.
3. I-batch ang anumang hindi kailangang hintayin ng isang tao.
4. Burahin ang mga instruction na nagpapahaba ng mga reply.

Ang max_tokens ay hard ceiling. Walang dagdag na gastos ang mataas na setting nito, dahil sinisingil ka batay sa mga token na ginawa, hindi sa ceiling. Ang epekto ng malaking cap ay inaalis nito ang limitasyon sa reply kapag nagkamali ang proseso. Kunin ang output_tokens distribution mula sa iyong logs, itakda ang cap nang kaunti sa 95th percentile, at pangasiwaan ang stop_reason: "max_tokens" sa code sa pamamagitan ng pagpapatuloy ng response o pag-retry. Mas mura ang truncation na nade-detect mo kaysa sa 4,000-token na mahabang reply na binayaran mo ngunit itinatapon. Kasama rin sa output_tokens ang extended thinking, kaya itakda ang budget nito batay sa parehong ebidensiya.

Gumagana ang routing kapag volume, hindi judgement, ang pinakamahal na bahagi ng isang hakbang. Panatilihin ang malakas na model para sa decision, at ipagawa ang pagta-type sa mas murang model. Suriin muna ang routed version gamit ang sarili mong evaluation set, dahil mas mahal ang murang model na nangangailangan ng dalawang attempt kaysa sa isang mamahaling attempt.

Ang batching ang tanging lever na nagbibigay ng discount sa output. Qualified dito ang 50% discount sa magkabilang panig, mga resultang dumarating sa loob ng 24 na oras, at anumang nasa schedule.

Ang huling lever ang madalas nilalaktawan ng mga tao. Ang mga pariralang tulad ng "be thorough" at "explain your reasoning" ay nagtatakda ng output length sa bawat call na gagawin mo. Palitan ang mga ito ng eksaktong format na gusto mo: "Answer in at most three sentences", o "Return only the JSON object, with no preamble". Ang system prompt na nagdaragdag ng 300 token sa bawat reply ay nagkakahalaga ng limang beses ng halaga ng parehong 300 token sa prompt. Ang pagkontrol sa gastos ng isang agent na patuloy na tumatakbo ay tumatalakay sa monitoring, at mahalagang ayusin muna ang kung mas mura para sa iyong pattern ang API o flat subscription bago ka gumugol ng isang linggo sa pag-tune ng per-token spend na sana ay sakop ng subscription. Para sa isang developer, karaniwang nakasalalay ito sa kung sapat para sa trabaho ang $20 bawat buwan ng Claude Pro at ang mga usage limit na kasama nito na kung hindi ay sisingilin mo batay sa paggamit. Kung naaabot mo na ang mga limit na ito sa kalagitnaan ng session, unahin ang pag-alam kung aling window ang hinihintay mo, dahil mula roon, maaaring mas maliit na model, mas magaang context, dagdag na usage credits, o paglipat ng trabahong iyon sa metered API ang solusyon. Kung lumabas na mas mura ang metered API para sa trabahong iyon, ang pag-downgrade sa mas maliit na plan o pagkansela nito ay hindi magbabago sa natitirang buwan na nabayaran mo na, kaya wala kang gastos sa paglipat. Kung ang plan na ikinukumpara mo sa Pro ay ang ChatGPT plan at hindi ang metered API, ipinapakita ng magkatabing presyo ng dalawang subscription ladder kung alin ang mas mura para sa coding work. Kung para sa team at hindi sa isang developer ang tanong, tandaan na pinagsasama ng Claude Enterprise ang per-seat fee at mga token na sinisingil sa parehong API rates na ito ang mga bayaring iyon, kaya naaangkop pa rin ang bawat lever sa metered na bahagi ng bill.

FAQ

Bakit mas mahal ang output tokens kaysa input tokens?

Mas maraming oras ng accelerator ang kailangan para ma-generate ang mga ito sa bawat token. Pinoproseso ang prompt sa isang forward pass sa kabuuan nito, kaya isang pagbasa lang ng model weights ang sumasaklaw sa libo-libong token at ang hardware ay nalilimitahan ng multiply throughput. Ang reply ay ginagawa naman nang tig-iisang token, at bawat token ay nangangailangan ng sarili nitong forward pass na muling bumabasa sa buong model weights. Kaya memory bandwidth naman ang naglilimita sa hardware. Sinisingil ng Anthropic ang output nang limang beses sa input sa buong kasalukuyang catalogue, mula Haiku 4.5 hanggang Fable 5.

Pinapamura ba ng prompt caching ang output tokens?

Hindi. Input lamang ang saklaw ng prompt caching. Noong August 2026, ang cache read ay nagkakahalaga ng 0.1x ng base input rate, at ang cache write ay nagkakahalaga ng 1.25x para sa 5 minute duration o 2x para sa 1 hour duration. Sisingilin ang output sa buong rate sa bawat call, anuman ang ginawa ng cache. Kaya binabago ng caching ang anyo pati ang laki ng bill mo: kapag lumiit na nang malaki ang bahagi para sa input, ang output ang bahaging sulit bawasan.

Magkano ang magagastos ko kapag mataas ang max_tokens pero maikli ang reply?

Wala. Sisingilin ka batay sa mga token na aktuwal na ginawa ng model, kaya ang max_tokens ay ceiling lamang at hindi reservation. Mahalaga pa rin ito dahil ito ang tanging hard limit sa reply na maaaring lumampas sa inaasahang haba. Itakda ito nang kaunti sa taas ng 95th percentile ng naobserbahan mong output_tokens, at pangasiwaan ang stop_reason: "max_tokens" sa code sa halip na maglabas ng sagot na tahimik na naputol.

Paano ko malalaman ang sarili kong input-to-output token ratio?

I-log ang input_tokens, output_tokens, cache_read_input_tokens, at cache_creation_input_tokens mula sa usage object ng bawat response, pagkatapos ay hatiin ang kabuuan sa loob ng isang linggo. Kung lampas 5 input sa bawat 1 output, nasa prompt ang gastos mo. I-cache ang stable na bahagi at bawasan ang natitira. Kung mas mababa rito, nasa reply ang gastos mo. Limitahan ang haba nito at ilipat sa mas murang model o sa Batch API ang mga hakbang na bumubuo ng pinakamaraming output.