Magkano ang 1M tokens sa Claude API?

Magkano ang 1M tokens sa Claude?

Ang 1M tokens ay isang milyong tokens, at ito ang unit na ginagamit sa pagbanggit ng presyo ng bawat Claude API (application programming interface). Walang iisang presyo para rito dahil magkakaiba ang singil sa input at output, at may sariling pares ng rate ang bawat model. Noong August 2026, ang isang milyong input tokens ay nagkakahalaga ng $1 sa Claude Haiku 4.5, $2 sa Claude Sonnet 5, at $5 sa Claude Opus 5.

Ang output ang mas mahal na bahagi. Sa lahat ng kasalukuyang model, limang beses na mas mataas ang output rate kaysa input rate. Kaya mas malaki ang epekto ng hatian ng dalawa sa iyong bill kaysa sa pangunahing presyong ipinapakita. Magkaiba ang magiging gastos ng isang app na nagpapadala ng mahahabang dokumento at nagbabalik ng maiikling sagot, kumpara sa isang app na sumusulat ng mahahabang sagot mula sa maikling prompt.

Tumutukoy ang page na ito sa unit economics: magkano ang halaga ng isang token at paano tantiyahin ang bill bago ka bumuo. Para malaman kung saan talaga napupunta ang mga token habang nagtatrabaho ka, basahin ang kung saan napupunta ang mga token sa loob ng isang Claude Code session.

Ano ang hitsura ng 1M tokens

Ang token ay isang bahagi ng text na binabasa o sinusulat ng model. Tinatayang gabay ng Anthropic ang isang token sa bawat 4 na character, o humigit-kumulang 0.75 salita sa English. Kaya ang isang milyong token ay katumbas ng humigit-kumulang 750,000 salita, o mga 4 MB ng plain text.

Mas malinaw ang laki nito kung gagamit ng mga inilathalang pagtatantiya para sa karaniwang input.

[
  {
    "label": "Average web page (10 kB)",
    "tokens": "2,500"
  },
  {
    "label": "Documentation page (100 kB)",
    "tokens": "25,000"
  },
  {
    "label": "Research paper PDF (500 kB)",
    "tokens": "125,000"
  }
]

Sa mga rate na iyon, ang 1M tokens ay katumbas ng humigit-kumulang 400 karaniwang web page na binasa nang isang beses, o walong research paper na ganoon ang laki. Katumbas ito ng isang pagdaan sa isang katamtamang laki ng codebase, o isang buwang magaan na paggamit ng chat para sa isang tao.

Ituring lamang na pagtatantiya ang lahat ng ito. Mas kaunting salita ang napapaloob sa isang token kapag code, JSON, o text sa ibang wika bukod sa English ang ginagamit, kaya ang ratio na 0.75 ay nasa optimistikong dulo. May isa pang salik na nakaaapekto sa bilang: ang Claude Opus 4.7 at mga mas bagong bersyon nito, kabilang ang Opus 5 at Sonnet 5, ay gumagamit ng mas bagong tokenizer na lumilikha ng humigit-kumulang 30 porsiyentong mas maraming token para sa parehong text kaysa sa Sonnet 4.6 at mga naunang bersyon. Ang Claude Haiku 4.5 ay gumagamit ng mas lumang tokenizer. Kaya ang bilang na sinukat mo sa Haiku 4.5 ay mas mababa kaysa sa bilang sa Sonnet 5 para sa magkaparehong input. Ibig sabihin, hindi patas ang tuwirang paghahambing ng presyo bawat milyon sa pagitan ng dalawang tokenizer. Bilangin ang parehong prompt sa dalawang model bago magpasya.

Sinisingil ni Claude sa bawat isang milyong token

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

Ang Claude Sonnet 5 ay may panimulang presyo na $2 para sa input at $10 para sa output hanggang 31 August 2026. Mula 1 September 2026, ipatutupad ang standard rate: $3 para sa input at $15 para sa output. Ang Claude Opus 5 ay nagkakahalaga ng $5 para sa input at $25 para sa output.

Maaaring magbago ang rates. Ituring ang bawat figure sa page na ito bilang isang halimbawang nakabatay sa mga presyo noong August 2026. Kumpirmahin ang kasalukuyang mga halaga sa opisyal na pricing page bago aprubahan ang budget.

Hindi binabago ng context length ang rate. Sa Claude 4.6 at mga mas bagong bersyon, sinisingil ang buong 1M token context window sa standard pricing. Kaya pareho ang singil bawat token para sa request na may 900,000 token at request na may 9,000 token. Mas mahal ang long prompt dahil mas marami itong token. Walang hiwalay na long-context rate.

Ang arithmetic na nananatili kahit magbago ang presyo

Ang bawat bill ay binubuo ng dalawang multiplication at isang addition.

cost = (input_tokens  / 1,000,000) * input_rate
     + (output_tokens / 1,000,000) * output_rate

Isinulat bilang code na maaari mong patakbuhin:

INPUT_RATE = 2.00    # USD per million input tokens, Sonnet 5, August 2026
OUTPUT_RATE = 10.00  # USD per million output tokens

def cost(input_tokens, output_tokens):
    return (input_tokens * INPUT_RATE + output_tokens * OUTPUT_RATE) / 1_000_000

print(f"{cost(4300, 400):.4f}")

Ipi-print nito ang 0.0126. Ang request na nagpapadala ng 4,300 input tokens at tumatanggap ng 400 output tokens ay nagkakahalaga ng humigit-kumulang 1.3 cents sa Sonnet 5. Panatilihin sa iisang lugar sa iyong code ang dalawang rate. Kapag nagbago ang presyo, dalawang linya lang ang ie-edit mo, at magbabago rin ang bawat estimate sa iyong system.

Isang aktuwal na pagtatantya para sa isang app

Isaalang-alang ang isang support assistant. Umaabot sa 4,000 tokens ang system prompt at product documentation nito, at ipinapadala ang mga ito sa bawat request dahil stateless ang Messages API at walang naaalala ang model sa pagitan ng mga call. Nagdaragdag ang tanong ng user ng humigit-kumulang 300 tokens. Karaniwang 400 tokens ang sagot. Ibig sabihin, 4,300 input tokens at 400 output tokens bawat request.

Ang 1 million input tokens ay sapat para sa humigit-kumulang 232 request na ganito ang anyo. Sa 1,000 request bawat araw, kumokonsumo ang app ng 4.3 million input tokens araw-araw. Kaya ang "1M tokens" ay katumbas ng wala pang anim na oras ng traffic.

[
  {
    "label": "Opus 5, list rates",
    "cost_per_1k_usd": "31.50"
  },
  {
    "label": "Sonnet 5, list rates",
    "cost_per_1k_usd": "12.60"
  },
  {
    "label": "Sonnet 5, Batch API",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Haiku 4.5, list rates",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Sonnet 5, warm prompt cache",
    "cost_per_1k_usd": "5.40"
  }
]

Sa Claude Opus 5, nagkakahalaga ang traffic na ito ng $31.50 bawat 1,000 request. Sa Sonnet 5, nagkakahalaga ito ng $12.60. Kapag lumipat sa Claude Haiku 4.5, bababa ito sa $6.30, at mas mababa pa ang gastos kapag may warm prompt cache sa Sonnet 5: $5.40.

I-multiply ito sa 30 para sa isang buwang ganitong traffic. Sa list rates, humigit-kumulang $378 bawat buwan ang Sonnet 5. Sa parehong app na may warm cache, humigit-kumulang $162 ito. Mas malaki ang halaga ng pagpili mo ng model at desisyon mo tungkol sa caching kaysa sa anumang rate na maaari mong ma-negosasyon sa ganitong volume. Hiwalay na tanong kung aling model ang gagamitin. Ang pinakamurang model na pumapasa sa iyong evaluations ang dapat piliin: ipinapaliwanag ng pagpili sa Opus, Sonnet at Haiku kung paano ito susuriin nang tama.

Binabawasan ng prompt caching ang paulit-ulit na bahagi

Magkapareho ang 4,000 token na prefix sa bawat request, at buong input price ang binabayaran mo sa bawat pagkakataon. Iniimbak ng prompt caching ang na-process na prefix at mas mababang rate ang sinisingil kapag muli itong ginamit.

Ang cache read ay nagkakahalaga ng 0.1 beses ng base input rate. Ang pagsusulat sa cache ay nagkakahalaga ng 1.25 beses ng base rate para sa 5 minutong lifetime, o 2 beses ng base rate para sa 1 oras na lifetime. Kaya nababawi ng 5 minutong cache ang gastos nito pagkatapos ng isang read, dahil 0.25 na dagdag ang gastos sa pagsulat habang 0.9 ang natitipid sa bawat read. Kailangan ng 1 oras na cache ng dalawang read para maabot ang break-even.

Ang pinakamadaling paraan para i-enable ito ay isang top-level field:

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 1024,
    "cache_control": {"type": "ephemeral"},
    "system": "You are a helpful assistant.",
    "messages": [
      {"role": "user", "content": "What are the key themes in Pride and Prejudice?"}
    ]
  }'

Pagkatapos, basahin ang usage block na ibinabalik:

{
  "usage": {
    "cache_creation_input_tokens": 5120,
    "cache_read_input_tokens": 1800,
    "input_tokens": 50,
    "output_tokens": 503
  }
}

Ang tatlong input counter na ito ay sinisingil sa tatlong magkakaibang rate, at ang kabuuan ng mga ito ang aktuwal mong input volume: total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Magiging lubhang mali ang cost estimate na input_tokens lamang ang binabasa kapag naka-enable ang caching.

May dalawang bagay na pumipigil sa cache na mabawi ang gastos nito, at parehong tahimik na nagfa-fail.

Dapat eksaktong magkapareho ang prefix sa antas ng byte. Prefix match ang ginagamit ng cache lookup, kaya binabago ng timestamp o pangalan ng user sa itaas ng system prompt ang prefix sa bawat request. Dahil dito, 1.25 beses ng base input ang binabayaran mo sa bawat pagkakataon at wala kang nagagawang read. Ang sintomas ay nananatiling mataas ang cache_creation_input_tokens habang nananatiling 0 ang cache_read_input_tokens. Ilagay ang cache_control sa huling block na pareho ang content sa lahat ng request, at ilagay pagkatapos nito ang lahat ng nagbabago. Ang pagbabago sa iyong tools definitions ay nag-iinvalidate sa buong cache sa ibaba ng mga ito, dahil pababa ang takbo ng invalidation ayon sa pagkakasunod-sunod na tools, pagkatapos system, pagkatapos messages.

Dapat sapat ang haba ng prefix. Ang minimum na cacheable length ay 512 tokens sa Opus 5, 1,024 sa Sonnet 5 at 4,096 sa Haiku 4.5. Hindi naka-cache ang mas maikling prompt at walang ibinabalik na error. Ang 4,000 token na prefix sa halimbawa sa itaas ay naka-cache sa Sonnet 5 at hindi naka-cache sa Haiku 4.5, dahil mas mababa ang 4,000 sa floor ng model na iyon. Kapag parehong 0 ang mga counter, walang na-cache.

Hinahati ng batch processing ang rate

Pinoproseso ng Batch API ang mga request nang asynchronous na may 50 porsiyentong discount sa input at output. Sa halimbawa sa itaas, ginagawa nitong $12.60 bawat 1,000 request ang $6.30. Naiipon ang discount na ito kasama ng prompt caching, kaya ang naka-cache na batch job ang pinakamurang paraan para magpatakbo ng maramihang gawain.

Ang kapalit nito ay latency, kaya hindi angkop ang batch sa anumang hinihintay ng isang tao habang tumatakbo ito. Angkop ito para sa overnight classification at document backfills.

Bakit lumalaki ang gastos sa chat sa loob ng isang conversation

Dahil walang state na pinapanatili ang API, ipinapadala muli ng client ang buong conversation sa bawat turn. Kaya ang paggamit ng token sa isang chat ay lumalaki ayon sa square ng haba nito, hindi nang tuwiran.

Ipagpalagay na ang bawat turn ay may average na 500 token. Nagpapadala ang Turn 1 ng 500 input token. Nagpapadala ang Turn 2 ng 1,000. Nagpapadala ang Turn 20 ng 10,000. Kapag isinama ito gamit ang n(n+1)/2, ang isang conversation na may 20 turn ay nakapagpadala ng humigit-kumulang 105,000 input token, kahit 10,000 token lamang ang haba ng transcript mismo.

Kaya mas mataas ang gastos ng isang chat feature kaysa sa ipinahihiwatig ng transcript nito. Nakakatulong nang malaki sa mahahabang thread ang pag-cache ng stable prefix o pagbubuod ng mas lumang mga turn. Ganito rin ang pattern ng isang agent na paulit-ulit na gumagamit ng tool calls, ngunit mas malala: nananatili sa history ang bawat resulta ng tool at ipinapadalang muli sa bawat susunod na turn. Pinakamahalaga rito ang Pagtatakda ng mahigpit na limitasyon sa gastos para sa agent na ikaw mismo ang nagpapatakbo, dahil awtomatikong lumalaki ang gastos at walang nagmo-monitor nito.

Bilangin ang mga token bago manghula

Huwag nang kunin ang bilang ng token mula sa bilang ng salita. Awtomatikong binibilang ito ng API nang walang bayad, gamit ang hiwalay na rate limit mula sa paggawa ng message.

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "system": "You are a scientist",
    "messages": [{
      "role": "user",
      "content": "Hello, Claude"
    }]
  }'

May isang field ang response:

{ "input_tokens": 14 }

Ipadala rito ang aktuwal mong system prompt at mga tool definition, kasama ang isang representative na user message, pagkatapos ay ilagay ang numero sa cost function sa itaas. Pareho ang body na tinatanggap ng endpoint at ng message request, kaya tama ring nabibilang ang mga image at PDF. Mahalaga ang dalawang caveat. Tantiya ang bilang at maaaring bahagyang magkaiba sa sisingiling figure. Sinusukat din ito gamit ang tokenizer ng model na ipinasa mo, kaya gamitin ang model na aktuwal mong patatakbuhin.

Hindi maaaring bilangin nang maaga ang output token dahil hindi pa umiiral ang mga ito. Limitahan ang mga ito gamit ang max_tokens, pagkatapos ay sukatin ang aktuwal na distribution mula sa usage.output_tokens sa live traffic.

Ano pa ang napupunta sa bill

Karamihan ng bill ay mga token. May ilang item na hindi token, at nakagugulat ang mga ito sa mga user.

• Nagiging input tokens ang mga tool definition sa bawat request. Ang system prompt para sa tool use lamang ay nagdaragdag ng 286 hanggang 406 tokens sa Opus 5, bago pa ang sarili mong schema. Maaaring doblehin ng sampung mahahabang tool description ang isang maliit na prompt.
• May singil ang web search na $10 sa bawat 1,000 search, bukod pa sa mga token na ginagamit ng mga resulta kapag pumapasok ang mga ito sa context.
• Walang sariling bayad ang web fetch, ngunit nagiging input tokens ang na-fetch na page. Ang isang documentation page na 100 kB ay humigit-kumulang 25,000 na token.
• Ang paghingi ng US-only inference gamit ang inference_geo sa Claude 4.6 at mas bagong bersyon ay naglalapat ng 1.1 multiplier sa bawat kategorya ng token, kabilang ang cache reads at cache writes.

Depende sa dami ng paggamit mo kung API nga ang tamang bilhin. Kapag mababa sa isang antas ang paggamit, mas mainam ang flat monthly plan, at inihahambing ng API kumpara sa Claude subscription ang mga ito gamit ang aktuwal na mga numero.

FAQ

Magkano ang halaga ng 1M tokens sa Claude?

Depende ito sa model at kung input o output ang mga token. Noong Agosto 2026, ang isang milyong input token ay nagkakahalaga ng $1 sa Claude Haiku 4.5, $2 sa Claude Sonnet 5 sa ilalim ng introductory pricing, at $5 sa Claude Opus 5. Limang beses ng input rate ang halaga ng output sa bawat model na ito. Magiging $3 ang input at $15 ang output ng Sonnet 5 sa 1 September 2026. Nagbabago ang mga rate, kaya kumpirmahin ang mga ito sa opisyal na pricing page bago ka magtakda ng halaga sa budget.

Kapareho ba ng 1M salita ang 1M tokens?

Hindi. Ang isang token ay humigit-kumulang 4 na character sa English, o mga 0.75 salita, kaya ang isang milyong token ay nasa 750,000 salita. Tantiya lamang ang ratio na iyon. Mas maraming token bawat salita ang code, JSON at mga wikang hindi English. Gumagamit din ang Claude Opus 4.7 at mga susunod na bersyon ng mas bagong tokenizer na gumagawa ng humigit-kumulang 30 porsiyentong mas maraming token para sa kaparehong text kumpara sa Claude Sonnet 4.6 at mga naunang bersyon. Dahil dito, hindi direktang maihahambing ang mga count sa magkakaibang model generation. Sukatin gamit ang libreng /v1/messages/count_tokens endpoint at ipasa ang model na balak mong patakbuhin.

Palagi bang nakakatipid sa gastos ang prompt caching?

Hindi. Ang pagsusulat sa 5 minute cache ay nagkakahalaga ng 1.25 beses ng base input rate. Kaya ang prefix na naisulat ngunit hindi kailanman nabasa ay nagkakahalaga ng 25 porsiyentong higit kaysa sa karaniwang pagpapadala nito. Nababayaran nito ang sarili nito sa unang pagbasa pa lamang. Dalawang paraan itong maaaring mabigo, at parehong walang error na ipinapakita. Kung magbago ang cached prefix sa pagitan ng mga request, hindi kailanman tatama ang lookup dahil eksaktong prefix match ito. Kung mas maikli ang prefix kaysa sa minimum cacheable length ng model, na 1,024 token sa Sonnet 5 at 4,096 sa Haiku 4.5, walang mapi-cache at walang ibabalik na error. Kapag parehong 0 ang binabasa ng cache_creation_input_tokens at cache_read_input_tokens, walang ginagawa ang cache.

Bakit mas mabilis lumaki ang bill ko kaysa sa bilang ng mga message?

Dahil ipinapadala muli ang buong conversation sa bawat turn. Walang state na hinahawakan ang Messages API, kaya ang turn 20 ng isang chat ay muling nagpapadala ng lahat ng naunang 19 turn bilang input. Kung ang bawat turn ay may average na 500 token, nagpapadala ang isang 20 turn conversation ng humigit-kumulang 105,000 input token kahit 10,000 token lamang ang haba ng transcript. Pareho ang epekto sa agent loop dahil nananatili sa history ang bawat resulta ng tool. I-cache ang stable prefix, o ibuod ang mga naunang turn at alisin ang mga ito sa request.