Claude 1M tokens விலை எவ்வளவு? முழுமையான கணக்கீடு

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

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

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

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

1M tokens என்பது எவ்வளவு

Token என்பது ஒரு model வாசிக்கும் அல்லது எழுதும் உரையின் ஒரு பகுதி. Anthropic-ன் தோராயமான வழிகாட்டுதலின்படி, 4 எழுத்துக்களுக்கு ஒரு token, அல்லது ஆங்கிலத்தில் சுமார் 0.75 வார்த்தைகள் ஒரு token ஆகும். எனவே, ஒரு மில்லியன் tokens என்பது சுமார் 750,000 வார்த்தைகள் அல்லது ஏறத்தாழ 4 MB plain text ஆகும்.

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

[
  {
    "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 சராசரி இணையப் பக்கங்களை ஒருமுறை வாசிப்பதற்குச் சமம், அல்லது அந்த அளவுள்ள எட்டு ஆய்வுக்கட்டுரைகளுக்குச் சமம். இது நடுத்தர அளவிலான codebase-ஐ ஒருமுறை முழுமையாகப் பார்ப்பது அல்லது ஒரு நபர் ஒரு மாதம் மிதமான அளவில் chat பயன்படுத்துவதற்குச் சமம்.

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

ஒரு மில்லியன் 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 முதல், standard கட்டணம் அமலுக்கு வரும்: input-க்கு $3 மற்றும் output-க்கு $15. Claude Opus 5-ன் கட்டணம் input-க்கு $5 மற்றும் output-க்கு $25 ஆகும்.

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

கட்டணத்தை மாற்றாத ஒரு அம்சம் context length ஆகும். Claude 4.6 மற்றும் அதற்குப் பிந்தைய பதிப்புகளில், முழுமையான 1M token context window-ம் standard விலையிலேயே கணக்கிடப்படுகிறது. எனவே, 900,000 token கொண்ட கோரிக்கையும் 9,000 token கொண்ட கோரிக்கையும் ஒரே token விலையையே கொண்டிருக்கும். நீண்ட prompt-க்கு அதிக tokens இருப்பதால் அதற்கான செலவு அதிகமாகுமே தவிர, நீண்ட context-க்கெனத் தனிப்பட்ட கட்டண விகிதம் எதுவும் இல்லை.

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

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

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

நீங்கள் இயக்கக்கூடிய குறியீடாக எழுதினால்:

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-ஐப் பெறும் ஒரு கோரிக்கைக்கு, Sonnet 5-ல் சுமார் 1.3 cents செலவாகும். இரண்டு கட்டண விகிதங்களையும் உங்கள் குறியீட்டில் ஒரே இடத்தில் வைத்திருங்கள். விலை மாறும்போது, இரண்டு வரிகளை மட்டும் திருத்தினால் போதும்; உங்கள் கணினியில் உள்ள அனைத்து மதிப்பீடுகளும் அதற்கேற்ப தானாகவே மாறிவிடும்.

ஒரு உண்மையான செயலிக்கான மதிப்பீடு

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

ஒரு மில்லியன் input tokens மூலம் இத்தகைய 232 கோரிக்கைகளைச் செய்ய முடியும். ஒரு நாளைக்கு 1,000 கோரிக்கைகள் எனில், அந்த செயலி தினமும் 4.3 மில்லியன் 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 கோரிக்கைகளுக்கு $31.50 செலவாகும். Sonnet 5-ல் இது $12.60 ஆகும். Claude Haiku 4.5-க்கு மாறினால் இது $6.30 ஆகக் குறையும். Sonnet 5-ல் warm prompt cache-ஐப் பயன்படுத்தினால், செலவு இன்னும் குறைந்து $5.40 ஆக இருக்கும்.

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

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

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

Cache read என்பது அடிப்படை input கட்டணத்தில் 0.1 மடங்கு ஆகும். Cache write கட்டணம், 5 நிமிட ஆயுட்காலத்திற்கு அடிப்படை கட்டணத்தைப் போல 1.25 மடங்கும், 1 மணிநேர ஆயுட்காலத்திற்கு 2 மடங்கும் ஆகும். எனவே, 5 நிமிட cache ஒருமுறை வாசித்தாலே அதன் செலவை ஈடுகட்டிவிடும்; ஏனெனில் write செய்யும்போது 0.25 கூடுதல் செலவாகும், ஆனால் ஒவ்வொரு read-லும் 0.9 சேமிக்கப்படுகிறது. 1 மணிநேர cache அதன் செலவை ஈடுகட்ட இரண்டு முறை வாசிக்கப்பட வேண்டும்.

இதைச் செயல்படுத்துவதற்கான எளிமையான வழி, ஒரு ஒற்றை 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 தொகுதியை வாசிக்கவும்:

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

அந்த மூன்று input counters-ம் மூன்று வெவ்வேறு விகிதங்களில் கட்டணம் வசூலிக்கப்படுகின்றன, அவை உங்கள் உண்மையான input அளவைக் குறிக்கின்றன: total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. input_tokens-ஐ மட்டும் வாசிக்கும் ஒரு செலவு மதிப்பீடு, caching செயல்பாட்டில் இருக்கும்போது தவறான முடிவைத் தரும்.

இரண்டு காரணங்கள் cache-ன் பலனைத் தடுக்கின்றன, இவை இரண்டும் எந்த எச்சரிக்கையும் இன்றி தோல்வியடையும்.

Prefix கண்டிப்பாக byte-identical ஆக இருக்க வேண்டும். Cache lookup என்பது ஒரு prefix பொருத்தம் (prefix match) ஆகும், எனவே உங்கள் system prompt-ன் தொடக்கத்தில் உள்ள ஒரு timestamp அல்லது பயனரின் பெயர் ஒவ்வொரு கோரிக்கையிலும் அதை மாற்றிவிடும். அப்போது நீங்கள் ஒவ்வொரு முறையும் அடிப்படை input கட்டணத்தைப் போல 1.25 மடங்கு செலுத்துவீர்கள், ஆனால் ஒருமுறை கூட cache-ஐ வாசிக்க மாட்டீர்கள். இதன் அறிகுறி என்னவென்றால், cache_creation_input_tokens அதிகமாக இருக்கும் அதே வேளையில் cache_read_input_tokens பூஜ்ஜியமாகவே இருக்கும். cache_control-ஐ அனைத்து கோரிக்கைகளிலும் மாறாமல் இருக்கும் கடைசித் தொகுதியில் வைக்கவும், மாறுபடும் அனைத்தையும் அதற்குப் பிறகு வைக்கவும். உங்கள் tools வரையறைகளை மாற்றினால், அதற்கு கீழே உள்ள முழு cache-ம் செல்லாததாகிவிடும், ஏனெனில் invalidation என்பது tools, பிறகு system, பிறகு messages என்ற வரிசையில் நடக்கும்.

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

Batch processing விகிதத்தை பாதியாகக் குறைக்கிறது

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

இதில் நீங்கள் இழப்பது latency ஆகும், எனவே பயனர் காத்திருக்கும் எந்தவொரு செயலுக்கும் batch முறை பொருத்தமற்றது. இது இரவு நேர வகைப்படுத்துதல் (classification) மற்றும் ஆவணங்களை மீண்டும் நிரப்புதல் (document backfills) போன்ற பணிகளுக்கு மிகவும் ஏற்றது.

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

API எந்தவொரு நிலையையும் (state) சேமித்து வைப்பதில்லை என்பதால், ஒவ்வொரு முறையும் உங்கள் client முழு உரையாடலையும் மீண்டும் அனுப்புகிறது. எனவே, ஒரு chat-ல் token பயன்பாடு நேர்க்கோட்டில் இல்லாமல், அதன் நீளத்தின் வர்க்கத்திற்கு (square) ஏற்ப அதிகரிக்கிறது.

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

இதனால்தான், ஒரு chat வசதியின் செலவு அதன் உரையாடல் நீளத்தை விட அதிகமாக இருக்கிறது. நீண்ட உரையாடல்களில், மாறாத முன்னொட்டுகளை (stable prefix) cache செய்வதோ அல்லது பழைய சுற்றுகளைச் சுருக்கி (summarising) வைப்பதோ செலவைக் குறைக்க உதவும். tool calls-களைத் திரும்பத் திரும்பச் செய்யும் ஒரு agent-க்கும் இதே நிலைதான், இன்னும் மோசமாக: ஒவ்வொரு tool-ன் முடிவும் வரலாற்றில் தங்கி, அடுத்தடுத்த சுற்றுகளில் மீண்டும் அனுப்பப்படும். நீங்கள் இயக்கும் ஒரு agent-க்கு கடுமையான செலவு வரம்பை (spending limit) நிர்ணயிப்பது இங்கு மிக முக்கியமானது, ஏனெனில் இந்த வளர்ச்சி தானாகவே நடக்கும் மற்றும் யாரும் அதைக் கவனிப்பதில்லை.

Token-களைக் கணக்கிடுதல்

வார்த்தைகளின் எண்ணிக்கையை வைத்து token-களைக் கணக்கிடுவதைத் தவிர்க்கவும். API உங்களுக்காகவே இதை இலவசமாகக் கணக்கிடுகிறது; இது 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 மற்றும் PDF-களும் சரியாகவே கணக்கிடப்படும். இதில் இரண்டு விஷயங்களைக் கவனத்தில் கொள்ள வேண்டும். இந்த எண்ணிக்கை ஒரு தோராயமான மதிப்பீடு மட்டுமே; இது billing தொகையிலிருந்து சற்று மாறுபடலாம். மேலும், இது நீங்கள் பயன்படுத்தும் model-ன் tokenizer-ஐக் கொண்டே அளவிடப்படுகிறது, எனவே நீங்கள் உண்மையில் பயன்படுத்தப்போகும் model-ஐயே குறிப்பிடவும்.

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

கட்டணத்தில் வேறு என்னென்ன அடங்கும்

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

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

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

FAQ

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

இது நீங்கள் பயன்படுத்தும் model மற்றும் tokens உள்ளீடா (input) அல்லது வெளியீடா (output) என்பதைப் பொறுத்தது. ஆகஸ்ட் 2026 நிலவரப்படி, ஒரு மில்லியன் input tokens-க்கு Claude Haiku 4.5-ல் $1-ம், அறிமுக விலையில் Claude Sonnet 5-ல் $2-ம், Claude Opus 5-ல் $5-ம் செலவாகும். ஒவ்வொரு model-லும் output செலவு, input விலையை விட ஐந்து மடங்கு அதிகம். செப்டம்பர் 1, 2026 முதல் Sonnet 5-ன் விலை input-க்கு $3 மற்றும் output-க்கு $15 என மாறும். கட்டணங்கள் மாறக்கூடும் என்பதால், பட்ஜெட் திட்டமிடுவதற்கு முன் அதிகாரப்பூர்வ விலை நிர்ணயப் பக்கத்தில் (pricing page) உறுதிப்படுத்திக் கொள்ளவும்.

1M tokens என்பது 1M வார்த்தைகளுக்குச் சமமா?

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

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

இல்லை. 5 நிமிட cache write, அடிப்படை input விலையை விட 1.25 மடங்கு செலவாகும். எனவே, ஒரு prefix-ஐ எழுதி அதை ஒருமுறை கூட பயன்படுத்தவில்லை என்றால், சாதாரணமான முறையில் அனுப்புவதை விட 25 சதவீதம் கூடுதல் செலவாகும். முதல் முறை வாசிக்கும்போதே இது லாபகரமாகிவிடும். இது இரண்டு வழிகளில் தோல்வியடையும், ஆனால் எந்த எச்சரிக்கையும் வராது. கோரிக்கைகளுக்கு இடையே cached prefix மாறினால், அது துல்லியமான prefix பொருத்தம் (exact prefix match) என்பதால் lookup தோல்வியடையும். prefix-ன் நீளம், model-ன் குறைந்தபட்ச cacheable அளவை விடக் குறைவாக இருந்தால் (Sonnet 5-க்கு 1,024 tokens, Haiku 4.5-க்கு 4,096 tokens), எதுவும் cache செய்யப்படாது, எந்த பிழையும் காட்டப்படாது. cache_creation_input_tokens மற்றும் cache_read_input_tokens ஆகிய இரண்டும் 0 என இருந்தால், cache எந்த வேலையும் செய்யவில்லை என்று அர்த்தம்.

செய்திகளின் எண்ணிக்கையை விட எனது கட்டணம் ஏன் வேகமாக அதிகரித்தது?

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