Magkano ang 1M tokens sa Claude?

Magkano ang 1M tokens sa Claude?

Ang 1M tokens ay nangangahulugang one million tokens. Ito ang unit na ginagamit sa pagbanggit ng mga presyo ng Claude API (application programming interface) models. Walang iisang presyo para rito dahil magkaiba ang billing rate ng input at output, at may sariling pares ng rate ang bawat model. May dalawang pares ng rate ang Claude Haiku 5.5: isa para sa mga prompt na hanggang 100,000 tokens at mas mataas na rate para sa mga prompt na lampas dito. Noong October 2026, ang one million 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 ang output rate kumpara sa input rate. Kaya mas malaking epekto sa bill ang hatian ng input at output kaysa sa nakalistang headline figure. Magkaiba nang malaki ang gastos ng app na nagpapadala ng mahahabang dokumento at nagbabalik ng maiikling sagot kumpara sa app na nagsusulat ng mahahabang sagot mula sa maikling prompt.

Tungkol ang page na ito sa unit economics: magkano ang halaga ng isang token at paano mag-estimate ng bill bago mag-build. Para makita 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. Tinatantiya ng glossary ng Anthropic na ang isang token ay humigit-kumulang 3.5 English character sa mga model bago ang Claude 4.7. Ayon sa model overview ng Anthropic, ang 1 million tokens ay naglalaman ng humigit-kumulang 750,000 salita sa mga model na iyon. Sa 3.5 character bawat token, katumbas ito ng humigit-kumulang 3.5 million character, o mga 3.5 MB ng plain English text. Sa mas bagong tokenizer na ipinakilala sa Claude Opus 4.7, ang parehong 1 million tokens ay naglalaman ng humigit-kumulang 555,000 salita, o mga 2.5 million character.

Mas madaling makita ang sukat nito gamit ang 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 ito, ang 1M tokens ay katumbas ng humigit-kumulang 400 karaniwang web page na binasa nang isang beses, o walong research paper na ganito ang laki. Katumbas din ito ng isang buong pagproseso sa isang mid-sized na codebase, o isang buwang magaan na chat use para sa isang tao.

Ituring ang lahat ng ito bilang pagtatantiya. Mas kaunting salita ang napapaloob sa isang token kapag code, JSON, o text sa ibang wika bukod sa English ang ginagamit. Kaya ang mga word count na ito ang optimistikong pagtatantiya. May isa pang salik na nagbabago 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 percent na 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 kung sinukat mo ang bilang gamit ang Haiku 4.5, mas mababa ito kaysa sa aktuwal na bilang sa Sonnet 5 para sa parehong input. Dahil dito, hindi patas ang direktang paghahambing ng presyo bawat milyon sa pagitan ng mga model na ito. Bilangin ang parehong prompt laban sa parehong model bago magpasya.

Magkano ang singil ni Claude kada milyong token

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5
  },
  {
    "label": "Sonnet 5",
    "input_usd": 2,
    "output_usd": 10
  },
  {
    "label": "Sonnet 4.6",
    "input_usd": 3,
    "output_usd": 15
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25
  }
]

Ang Claude Sonnet 5 ay nagkakahalaga ng $2 para sa input at $10 para sa output. Unang iniaalok ng Anthropic ang presyong ito bilang introductory rate hanggang 31 August 2026, pagkatapos ay ginawa itong standard price at kinansela ang planong pagtataas sa $3 at $15. Ang Claude Opus 5 ay nagkakahalaga ng $5 at $25. Higit na mahal ang mga Fable model: parehong may presyong $10 para sa input at $50 para sa output ang Claude Fable 5 at ang mas bagong Claude Fable 5.1, kaya nakadepende sa mga aktuwal na task na ipapagawa mo rito kung sulit bayaran ang mga rate na iyon.

Mas bago ang kasalukuyang lineup ng Anthropic kaysa sa mga model na sinuri sa presyo sa page na ito. Ang Claude Opus 5.5 ay may presyong $4 para sa input at $20 para sa output, ang Claude Sonnet 5.5 ay $2 at $10, at ang Claude Haiku 5.5 ay nagsisimula sa $0.10 at $0.50. Nakalista na ngayon bilang legacy models ang Opus 5, Sonnet 5, Haiku 4.5, at Fable 5, pero available pa rin ang mga ito, kaya gagana pa rin ang mga halimbawa sa ibaba gaya ng pagkakasulat. Tinalakay sa Magkano ang Claude Haiku 5.5 at saan ito angkop ang pinakamura sa mga bagong model.

Nagbabago ang mga rate. Ituring ang bawat halagang nasa page na ito bilang halimbawang ginawa noong October 2026, at kumpirmahin ang kasalukuyang mga numero sa official pricing page bago aprubahan ang budget.

Ipinapakita ng mga rate na ito kung magkano ang Claude, pero hindi kung ito ang pinakamurang option para sa workload mo. Ipinapakita naman ng tatlong task na siningil sa Claude at ChatGPT kung alin sa dalawang API ang mas matipid sa bawat sitwasyon.

Hindi binabago ng haba ng context ang rate, maliban sa isang exception. Sa Claude 4.6 at mga mas bagong model, maliban sa Claude Haiku 5.5, sinisingil sa standard pricing ang buong 1M token context window. Dahil dito, pareho ang singil kada token para sa request na may 900,000 token at request na may 9,000 token. Mas mahal ang mahabang prompt dahil mas marami itong token; walang hiwalay na long-context rate. Sa halip, batay sa haba ng prompt ang pricing ng Claude Haiku 5.5: kung lampas 100,000 token ang prompt ng isang request, $0.50 para sa input at $2.50 para sa output kada milyon ang sisingilin, sa halip na $0.10 at $0.50. Kasama sa pagtukoy kung lalampas sa threshold na ito ang cache reads at cache writes.

Arithmetika na nananatiling tama 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, October 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}")

Nagpi-print iyon ng 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. Ilagay sa iisang bahagi ng code ang dalawang rate. Kapag nagbago ang presyo, dalawang linya lang ang ie-edit mo, at awtomatikong magbabago kasabay nito ang bawat estimate sa system mo.

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. 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. Umaabot naman sa mga 400 tokens ang sagot. Ibig sabihin, 4,300 input tokens at 400 output tokens ang bawat request.

Ang 1M input tokens ay sapat para sa humigit-kumulang 232 request na ganito ang anyo. Kung 1,000 request bawat araw, kumokonsumo ang app ng 4.3 million input tokens kada araw. Kaya ang “1M tokens” ay 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, ito ay $12.60. Kung lilipat sa Claude Haiku 4.5, magiging $6.30, at mas mababa pa ito kapag may warm prompt cache sa Sonnet 5, na nagkakahalaga ng $5.40.

I-multiply sa 30 para sa isang buwang ganito ang traffic. Sa list rates, nasa $378 bawat buwan ang Sonnet 5. Kung may warm cache, nasa $162 bawat buwan ang parehong app. Mas malaki ang epekto ng pagpili ng model at caching decision kaysa sa anumang rate na maaari mong ma-negotiate 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 pagitan ng Opus, Sonnet at Haiku kung paano ito test nang maayos.

Binabawasan ng prompt caching ang paulit-ulit na bahagi

Magkapareho ang 4,000 token na prefix sa bawat request, at buong presyo ng input ang binabayaran mo sa bawat pagkakataon. Iniimbak ng prompt caching ang naprosesong prefix at naniningil ng mas mababang rate kapag ginagamit itong muli.

Sa mga model na nasa price chart at worked examples ng page na ito (Haiku 4.5, Sonnet 5, Sonnet 4.6 at Opus 5), pati na rin sa Fable 5, ang cache read ay nagkakahalaga ng 0.1 beses ng base input rate. Mas mababa ang singil ng ilang mas bagong model para sa read: 0.05 beses sa Opus 5.5 at Sonnet 5.5, at 0.025 beses sa Fable 5.1 at Mythos 5.1. Ang pagsusulat sa cache ay nagkakahalaga ng 1.25 beses ng base rate para sa 5 minute lifetime, o 2 beses ng base rate para sa 1 hour lifetime. Kaya sa mga model na 0.1 beses ang rate, nababawi ng 5 minute cache ang gastos pagkatapos ng isang read. Ang dagdag na gastos sa pagsusulat ay 0.25, samantalang 0.9 ang natitipid sa bawat read. Kailangang magkaroon ng dalawang read ang 1 hour cache para mag-break even.

Ang pinakasimpleng paraan para i-enable ito ay isang single 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 na ang caching.

May dalawang dahilan kung bakit hindi nababawi ng cache ang gastos, at kapwa ito tahimik na nabibigo.

Dapat eksaktong magkapareho ang prefix sa antas ng byte. Prefix match ang ginagamit sa cache lookup. Kaya kapag naglagay ka ng timestamp o pangalan ng user sa itaas ng system prompt, nagbabago ito sa bawat request. Magbabayad ka ng 1.25 beses ng base input sa bawat pagkakataon at hindi kailanman makakagawa ng read. Ang makikitang 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 ang lahat ng nagbabagong bahagi pagkatapos nito. Kapag binago mo ang mga definition ng tools, magiging invalid ang buong cache sa ibaba ng mga ito dahil isinasagawa ang invalidation ayon sa pagkakasunod-sunod na tools, pagkatapos system, at 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. Naka-cache ang 4,000 token na prefix sa halimbawa sa itaas sa Sonnet 5, ngunit hindi sa Haiku 4.5 dahil mas mababa ang 4,000 sa minimum ng model na iyon. Kapag parehong 0 ang dalawang counter, walang na-cache.

Binababa ng batch processing sa kalahati ang rate

Pinoproseso ng Batch API ang mga request nang asynchronous, at may 50 percent na bawas sa bayad para sa input at output. Sa halimbawa sa itaas, nagiging $12.60 kada 1,000 request ang halagang $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 gawain na hinihintay ng isang tao ang resulta. Angkop ito para sa overnight classification at document backfills.

Bakit tumataas ang gastos ng chat sa loob ng iisang 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 may average na 500 token ang bawat turn. Nagpapadala ang Turn 1 ng 500 input token. Nagpapadala ang Turn 2 ng 1,000. Nagpapadala ang Turn 20 ng 10,000. Gamit ang n(n+1)/2, ang 20-turn na conversation ay nakapagpadala ng humigit-kumulang 105,000 input token, kahit 10,000 token lang ang haba ng transcript mismo.

Kaya mas mahal ang isang chat feature kaysa sa ipinahihiwatig ng transcript nito. Kaya rin sulit sa mahahabang thread ang pag-cache sa stable prefix o pagbubuod sa mas lumang mga turn. Ganito rin ang pattern ng isang agent na paulit-ulit na tumatawag sa mga tool, at mas malala pa: nananatili sa history ang bawat resulta ng tool at ipinapadala itong muli sa bawat susunod na turn. Magtakda ng mahigpit na spending limit para sa agent na ikaw mismo ang nagpapatakbo ang pinakamahalaga rito, dahil awtomatikong lumalaki ang gastos at walang nagbabantay dito.

Bilangin ang tokens bago manghula

Huwag nang kunin ang bilang ng tokens mula sa bilang ng mga salita. Binibilang ito ng API para sa iyo 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"
    }]
  }'

Isang field ang laman ng response:

{ "input_tokens": 14 }

Ipadala rito ang aktuwal mong system prompt at mga tool definition, kasama ang representative na user message, at ilagay ang bilang sa cost function sa itaas. Pareho ang body na tinatanggap ng endpoint at ng message request, kaya tama ring nabibilang ang mga larawang at PDF na ipinadala bilang base64. Tinatanggihan nito ang mga server tool gaya ng web search at web fetch, pati ang mga larawan o dokumentong ipinasa sa pamamagitan ng URL o file reference. Mahalaga ang dalawang caveat. Tantiya ang bilang at maaari itong bahagyang magkaiba sa halagang sisingilin. 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 tokens dahil wala pa ang mga ito. Limitahan ang mga ito gamit ang max_tokens, pagkatapos sukatin ang aktuwal na distribution mula sa usage.output_tokens sa live traffic.

Ano pa ang napupunta sa bill

Mga token ang bumubuo sa karamihan ng bill. May ilang item na hindi token, at nakapagtataka ang mga ito para sa maraming user.

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

Kung sulit bang bilhin ang API ay nakadepende sa volume ng paggamit mo. Karaniwan, kapag naabot ang usage ceiling ng isang plan, saka lumilitaw ang tanong na ito, at ang mga paraan para lampasan ang limit ay mula sa paghihintay na mag-reset ang window hanggang sa paglipat ng gawaing iyon sa metered API calls. Kapag mas mababa sa isang partikular na antas ang paggamit, mas sulit ang flat monthly plan, at inihahambing ng API sa Claude subscription ang dalawang opsyon gamit ang aktuwal na mga numero.

FAQ

Magkano ang 1M token sa Claude?

Depende ito sa model at kung input o output ang mga token. Noong October 2026, ang isang milyong input token ay nagkakahalaga ng $1 sa Claude Haiku 4.5, $2 sa Claude Sonnet 5, at $5 sa Claude Opus 5. Ang mas bagong Claude Haiku 5.5 ay nagsisimula sa $0.10 bawat milyong input token para sa mga prompt na hanggang 100,000 token, at naniningil ng $0.50 para sa higit dito. Limang beses ng input rate ang halaga ng output sa bawat model na ito. Nagbabago ang mga rate, kaya kumpirmahin ang mga ito sa opisyal na pricing page bago magtakda ng halaga sa budget.

Kapareho ba ng 1M salita ang 1M token?

Hindi. Sa mga model bago ang Claude Opus 4.7, tinatantiya ng Anthropic na ang isang token ay katumbas ng humigit-kumulang 3.5 English character, at sinasabing naglalaman ang isang milyong token ng humigit-kumulang 750,000 salita. Sa mas bagong tokenizer na ginagamit ng Claude Opus 4.7 at mga sumunod dito, naglalaman ang isang milyong token ng humigit-kumulang 555,000 salita, dahil gumagawa ang tokenizer na iyon ng humigit-kumulang 30 porsiyentong mas maraming token para sa parehong text kaysa sa Claude Sonnet 4.6 at mga nauna rito. Gabay lamang ang mga ratio na iyon. Mas maraming token bawat salita ang ginagamit ng code, JSON, at mga wikang hindi English, at hindi portable ang mga bilang sa pagitan ng magkakaibang henerasyon ng model. Sukatin gamit ang libreng /v1/messages/count_tokens endpoint, at ipasa ang model na balak mong patakbuhin.

Palagi bang nakakatipid ng pera ang prompt caching?

Hindi. Ang 5 minutong cache write ay nagkakahalaga ng 1.25 beses ng base input rate, kaya ang prefix na isinulat ngunit hindi kailanman binasa ay nagkakahalaga ng 25 porsiyentong higit kaysa sa direktang pagpapadala nito. Nababayaran nito ang sarili mula sa unang pagbasa. Dalawang paraan ang dahilan kung bakit maaari itong hindi gumana, at parehong walang ipinapakitang error. Kung nagbabago ang naka-cache na prefix sa pagitan ng mga request, hindi kailanman tumutugma ang lookup dahil exact 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 naka-cache at walang ibinabalik 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 ipinapadalang 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 19 na naunang turn bilang input. Kung may average na 500 token ang bawat turn, nagpapadala ang isang 20-turn conversation ng humigit-kumulang 105,000 input token kahit 10,000 token lamang ang haba ng transcript. Ganito rin gumagana ang mga agent loop dahil nananatili sa history ang bawat tool result. I-cache ang stable prefix, o ibuod ang mas lumang mga turn at alisin ang mga ito sa request.