Input vs Output Tokens: Bakit Mas Mahal ang Output

Bakit mas mahal ang output tokens kaysa input tokens

Limang beses ang halaga ng output tokens kumpara sa input tokens sa bawat Claude model sa kasalukuyang catalogue. Ang dahilan ay ang anyo ng computation. Isang pass lang ng model ang kailangan sa pagbasa ng 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 nagbabago ang bahagi ng bill mo na napupunta sa output batay sa model na pipiliin mo. Ang workload shape ang nagtatakda nito. Ang isang agent step na nagbabasa ng 60,000 tokens at sumasagot gamit ang 800 tokens ay halos walang gastos sa output. Ang drafting job na nagbabasa ng 2,000 tokens at sumusulat ng 12,000 tokens ay halos walang gastos sa input. Ipinapakita sa ibaba ang pagkalkula para sa parehong sitwasyon gamit ang mga rate ng Anthropic na inilathala noong August 2026.

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

Pinoproseso ng inference server ang isang request sa 2 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 token ng prompt sa network sa iisang forward pass, kaya ang attention at feed-forward work ay nagiging maliit na bilang ng malalaking matrix multiplication na sumasaklaw sa libo-libong token sa bawat pagkakataon. Isang pagbasa sa model weights mula sa memory ang nagsisilbi sa buong prompt. Nanatiling 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 katatapos lang likhain ng model, kaya hindi maaaring tumakbo nang sabay-sabay ang mga step. May sariling forward pass ang bawat output token, at sa bawat pass, binabasa ang buong set ng model weights mula sa high-bandwidth memory upang makalikha ng isang token. Dahil dito, memory-bound ang decoding: ang limitasyon ay kung gaano kabilis maililipat ang weights, hindi kung gaano kabilis mai-multiply ang mga ito. Ang parehong weight traffic na nakapagproseso ng buong prompt sa prefill ay nakakalikha lamang ng isang token sa decoding.

Nilalabanan ito ng mga serving system sa pamamagitan ng batching. Sabay-sabay na nagde-decode ang maraming request, kaya sa isang pagbasa ng weights ay nakakalikha ng tig-isang token para sa bawat request sa batch. Ito ang dahilan kung bakit katanggap-tanggap pa rin ang gastos ng decoding. Memory pa rin ang limitasyon. May KV cache ang bawat request na kasalukuyang pinoproseso (key/value cache, ang nakaimbak na attention state para sa bawat token hanggang sa kasalukuyan). Lumalaki ang cache sa bawat nalilikhang token. Kapag napuno nito ang accelerator, hindi na maaaring palakihin pa ang batch.

Wala sa mga ito ang nagbibigay sa iyo ng eksaktong numero, at hindi mo dapat ituring ang 5x bilang aktuwal na hardware ratio na sinukat. Isa itong presyong itinakda ng Anthropic at ibinatay sa asymmetry na ito. Ang maaari mong suriin mismo ay ang direksiyon ng epekto, 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 ang bawat linyang dumating.

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 bilang ng mga segundong lumipas mula nang magsimula ang command. May dalawang bagay na dapat basahin mula sa output na ito. Ang unang linyang may content_block_delta ang oras ng pagdating ng unang token, at lahat ng prefill ay nangyari sa loob nito. Ang bawat kasunod na linya ay isang maliit na hakbang ng decoding, at patuloy na tumataas ang mga time stamp hanggang dumating ang message_stop.

Ngayon, baligtarin 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 token na kailangang i-decode. Sampu-sampung libong token ang pumasok, pero bahagya lamang umusad ang orasan. Ilang daang token ang lumabas, pero buong panahon itong tumakbo.

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 ito ang tanging bahagi ng API na walang bayad, at sulit suriin ang mga bahagi ng Claude API na hindi kailanman sinisingil sa iyo bago magtakda ng budget para sa unang proyekto.

Magkano ang singil ni Claude kada 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 nakalagay itong 5 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 nakukuha mo sa mga rate ng Fable 5 bago mo agad isantabi ang pinakamataas na row. Habang umaakyat sa range, parehong factor ang ipinaparami sa dalawang panig. Dahil dito, nagbabago ang kabuuang gastos pero nananatiling eksakto ang hati ng input at output.

Dalawang beses lumilitaw ang Sonnet 5 dahil nagtatapos ang introductory rate nito. Hanggang 31 August 2026, naniningil ito ng $2 at $10. Mula 1 September 2026, gagamitin ang standard rate na $3 at $15, na 50% na mas mataas sa dalawang panig. Ang lahat ng worked example sa ibaba ay gumagamit ng August rate.

Nagbabago ang mga rate, at hindi sa page na ito dapat tingnan ang pinakabagong halaga. Ang claude.com/pricing ang opisyal na source of truth. Ang hindi nagbabago kapag nagbago ang presyo ay ang pamamaraan.

May isang mahalagang limitasyon na hindi ipinapakita sa price list. Ayon sa documentation ng Anthropic, gumagamit ang Claude 4.7 at mga mas bagong model ng bagong tokenizer na gumagawa ng humigit-kumulang 30% mas maraming token para sa parehong text kumpara sa tokenizer ng Sonnet 4.6 at mga naunang version. Kung ihahambing ang dalawang model batay lamang sa presyo kada milyong token, magmumukhang mas paborable ang mas bagong model, dahil mas maraming token ang parehong document dito. Ihambing ang gastos kada natapos na task, at bilangin ang aktuwal mong prompt gamit ang model na talagang gagamitin mo. Ipinapaliwanag ng kung gaano karaming aktuwal na text ang katumbas ng isang milyong Claude token kung ano ang kinakatawan ng volume na iyon sa praktikal na paggamit.

Kailan nagsisimulang maging pinakamalaking bahagi ng bill ang output?

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

Kaya kung higit sa 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 makabuluhang dapat gawin. Sa ratio na 5 sa 1, magkapantay ang dalawang bahagi. Sa ratio na 1 sa 6, 96.8% ang output at rounding error na lamang ang prompt. Kadalasan, mali ang tantiya ng mga tao sa sarili nilang ratio, kaya kunin muna ito mula sa logs bago mag-optimize ng anuman.

Isang agent workload: mahaba ang context sa input, maikli ang sagot sa output

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

[
  {
    "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 gamit ang August rate, 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 hatian. Ang pagbawas sa sagot mula 800 token tungo sa 400 ay nakakatipid ng humigit-kumulang 3% ng call. Ang pagtanggal ng 20,000 token ng stale context mula sa prompt ay nakakatipid ng humigit-kumulang isang-katlo ng gastos nito. Ang paghihigpit sa haba ng output ng isang read-heavy agent ay halos walang napapakinabangan. Ipinapakita ng kung saan talaga napupunta ang mga token ng coding agent kung ano ang bumubuo sa prompt na iyon.

Isang workload para sa generation: 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 sa Haiku 4.5. Halos buong pagkakaiba na limang beses ay nagmumula sa output. Dito pinakamalaki ang natitipid kapag mas murang model ang ginamit.

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

Kapaki-pakinabang dito ang model routing sa paraang hindi nito napapakinabangan ang agent step. Kung mechanical ang verbose na bahagi ng trabaho, gaya ng pagre-reformat ng text o pagpapalawak ng outline na naaprubahan mo na, nalilikha ng mas 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.

Binabaan ng caching ang gastos sa input lamang

Iniimbak ng prompt caching ang prefix ng iyong prompt sa server at naniningil ng isang bahagi ng input rate kapag muli itong binasa. Simula Agosto 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 benepisyong iyon ang output. Walang naka-cache na output. Bawat token na isinusulat ng model ay sinisingil sa buong output rate sa bawat pagkakataon, gaano man karami sa prompt ang naibalik bilang cache hit.

Gamitin ang parehong agent step sa Opus 5, kung saan 55,000 sa 60,000 input token ang ibinigay mula 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 nito at $0.02 pagkatapos. Binabawasan ng caching ang bill at binabago ang komposisyon nito. 6.25% ng call na iyon ang output. Ngayon, mahigit isang-kapat na ito ng kabuuang singil, kaya nagbabago kung aling lever ang sulit gamitin sa susunod.

Ang unang call ang sumasagot sa write cost. 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 p95 na haba ng output, hindi sa maximum ng model.
2. I-route ang mahahabang step sa mas murang model.
3. I-batch ang anumang hindi kailangang hintayin ng user.
4. Tanggalin ang mga instruction na nagpapahaba ng mga reply.

max_tokens ang hard ceiling. Walang direktang gastos ang pagtatakda nito nang mataas dahil sinisingil ka batay sa mga token na nalilikha, hindi sa ceiling. Ang epekto ng mataas na cap ay inaalis nito ang limitasyon kapag pumalya ang isang reply. Kunin ang output_tokens distribution mula sa logs mo, itakda ang cap nang kaunti sa itaas ng 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 natukoy mo kaysa sa 4,000-token na mahabang reply na babayaran mo pero itatapon. 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 nagpapamahal sa isang step. 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 magastos ang murang model na nangangailangan ng dalawang attempt kaysa sa isang mamahaling attempt.

Ang batching ang tanging lever na nagbibigay ng discount sa output. May 50% discount sa dalawang panig, available ang results sa loob ng 24 oras, at kwalipikado ang anumang naka-schedule.

Ang huling lever ang madalas nilalaktawan. Ang mga pariralang gaya ng "maging masinsinan" at "ipaliwanag ang iyong reasoning" ay nagtatakda ng haba ng output sa bawat call na gagawin mo. Palitan ang mga ito ng eksaktong format na kailangan mo: "Sumagot sa hindi hihigit sa tatlong pangungusap", o "Ibalik lamang ang JSON object, nang walang preamble". Ang system prompt na nagdaragdag ng 300 token sa bawat reply ay limang beses na mas magastos kaysa sa parehong 300 token sa prompt. Saklaw ng pagkontrol sa gastos ng patuloy na tumatakbong agent ang bahagi ng monitoring, at makabubuting pagpasiyahan muna ang kung mas mura para sa pattern mo ang API o flat subscription bago ka gumugol ng isang linggo sa pag-tune ng per-token spend na sana ay saklaw na 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 limitasyong iyon sa kalagitnaan ng session, unahin ang pag-alam kung aling window ang hinihintay mo, dahil mula roon ay maaaring mas maliit na model, mas magaan na context, karagdagang usage credits, o paglilipat ng gawaing iyon sa metered API ang solusyon. Kung lumabas na mas mura para sa gawaing iyon ang metered API, hindi maaapektuhan ang buwan na nabayaran mo na kapag lumipat sa mas maliit na plan o nag-cancel nito, kaya wala kang babayaran sa paglipat. Kung ang plan na ikinukumpara mo sa Pro ay sa ChatGPT at hindi sa metered API, ipinapakita ng magkatabing presyo ng dalawang subscription ladder kung alin ang mas mura para sa coding work. Kung ang tanong na ito ay para sa team at hindi sa isang developer, tandaan na ang Claude Enterprise ay pinagsasama ang per-seat fee at mga token na sisingilin sa parehong API rate; kaya naaangkop pa rin ang bawat lever sa metered na bahagi ng bill na iyon.

FAQ

Bakit mas mahal ang output tokens kaysa input tokens?

Mas malaking accelerator time ang kailangan para ma-generate ang mga ito sa bawat token. Pinoproseso ang prompt sa isang forward pass sa buong input, 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 nang tig-iisang token, at bawat token ay nangangailangan ng sarili nitong forward pass na muling nagbabasa 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.

Mas 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. Sinisingil ang output sa buong rate sa bawat call, anuman ang naging epekto ng cache. Kaya binabago ng caching ang hugis ng bill mo pati ang laki nito: kapag lumiit na nang malaki ang input side, ang output ang bahaging sulit bawasan.

Magkakagastos ba ako kapag mataas ang max_tokens pero maikli ang reply?

Hindi. Sinisingil ka para 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 lang ang hard limit sa reply na maaaring lumampas nang walang katapusan. Itakda ito nang bahagya sa taas ng 95th percentile ng naobserbahan mong output_tokens, pagkatapos ay 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 mga total sa loob ng isang linggo. Kapag lampas 5 input sa 1 output, nasa prompt ang malaking bahagi ng gastos mo. I-cache ang stable na bahagi at paikliin ang natitira. Kapag mas mababa roon, nasa reply ang malaking bahagi ng gastos mo. Limitahan ang haba nito at ilipat sa mas murang model o sa Batch API ang mga hakbang na gumagawa ng pinakamarami nitong output.