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 pag-quote ng presyo ng bawat Claude API (application programming interface). Walang iisang presyo para rito dahil magkaiba ang rate ng input at output, at may sariling pares ng rate ang bawat model. Noong August 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 bawat kasalukuyang model, limang beses na mas mataas ang output rate kaysa input rate. Kaya mas malaki ang epekto sa bill ng hatian ng input at output kaysa sa headline figure. Ibang-iba ang gastos ng app na nagpapadala ng mahahabang dokumento at nagbabalik ng maiikling sagot kumpara sa app na sumusulat ng mahahabang sagot mula sa maikling prompt.

Tungkol ang page na ito sa unit economics: magkano ang halaga ng isang token, at paano tantiyahin ang bill bago ka mag-build. 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 token

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

Mas madaling makita ang laki nito gamit ang mga inilathalang pagtatantya 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 token ay katumbas ng humigit-kumulang 400 karaniwang web page na binasa nang isang beses, o walong research paper na ganoon ang laki. Katumbas din ito ng isang buong pagdaan sa isang mid-sized codebase, o isang buwang magaan na paggamit ng chat para sa isang tao.

Ituring ang lahat ng ito bilang pagtatantya. Mas kaunting salita ang naipapaloob sa isang token ng code, JSON, at text sa mga wikang hindi English, kaya ang ratio na 0.75 ang optimistikong dulo. May isa pang salik na nagbabago sa bilang: ang Claude Opus 4.7 at mas bago, 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 kumpara sa Sonnet 4.6 at mas luma. Ang Claude Haiku 4.5 ay gumagamit ng mas lumang tokenizer. Kaya kung ang bilang na sinukat mo sa Haiku 4.5 ay mas mababa kaysa sa tunay na bilang, mas mataas ang lalabas na bilang sa Sonnet 5 para sa parehong input. Ibig sabihin, hindi patas ang direktang paghahambing ng presyo kada milyon sa pagitan ng dalawang tokenizer. Bilangin ang parehong prompt sa dalawang model bago magpasya.

Magkano ang singil ni Claude kada 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
  }
]

Nasa introductory pricing ang Claude Sonnet 5 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 nasa $5 para sa input at $25 para sa output. May isang modelong mas mataas pa rito: ang Claude Fable 5 ay may presyong $10 para sa input at $50 para sa output, kaya nakadepende sa mga aktuwal na task na ipapagawa rito kung makatuwirang bayaran ang mga rate na iyon.

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

Ipinapakita ng mga rate na ito kung magkano ang Claude, pero hindi kung ito ang mas murang option para sa workload mo. Ipinapakita naman ng tatlong task na kinuwenta ang gastos sa Claude at ChatGPT kung saan mas kapaki-pakinabang ang bawat API.

Hindi binabago ng context length ang rate. Sa Claude 4.6 at mga sumunod na version, 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 mahabang prompt dahil mas marami itong token. Walang hiwalay na rate para sa long context.

Ang arithmetic na nananatiling tama kapag nagbago 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}")

Nila-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 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.

Ang prompt caching ay nagbabawas ng gastos sa paulit-ulit na bahagi

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

Ang cache read ay nagkakahalaga ng 0.1 beses ng base input rate. Ang pagsulat 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 ang dagdag na gastos sa write habang 0.9 ang natitipid sa bawat read. Kailangang magkaroon ng dalawang read ang 1 oras na cache upang mabawi ang gastos nito.

Ang pinakasimpleng 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
  }
}

Sisingilin sa tatlong magkakaibang rate ang tatlong input counter na iyon, 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 malaki ang mali sa 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 pareho itong tahimik na nagfa-fail.

Dapat eksaktong magkapareho ang prefix sa bawat byte. Prefix match ang ginagamit sa cache lookup, kaya kapag may timestamp o pangalan ng user sa itaas ng system prompt, nagbabago ito sa bawat request. Dahil dito, 1.25 beses ng base input ang binabayaran mo sa bawat pagkakataon at wala kang nagagawang read. Ang senyales nito 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. Kapag binago mo ang mga definition ng tools, mai-invalidate ang buong cache sa ibaba ng mga ito, dahil pababa ang takbo ng invalidation sa pagkakasunod-sunod na tools, pagkatapos system, at pagkatapos messages.

Dapat sapat ang haba ng prefix. Ang minimum na haba para ma-cache ay 512 tokens sa Opus 5, 1,024 sa Sonnet 5, at 4,096 sa Haiku 4.5. Hindi naca-cache ang mas maikling prompt at walang ibinabalik na error. Ang 4,000 token na prefix sa halimbawa sa itaas ay naca-cache 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 tukuyin ang bilang ng tokens batay sa bilang ng salita. Awtomatikong binibilang ito ng API nang walang dagdag na bayad, gamit ang hiwalay na rate limit para 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 nilalaman ng response:

{ "input_tokens": 14 }

Ipadala rito ang aktuwal mong system prompt at mga tool definition, kasama ang isang kumakatawang user message, pagkatapos ay ilagay ang bilang sa cost function sa itaas. Pareho ang body na tinatanggap ng endpoint at ng message request, kaya tama ring nabibilang ang images at PDFs. Mahalaga ang dalawang caveat. Estimate ang bilang at maaaring bahagyang magkaiba sa sisingiling value. 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 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

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 halaga ng 1M token sa Claude?

Depende ito sa model at kung input o output ang mga token. Noong August 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 output cost sa bawat model na ito. Magiging $3 ang input at $15 ang output sa Sonnet 5 simula 1 September 2026. Nagbabago ang mga rate, kaya kumpirmahin ang mga ito sa official pricing page bago magtakda ng halaga sa budget.

Kapareho ba ng 1M salita ang 1M token?

Hindi. Ang isang token ay humigit-kumulang 4 na character sa English, o mga 0.75 salita, kaya ang isang milyong token ay katumbas ng humigit-kumulang 750,000 salita. Gabay lamang ang ratio na ito. 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 kaysa 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 nakatitipid sa gastos ang prompt caching?

Hindi. Ang 5 minute cache write 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 mula sa unang pagbasa. Dalawang paraan ang sanhi ng failure nito, at parehong walang ipinapakitang error. Kung magbabago ang cached prefix sa pagitan ng mga request, hindi kailanman tatama 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 mako-cache at walang error na ibabalik. 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 pinananatili ang Messages API, kaya sa turn 20 ng isang chat, kasama na naman bilang input ang lahat ng 19 na naunang turn. Kung may average na 500 token bawat turn, nagpapadala ang isang 20 turn na conversation ng humigit-kumulang 105,000 input token kahit 10,000 token lamang ang haba ng transcript. Ganito rin ang agent loop dahil nananatili sa history ang bawat tool result. I-cache ang stable prefix, o i-summarize ang mas matatandang turn at alisin ang mga ito sa request.