Claude இல் 1M tokens-க்கு எவ்வளவு செலவாகும்?

Claude இல் 1M tokens-ன் விலை எவ்வளவு?

1M tokens என்பது one million tokens-ஐக் குறிக்கும். Claude API (application programming interface) ஒவ்வொன்றின் விலையும் இந்த அலகில்தான் குறிப்பிடப்படுகிறது. இதற்கு ஒரே விலை இல்லை. input மற்றும் output ஆகியவற்றுக்கு வெவ்வேறு கட்டண விகிதங்கள் உள்ளன. ஒவ்வொரு model-க்கும் தனித்தனி input மற்றும் output விகிதங்கள் உள்ளன. August 2026 நிலவரப்படி, Claude Haiku 4.5 இல் one million input tokens-க்கு $1 செலவாகும். Claude Sonnet 5 இல் $2 செலவாகும். Claude Opus 5 இல் $5 செலவாகும்.

Output அதிகச் செலவான பகுதி. தற்போதைய ஒவ்வொரு model-லும் output விகிதம் input விகிதத்தைவிட five times அதிகம். எனவே, தலைப்பில் குறிப்பிடப்படும் விலையைவிட input மற்றும் output ஆகியவற்றின் பிரிப்பே உங்கள் கட்டணத்தை அதிகமாகத் தீர்மானிக்கிறது. நீண்ட documents-ஐ அனுப்பி, குறுகிய பதில்களைப் பெறும் app-ன் கட்டணப் போக்கு, குறுகிய prompt-இலிருந்து நீண்ட பதில்களை உருவாக்கும் app-ன் கட்டணப் போக்கிலிருந்து முற்றிலும் வேறுபடும்.

இந்தப் பக்கம் unit economics பற்றியது: ஒரு token-ன் விலை என்ன, build செய்வதற்கு முன் கட்டணத்தை எவ்வாறு மதிப்பிடுவது என்பவை இதில் விளக்கப்படுகின்றன. நீங்கள் பணிபுரியும் போது tokens உண்மையில் எங்கு செல்கின்றன என்பதை அறிய, Claude Code session-க்குள் tokens எங்கு செல்கின்றன என்பதைப் படிக்கவும்.

1M tokens எவ்வாறு இருக்கும்

ஒரு token என்பது model படிக்கும் அல்லது எழுதும் text-இன் ஒரு பகுதி. Anthropic வழங்கும் தோராயமான வழிகாட்டுதலின்படி, 4 characters-க்கு 1 token அல்லது English மொழியில் சுமார் 0.75 words இருக்கும். ஆகவே, 1M tokens என்பது சுமார் 750,000 words அல்லது plain text-ஆக தோராயமாக 4 MB ஆகும்.

பொதுவாகப் பயன்படுத்தப்படும் inputs-க்கான வெளியிடப்பட்ட மதிப்பீடுகள், இந்த அளவை நன்றாகப் புரிந்துகொள்ள உதவுகின்றன.

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

அந்த விகிதங்களில், 1M tokens என்பது சராசரி அளவிலான சுமார் 400 web pages-ஐ ஒருமுறை படிப்பதற்குச் சமம். அல்லது அந்த அளவிலான 8 research papers-க்குச் சமம். இது நடுத்தர அளவிலான codebase-ஐ ஒருமுறை முழுவதும் பார்ப்பதற்கும், ஒருவரின் குறைந்த அளவிலான chat பயன்பாட்டின் 1 மாதத்திற்கும் சமமாகும்.

இவை அனைத்தையும் மதிப்பீடுகளாகவே கருதுங்கள். English அல்லாத மொழிகளில் உள்ள Code, JSON மற்றும் text ஆகியவை ஒரு token-க்குள் குறைவான words-ஐக் கொண்டிருக்கும். எனவே 0.75 என்ற விகிதம் சாதகமான மேல்கட்ட மதிப்பீடாகும். எண்ணிக்கையை மாற்றும் மற்றொரு காரணியும் உள்ளது: Opus 5 மற்றும் Sonnet 5 ஆகியவற்றை உள்ளடக்கிய Claude Opus 4.7 மற்றும் அதற்குப் பிந்தைய versions, Sonnet 4.6 மற்றும் அதற்கு முந்தைய versions-ஐவிட அதே text-க்கு தோராயமாக 30 percent அதிக tokens-ஐ உருவாக்கும் புதிய tokenizer-ஐப் பயன்படுத்துகின்றன. Claude Haiku 4.5 பழைய tokenizer-ஐப் பயன்படுத்துகிறது. எனவே, Haiku 4.5-ல் அளந்த count, அதே input-க்கு Sonnet 5-ல் இருக்கும் count-ஐவிடக் குறைவாக இருக்கும். இதனால், அந்த எல்லையைத் தாண்டி price-per-million அடிப்படையில் நேரடியாக ஒப்பிடுவது நியாயமானதல்ல. முடிவு செய்வதற்கு முன், அதே prompt-ஐ இரு models-க்கும் எதிராகக் கணக்கிடுங்கள்.

ஒரு million tokens-க்கு Claude வசூலிக்கும் கட்டணம்

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

Claude Sonnet 5-க்கு 31 August 2026 வரை அறிமுகக் கட்டணம் பொருந்தும்: input-க்கு $2, output-க்கு $10. 1 September 2026 முதல் நிலையான கட்டணம் பொருந்தும்: input-க்கு $3, output-க்கு $15. Claude Opus 5-க்கு input-க்கு $5, output-க்கு $25.

கட்டண விகிதங்கள் மாறக்கூடும். இந்தப் பக்கத்தில் உள்ள ஒவ்வொரு எண்ணையும் August 2026-க்கான கணக்கீட்டு எடுத்துக்காட்டாகக் கருதுங்கள். பட்ஜெட்டுக்கு இறுதி ஒப்புதல் அளிப்பதற்கு முன், தற்போதைய எண்களை அதிகாரப்பூர்வ pricing பக்கம் இல் உறுதிப்படுத்துங்கள்.

Context length கட்டண விகிதத்தை மாற்றாது. Claude 4.6 மற்றும் அதற்குப் பிந்தைய versions-ல் முழு 1M token context window-க்கும் நிலையான pricing பொருந்தும். எனவே, 900,000 token request-க்கு ஒரு token-க்கான கட்டணம் 9,000 token request-க்கான கட்டணத்துடன் ஒன்றே. நீண்ட prompt-க்கு அதிக tokens இருப்பதால் அதிகக் கட்டணம் வசூலிக்கப்படும். தனியான long-context கட்டணம் பொருந்தாது.

விலை மாற்றத்தையும் தாங்கும் கணக்கீடு

ஒவ்வொரு bill-ம் இரண்டு பெருக்கல்களையும் ஒரு கூட்டலையும் கொண்டது.

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

இதை இயக்கக்கூடிய code ஆக எழுதினால்:

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}")

அது 0.0126-ஐ அச்சிடும். 4,300 input tokens-ஐ அனுப்பி, 400 output tokens-ஐ பெறும் request-ன் விலை Sonnet 5-ல் சுமார் 1.3 cents ஆகும். இரண்டு rates-ஐ உங்கள் code-ல் ஒரே இடத்தில் வைத்திருங்கள். விலை மாறும்போது இரண்டு வரிகளைத் திருத்தினால் போதும்; உங்கள் system-இல் உள்ள ஒவ்வொரு estimate-மும் அதற்கேற்ப மாறும்.

உண்மையான பயன்பாட்டிற்கான கணக்கீட்டு மதிப்பீடு

ஒரு support assistant-ஐ எடுத்துக்கொள்ளுங்கள். அதன் system prompt மற்றும் product documentation ஆகியவை சேர்ந்து 4,000 tokens ஆகின்றன. Messages API stateless ஆக இருப்பதால், மேலும் calls-க்கிடையில் model எதையும் நினைவில் வைத்திருக்காததால், அவை ஒவ்வொரு request-லும் அனுப்பப்படுகின்றன. ஒரு user question மேலும் சுமார் 300 tokens சேர்க்கிறது. ஒரு answer சுமார் 400 tokens ஆகும். ஆகவே, ஒவ்வொரு request-க்கும் 4,300 input மற்றும் 400 output tokens தேவைப்படும்.

ஒரு million input tokens இந்த வடிவிலான சுமார் 232 requests-க்கு போதுமானது. நாளொன்றுக்கு 1,000 requests என்ற அளவில், app தினமும் 4.3 million input tokens பயன்படுத்தும். எனவே, "1M tokens" என்பது ஆறு மணி நேரத்திற்கும் குறைவான 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"
  }
]

Claude Opus 5-ல், அந்த traffic-க்கான செலவு 1,000 requests-க்கு $31.50 ஆகும். Sonnet 5-ல் அது $12.60 ஆகும். Claude Haiku 4.5-க்கு மாறினால், செலவு $6.30 ஆகக் குறையும். Sonnet 5-ல் warm prompt cache பயன்படுத்தினால், செலவு $5.40 ஆக மேலும் குறையும்.

அந்த traffic-ஐ ஒரு மாதத்திற்குக் கணக்கிட 30-ஆல் பெருக்குங்கள். list rates அடிப்படையில் Sonnet 5-ன் மாதச் செலவு சுமார் $378. warm cache பயன்படுத்தும் அதே app-ன் செலவு சுமார் $162. இந்த அளவிலான traffic-ல், நீங்கள் தேர்ந்தெடுக்கும் model மற்றும் caching குறித்த உங்கள் முடிவு, நீங்கள் பேச்சுவார்த்தை நடத்தும் எந்த rate-ஐவிடவும் அதிக மதிப்புடையது. எந்த model-ஐ இயக்குவது என்பது தனியான கேள்வி. உங்கள் evaluations-ல் தேர்ச்சி பெறும் குறைந்த செலவிலான model-ஐத் தேர்ந்தெடுக்க வேண்டும்: Opus, Sonnet மற்றும் Haiku ஆகியவற்றுக்கு இடையே தேர்வு செய்தல் அதைச் சரியாகச் சோதிப்பது எப்படி என்பதை விளக்குகிறது.

Prompt caching மீண்டும் வரும் பகுதியைக் குறைக்கிறது

அந்த 4,000 token prefix ஒவ்வொரு request-லும் ஒரே மாதிரியாக உள்ளது. ஒவ்வொரு முறையும் அதற்கான முழு input விலையைச் செலுத்துகிறீர்கள். Prompt caching, process செய்யப்பட்ட prefix-ஐ சேமித்து, அதை மீண்டும் பயன்படுத்தும்போது குறைந்த rate-ஐ வசூலிக்கிறது.

ஒரு cache read-க்கு base input rate-ன் 0.1 மடங்கு செலவாகும். 5 minute lifetime-க்கு cache எழுதும் செலவு base rate-ன் 1.25 மடங்காகும். 1 hour lifetime-க்கு அது base rate-ன் 2 மடங்காகும். எனவே 5 minute cache, ஒரு read-க்குப் பிறகு தனது செலவை ஈடுசெய்கிறது. காரணம், எழுதுவதற்கு 0.25 கூடுதல் செலவாகிறது, ஒவ்வொரு read-லும் 0.9 சேமிக்கப்படுகிறது. 1 hour cache-க்கு break even ஆக 2 reads தேவை.

இதை இயக்குவதற்கான எளிய வழி, ஒரு 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?"}
    ]
  }'

திரும்ப வரும் usage block-ஐ பின்னர் படிக்கவும்:

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

இந்த 3 input counters, 3 வேறு rates-ல் bill செய்யப்படுகின்றன. அவற்றின் கூட்டுத்தொகையே உங்கள் உண்மையான input volume: total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Caching இயக்கப்பட்ட பிறகு input_tokens மட்டும் படிக்கும் cost estimate மிகவும் தவறாக இருக்கும்.

Cache மூலம் செலவு ஈடுசெய்யப்படாமல் போக 2 காரணங்கள் உள்ளன. இரண்டிலும் எந்த error-மும் வெளிப்படையாகத் தெரிவிக்காது.

Prefix byte-identical ஆக இருக்க வேண்டும். Cache lookup, prefix match அடிப்படையில் செயல்படுகிறது. எனவே system prompt-ன் தொடக்கத்தில் timestamp அல்லது user's name இருந்தால், அது ஒவ்வொரு request-லும் மாறும். அப்போது ஒவ்வொரு முறையும் base input rate-ன் 1.25 மடங்கு செலுத்துவீர்கள். ஒருமுறையும் read செய்யப்படாது. இதன் அறிகுறி cache_creation_input_tokens அதிகமாகவும், cache_read_input_tokens 0 ஆகவும் இருப்பதாகும். Requests அனைத்திலும் content ஒரே மாதிரியாக இருக்கும் கடைசி block-ல் cache_control-ஐ வைக்கவும். மாறக்கூடிய அனைத்தையும் அதன் பிறகு வைக்கவும். உங்கள் tools definitions-ஐ மாற்றினால், அவற்றுக்குக் கீழே உள்ள முழு cache invalid ஆகும். ஏனெனில் invalidation, tools, பின்னர் system, பின்னர் messages என்ற order-ல் கீழ்நோக்கி இயங்குகிறது.

Prefix போதுமான நீளமுடையதாக இருக்க வேண்டும். Cache செய்யக்கூடிய குறைந்தபட்ச நீளம் Opus 5-க்கு 512 tokens, Sonnet 5-க்கு 1,024 tokens, Haiku 4.5-க்கு 4,096 tokens ஆகும். அதைவிடக் குறுகிய prompt cache செய்யப்படாது. எந்த error-மும் திரும்ப வழங்கப்படாது. மேலுள்ள example-ல் உள்ள 4,000 token prefix, Sonnet 5-ல் cache செய்யப்படும். Haiku 4.5-ல் cache செய்யப்படாது. காரணம், 4,000 என்பது அந்த model-ன் minimum limit-க்குக் குறைவாகும். இரண்டு counters-மும் 0 ஆக இருந்தால், எதுவும் cache செய்யப்படவில்லை.

Batch processing rate-ஐ பாதியாகக் குறைக்கிறது

Batch API requests-ஐ asynchronous முறையில் process செய்கிறது. Input மற்றும் output இரண்டிற்கும் 50 percent discount வழங்கப்படுகிறது. மேலே உள்ள எடுத்துக்காட்டில், 1,000 requests-க்கான $12.60 என்பது $6.30 ஆகக் குறைகிறது. இந்த discount prompt caching உடனும் சேர்ந்து செயல்படுகிறது. எனவே, bulk work-ஐ இயக்க cached batch job மிகவும் குறைந்த செலவுடைய வழியாகும்.

இதற்குப் பதிலாக latency அதிகரிக்கும். ஒருவர் காத்திருக்க வேண்டிய எந்தச் செயலுக்கும் Batch பொருத்தமானது அல்ல. Overnight classification மற்றும் document backfills போன்ற பணிகளுக்கு இது பொருத்தமானது.

ஒரே உரையாடலுக்குள் chat செலவு ஏன் அதிகரிக்கிறது

API எந்த state-ஐயும் வைத்திருக்காது. எனவே ஒவ்வொரு turn-லும் client முழு உரையாடலையும் மீண்டும் அனுப்புகிறது. ஆகவே ஒரே chat-க்குள் token பயன்பாடு நேர்கோட்டில் அல்ல; உரையாடலின் நீளத்தின் வர்க்கத்துக்கு ஏற்ப அதிகரிக்கிறது.

ஒவ்வொரு turn-லும் சராசரியாக 500 tokens இருப்பதாகக் கொள்ளுங்கள். Turn 1-ல் 500 input tokens அனுப்பப்படும். Turn 2-ல் 1,000 அனுப்பப்படும். Turn 20-ல் 10,000 அனுப்பப்படும். இதை n(n+1)/2 என்ற கூட்டுத்தொகையுடன் கணக்கிட்டால், 20 turn கொண்ட உரையாடல் சுமார் 105,000 input tokens-ஐ அனுப்பியிருக்கும். ஆனால் transcript-ன் நீளம் 10,000 tokens மட்டுமே.

அதனால் ஒரு chat feature-ன் செலவு, அதன் transcript காட்டும் அளவைவிட அதிகமாக இருக்கும். நீண்ட threads-ல் நிலையான prefix-ஐ cache செய்வது அல்லது பழைய turns-ஐ சுருக்கமாக்குவது செலவை ஈடுகட்டும். tool calls-ஐ மீண்டும் மீண்டும் இயக்கும் agent-க்கும் இதே முறை இருக்கும்; மேலும் மோசமாக, ஒவ்வொரு tool result-உம் history-ல் தொடர்ந்து இருந்து, பின்னர் வரும் ஒவ்வொரு turn-லும் மீண்டும் அனுப்பப்படும். நீங்களே இயக்கும் agent-க்கு கடுமையான spending limit அமைப்பது இங்கு மிகவும் முக்கியம். ஏனெனில் இந்த அதிகரிப்பு தானாகவே நிகழ்கிறது; அதை யாரும் கண்காணிக்கவில்லை.

ஊகிப்பதற்கு முன் tokens எண்ணிக்கையை அறியுங்கள்

Word எண்ணிக்கையிலிருந்து token எண்ணிக்கையை கணக்கிடுவதை நிறுத்துங்கள். API இதை உங்களுக்காக எந்தக் கட்டணமும் இன்றி கணக்கிடுகிறது. இதற்கான rate limit, message உருவாக்குவதற்கான rate limit-இலிருந்து தனியாக உள்ளது.

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"
    }]
  }'

Response-ல் ஒரு field உள்ளது:

{ "input_tokens": 14 }

உங்கள் உண்மையான system prompt மற்றும் tool definitions-ஐ, பிரதிநிதித்துவ user message ஒன்றுடன் இதில் அனுப்புங்கள். பின்னர் கிடைக்கும் எண்ணை மேலே உள்ள cost function-ல் பயன்படுத்துங்கள். இந்த endpoint, message request பயன்படுத்தும் அதே body-ஐ ஏற்கிறது. எனவே images மற்றும் PDFs-ம் சரியாகக் கணக்கிடப்படும். இரண்டு கட்டுப்பாடுகள் முக்கியமானவை. இந்த எண்ணிக்கை ஒரு மதிப்பீடு மட்டுமே. இது billed figure-இலிருந்து சற்றே மாறக்கூடும். மேலும், நீங்கள் அனுப்பும் model-ன் tokenizer-ஐப் பயன்படுத்தியே இது அளவிடப்படுகிறது. ஆகவே உண்மையில் இயக்கப் போகும் model-ஐயே அனுப்புங்கள்.

Output tokens-ஐ முன்கூட்டியே எண்ண முடியாது, ஏனெனில் அவை இன்னும் உருவாகவில்லை. அவற்றை max_tokens மூலம் வரம்பிடுங்கள். பின்னர் live traffic-ல் usage.output_tokens இலிருந்து உண்மையான distribution-ஐ அளவிடுங்கள்.

கட்டணத்தில் சேரும் பிற அம்சங்கள்

மொத்தக் கட்டணத்தில் Tokens பெரும்பகுதியைக் கொண்டுள்ளன. சில உருப்படிகள் tokens அல்ல. அவை பலரையும் ஆச்சரியப்படுத்துகின்றன.

• ஒவ்வொரு request-லும் Tool definitions input tokens ஆக மாறுகின்றன. உங்கள் சொந்த schemas சேர்க்கப்படுவதற்கு முன்பே, tool use system prompt மட்டும் Opus 5-ல் 286 முதல் 406 tokens வரை சேர்க்கிறது. விரிவான tool descriptions பத்து இருந்தால், சிறிய prompt-ன் அளவு இரட்டிப்பாகலாம்.
• Web search-க்கு 1,000 searches-க்கு $10 கட்டணம் வசூலிக்கப்படுகிறது. Results context-க்குள் சேரும்போது அவை பயன்படுத்தும் tokens-க்கான கட்டணம் இதற்கு மேலாகும்.
• Web fetch தனியாக எந்தக் கட்டணத்தையும் சேர்க்காது. ஆனால் fetch செய்யப்பட்ட page input tokens ஆக மாறும். 100 kB documentation page ஒன்று தோராயமாக 25,000 tokens ஆகும்.
• Claude 4.6 மற்றும் அதற்குப் பிந்தைய பதிப்புகளில் inference_geo மூலம் US-only inference-ஐக் கோரினால், cache reads மற்றும் cache writes உட்பட ஒவ்வொரு token வகைக்கும் 1.1 multiplier பயன்படுத்தப்படும்.

API-யை வாங்குவது சரியான தேர்வா என்பது உங்கள் volume-ஐப் பொறுத்தது. குறிப்பிட்ட பயன்பாட்டு அளவுக்குக் கீழே, flat monthly plan நேரடியாகச் சிறந்ததாக இருக்கும். Claude subscription-உடன் API-யை ஒப்பிடும் பகுதி அந்த ஒப்பீட்டை உண்மையான எண்களுடன் செய்கிறது.

FAQ

Claude இல் 1M tokens-க்கான கட்டணம் எவ்வளவு?

இது model-ஐப் பொறுத்தது. மேலும் tokens, input-ஆக உள்ளனவா அல்லது output-ஆக உள்ளனவா என்பதையும் பொறுத்தது. August 2026 நிலவரப்படி, Claude Haiku 4.5 இல் ஒரு million input tokens-க்கான கட்டணம் $1. அறிமுக pricing-ன் கீழ் Claude Sonnet 5 இல் அது $2, Claude Opus 5 இல் $5. இந்த models ஒவ்வொன்றிலும் output-க்கான கட்டணம் input rate-ஐவிட ஐந்து மடங்கு. 1 September 2026 அன்று Sonnet 5-க்கான input கட்டணம் $3 ஆகவும், output கட்டணம் $15 ஆகவும் மாறும். Rates மாறக்கூடும். ஆகவே budget-இல் ஒரு தொகையை குறிப்பிடுவதற்கு முன், official pricing page-இல் அவற்றை உறுதிப்படுத்துங்கள்.

1M tokens என்பது 1M words-க்கு சமமா?

இல்லை. ஒரு token என்பது English-இல் தோராயமாக 4 characters அல்லது சுமார் 0.75 words ஆகும். எனவே one million tokens என்பது சுமார் 750,000 words. இந்த விகிதம் ஒரு வழிகாட்டி மட்டுமே. Code, JSON மற்றும் English அல்லாத languages ஆகியவை ஒவ்வொரு word-க்கும் அதிக tokens பயன்படுத்துகின்றன. Claude Opus 4.7 மற்றும் அதற்குப் பிந்தைய versions, Claude Sonnet 4.6 மற்றும் அதற்கு முந்தைய versions-ஐவிட ஒரே text-க்கு சுமார் 30 percent அதிக tokens உருவாக்கும் புதிய tokenizer-ஐப் பயன்படுத்துகின்றன. எனவே வெவ்வேறு model generations இடையே counts-ஐ நேரடியாகப் பயன்படுத்த முடியாது. நீங்கள் இயக்கத் திட்டமிட்டுள்ள model-ஐக் கொடுத்து, இலவச /v1/messages/count_tokens endpoint மூலம் அளவிடுங்கள்.

Prompt caching எப்போதும் பணத்தைச் சேமிக்குமா?

இல்லை. 5 minute cache write-க்கான கட்டணம் base input rate-ன் 1.25 மடங்கு. ஆகவே write செய்யப்பட்டும் ஒருபோதும் read செய்யப்படாத prefix-க்கு, அதை வழக்கமாக அனுப்புவதைவிட 25 percent அதிகம் செலவாகும். முதல் read-இலிருந்தே அது தனது செலவை ஈடுசெய்கிறது. இது இரண்டு வழிகளில் தோல்வியடையும். இரண்டுமே அமைதியாக நிகழும். Requests இடையே cached prefix மாறினால், lookup ஒருபோதும் பொருந்தாது, ஏனெனில் இது exact prefix match ஆகும். Prefix, model-ன் minimum cacheable length-ஐவிடச் சிறியதாக இருந்தாலும் எதுவும் cache செய்யப்படாது; error-ம் திரும்ப வழங்கப்படாது. Sonnet 5-இல் இந்த அளவு 1,024 tokens; Haiku 4.5-இல் 4,096 tokens. cache_creation_input_tokens மற்றும் cache_read_input_tokens இரண்டும் 0-ஐக் காட்டும்போது, cache எந்தப் பணியும் செய்யவில்லை.

எனது message count-ஐவிட bill ஏன் வேகமாக அதிகரித்தது?

ஒவ்வொரு turn-இலும் முழு conversation மீண்டும் அனுப்பப்படுவதால். Messages API எந்த state-ஐயும் வைத்திருக்காது. ஆகவே chat-ன் turn 20, முந்தைய 19 turns அனைத்தையும் மீண்டும் input-ஆகக் கொண்டிருக்கும். ஒவ்வொரு turn-மும் சராசரியாக 500 tokens கொண்டதாக இருந்தால், transcript-ன் நீளம் 10,000 tokens மட்டுமே இருந்தாலும், 20 turn conversation சுமார் 105,000 input tokens-ஐ அனுப்பும். ஒவ்வொரு tool result-உம் history-யில் தொடர்ந்து இருப்பதால், agent loops-மும் இதேபோல் செயல்படும். நிலையான prefix-ஐ cache செய்யுங்கள். அல்லது பழைய turns-ஐ summarise செய்து, அவற்றை request-இலிருந்து நீக்குங்கள்.