Claude API செலவு: Input மற்றும் Output tokens வேறுபாடு

Output tokens ஏன் அதிக செலவை ஏற்படுத்துகின்றன

தற்போதைய catalogue-ல் உள்ள அனைத்து Claude model-களிலும், output tokens-ன் விலை input tokens-ஐ விட ஐந்து மடங்கு அதிகமாக உள்ளது. கணக்கீட்டு முறை (computation shape) இதற்குக் காரணம். ஒரு prompt-ஐ வாசிப்பது என்பது model-ன் மீது செய்யப்படும் ஒரே ஒரு pass ஆகும். ஆனால், ஒரு பதிலை எழுதுவது என்பது ஒவ்வொரு token-க்கும் ஒரு pass ஆகும்; மேலும், ஒவ்வொரு pass-ம் அதற்கு முந்தைய pass முடிவடையும் வரை காத்திருக்க வேண்டும்.

விலைப் பட்டியலின் ஒவ்வொரு வரிசையிலும் இந்த விகிதம் ஒரே மாதிரியாகவே உள்ளது. எனவே, நீங்கள் தேர்ந்தெடுக்கும் model, உங்கள் கட்டணத்தில் output-ன் பங்களிப்பை மாற்றுவதில்லை. உங்கள் workload-ன் தன்மையே அதைத் தீர்மானிக்கிறது. 60,000 tokens-ஐ வாசித்து 800 tokens-ல் பதிலளிக்கும் ஒரு agent step, output-க்காக மிகக் குறைந்த செலவையே செய்கிறது. அதேசமயம், 2,000 tokens-ஐ வாசித்து 12,000 tokens-ஐ எழுதும் ஒரு drafting பணி, input-க்காக மிகக் குறைந்த செலவையே செய்கிறது. Anthropic-ன் ஆகஸ்ட் 2026 விலைப்பட்டியலின்படி, இந்த இரண்டு சூழல்களும் கீழே கணக்கிடப்பட்டுள்ளன.

Prefill ஒருமுறை மட்டுமே இயங்கும், Decoding ஒவ்வொரு token-க்கும் ஒருமுறை இயங்கும்

ஒரு inference server, கோரிக்கைகளை இரண்டு கட்டங்களாகக் கையாளுகிறது. இவை ஒவ்வொன்றிற்கும் வெவ்வேறு செலவுகள் உள்ளன. Prefill என்பது prompt-ஐ வாசிப்பதாகும். Decoding என்பது பதிலை எழுதுவதாகும்.

Prefill முழு prompt-ஐயும் ஒரே நேரத்தில் எடுத்துக்கொள்ளும். அனைத்து prompt token-களும் ஒரே forward pass-ல் network-க்குள் நுழைகின்றன. எனவே, attention மற்றும் feed-forward செயல்பாடுகள், ஆயிரக்கணக்கான token-களை உள்ளடக்கிய ஒரு சில பெரிய matrix பெருக்கல்களாக மாறுகின்றன. memory-லிருந்து model weights ஒருமுறை வாசிக்கப்படுவது முழு prompt-க்கும் போதுமானதாக இருக்கும். accelerator-ன் matrix units தொடர்ந்து இயங்கிக்கொண்டிருக்கும். இதனால், prefill என்பது compute-bound ஆகிறது: சிப் எவ்வளவு வேகமாகப் பெருக்கல்களைச் செய்கிறது என்பதே அதன் வரம்பு.

Decoding இந்த முறையில் இயங்க முடியாது, ஏனெனில் இரண்டாவது token, முதல் token-ஐச் சார்ந்தது. model உருவாக்கிய token, அடுத்த கட்டத்திற்கான input-ன் ஒரு பகுதியாக மாறுகிறது. எனவே, இந்த நிலைகளை ஒரே நேரத்தில் இயக்க முடியாது. ஒவ்வொரு output token-க்கும் தனித்தனி forward pass தேவைப்படுகிறது. ஒவ்வொரு pass-ம், ஒரு token-ஐ உருவாக்க, முழு model weights-ஐயும் high-bandwidth memory-யிலிருந்து வாசிக்க வேண்டும். இதனால் decoding என்பது memory-bound ஆகிறது: weights எவ்வளவு வேகமாக நகர்த்தப்படுகின்றன என்பதே அதன் வரம்பு, பெருக்கப்படும் வேகம் அல்ல. prefill-ன் போது ஒரு முழு prompt-ஐயும் வாசிக்கப் பயன்படுத்தப்பட்ட அதே weight traffic, decoding-ன் போது ஒரு token-ஐ மட்டுமே வழங்குகிறது.

Serving systems, batching மூலம் இதைச் சமாளிக்கின்றன. பல கோரிக்கைகள் ஒன்றாகச் சேர்ந்து decode செய்யப்படுகின்றன. இதனால், weights ஒருமுறை வாசிக்கப்படும்போது, batch-ல் உள்ள ஒவ்வொரு கோரிக்கைக்கும் ஒரு token கிடைக்கிறது. இதனால்தான் decoding செலவு குறைந்ததாக இருக்கிறது. இதிலும் memory-யே முக்கிய வரம்பாக உள்ளது. செயல்பாட்டில் உள்ள ஒவ்வொரு கோரிக்கையும் ஒரு KV cache-ஐ (key/value cache, இதுவரை உருவாக்கப்பட்ட ஒவ்வொரு token-க்கான attention state) வைத்திருக்கும். ஒவ்வொரு token உருவாக்கப்படும்போதும் இந்த cache வளரும். இது accelerator-ஐ நிரப்பும்போது, batch-ஐ மேலும் அதிகரிக்க முடியாது.

இவை எதுவும் உங்களுக்குத் துல்லியமான எண்ணைக் கொடுக்காது. 5x என்பதை ஒரு அளவிடப்பட்ட hardware விகிதமாகக் கருதக்கூடாது. இது Anthropic நிறுவனத்தால் நிர்ணயிக்கப்பட்ட ஒரு விலை, இந்த சமச்சீரற்ற தன்மையின் அடிப்படையில் இது அமைந்தது. நீங்கள் நீங்களாகவே சரிபார்க்கக்கூடிய விஷயம் அதன் திசை மட்டுமே, இதற்கு சுமார் ஒரு நிமிடம் ஆகும்.

உள்ளீடு மற்றும் வெளியீட்டு இடைவெளியை நீங்களே அளவிடுங்கள்

எந்தவொரு Ubuntu கணினியிலும் இந்த கருவிகளை நிறுவவும்:

sudo apt update && sudo apt install -y curl jq moreutils

இப்போது நீண்ட பதிலை எதிர்பார்க்கும் ஒரு சிறிய prompt-ஐ அனுப்பி, ஒவ்வொரு வரியும் வந்து சேர்ந்த நேரத்தை அதில் முத்திரையிடவும்.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
       "messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
  | ts -s '%.s'

ts -s கட்டளையானது ஒவ்வொரு வரியின் முன்னும் அது தொடங்கப்பட்டதிலிருந்து கடந்த வினாடிகளைச் சேர்க்கிறது. அந்த வெளியீட்டில் இரண்டு விஷயங்களைக் கவனிப்பது அவசியம். முதல் content_block_delta வரி என்பது உங்கள் முதல் token-ஐப் பெறுவதற்கான நேரம், அந்த நேரத்திற்குள்ளேயே அனைத்து prefill செயல்பாடுகளும் முடிந்துவிடும். அதற்குப் பிறகு வரும் ஒவ்வொரு வரியும் decoding-ன் ஒரு சிறிய படிநிலை ஆகும், மேலும் message_stop வரும் வரை நேர முத்திரைகள் அதிகரித்துக்கொண்டே இருக்கும்.

இப்போது இதன் வடிவத்தை மாற்றவும். ஒரு நீண்ட ஆவணத்தை prompt-ல் வைத்து, பதிலைச் சில token-களுக்குள் கட்டுப்படுத்தவும்.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "$(jq -n --rawfile doc ./long-document.txt \
       '{model:"claude-sonnet-5", max_tokens:16, stream:true,
         messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
  | ts -s '%.s'

குறுகிய prompt-ஐ விட இதில் முதல் delta அதிக நேரம் எடுக்கும், ஏனெனில் prefill செய்வதற்கு அதிகப்படியான உரையை அது படிக்க வேண்டியுள்ளது. அது வந்த பிறகு, பதில் மிக விரைவாக முடிந்துவிடும், ஏனெனில் decoding செய்வதற்குச் சில token-கள் மட்டுமே எஞ்சியிருக்கும். பல்லாயிரக்கணக்கான token-கள் உள்ளே சென்றாலும் கடிகாரம் மிகக் குறைவாகவே நகர்ந்திருக்கும். ஆனால் சில நூறு token-கள் வெளியே வரும்போது கடிகாரம் முழு நேரமும் ஓடியிருக்கும்.

streaming அல்லாத ஒவ்வொரு பதிலும் நீங்கள் கட்டணம் செலுத்த வேண்டிய எண்களுடன் முடிவடையும்.

{
  "usage": {
    "input_tokens": 41283,
    "output_tokens": 6,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

ஒவ்வொரு கோரிக்கையிலும் நான்கு புலங்களையும் (fields) log செய்யவும். output_tokens என்பது விரிவான சிந்தனையையும் உள்ளடக்கியது, எனவே பதிலளிக்கும் முன் சிந்திக்கும் ஒரு மாதிரி (model), அந்தச் சிந்தனைக்கும் வெளியீட்டு விகிதத்திலேயே கட்டணம் வசூலிக்கும். ஒரு prompt-ஐ அனுப்பும் முன்பே அதன் விலையை அறிய, POST /v1/messages/count_tokens அதே கோரிக்கை அமைப்பை ஏற்றுக்கொண்டு, மாதிரியை இயக்காமலேயே {"input_tokens": N}-ஐத் திருப்பித் தரும், இது இலவசமானது. API-ல் கட்டணம் இல்லாத பகுதி இது ஒன்று மட்டுமல்ல, உங்கள் முதல் திட்டத்திற்கான வரவு செலவுத் திட்டத்தைத் தீர்மானிக்கும் முன் Claude API-ல் எவற்றிற்கு கட்டணம் வசூலிக்கப்படுவதில்லை என்பதைச் சரிபார்ப்பது நல்லது.

ஆகஸ்ட் 2026 நிலவரப்படி ஒரு மில்லியன் tokens-க்கு Claude வசூலிக்கும் கட்டணங்கள்

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

கடைசி நெடுவரிசை என்பது input-ஆல் வகுக்கப்பட்ட output ஆகும், இது ஒவ்வொரு வரிசையிலும் 5 என்று காட்டுகிறது. Haiku 4.5, input-க்கு $1 மற்றும் output-க்கு $5 என கட்டணம் வசூலிக்கிறது. Opus 5, $5 மற்றும் $25 என வசூலிக்கிறது. மிகவும் விலையுயர்ந்த Fable 5, $10 மற்றும் $50 என வசூலிக்கிறது, மேலும் அந்த Fable 5 கட்டணங்கள் உங்களுக்கு எதை வழங்குகின்றன என்பதை முதல் வரிசையைத் தவிர்ப்பதற்கு முன்பே படிப்பது நல்லது. வரிசையில் மேலே செல்லும்போது, இரண்டு பக்கங்களும் ஒரே காரணியால் பெருக்கப்படுகின்றன, எனவே இது உங்கள் மொத்தத் தொகையை மாற்றுகிறது, ஆனால் input மற்றும் output விகிதத்தை அப்படியே வைத்திருக்கிறது.

Sonnet 5 இரண்டு முறை காட்டப்பட்டுள்ளது, ஏனெனில் அதன் அறிமுகக் கட்டணம் முடிவடைகிறது. 31 ஆகஸ்ட் 2026 வரை இது $2 மற்றும் $10 என வசூலிக்கிறது. 1 செப்டம்பர் 2026 முதல், $3 மற்றும் $15 என்ற நிலையான கட்டணம் பொருந்தும், இது இரண்டு பக்கங்களிலும் 50% அதிகம். கீழே உள்ள ஒவ்வொரு உதாரணமும் ஆகஸ்ட் மாதக் கட்டணத்தையே பயன்படுத்துகிறது.

கட்டணங்கள் மாறக்கூடியவை, எனவே அவற்றைச் சரிபார்க்க இது சரியான இடம் அல்ல. claude.com/pricing என்பதே உண்மையான ஆதாரமாகும். விலை மாற்றத்திற்குப் பிறகும் மாறாமல் இருப்பது அதன் கணக்கீட்டு முறை மட்டுமே.

விலைப் பட்டியலில் காட்டப்படாத ஒரு எச்சரிக்கை உள்ளது. Anthropic-ன் ஆவணங்களின்படி, Claude 4.7 மற்றும் அதற்குப் பிந்தைய மாடல்கள் புதிய tokenizer-ஐப் பயன்படுத்துகின்றன, இது Sonnet 4.6 மற்றும் அதற்கு முந்தைய மாடல்களை விட அதே உரைக்கு சுமார் 30% கூடுதல் tokens-ஐ உருவாக்குகிறது. ஒரு மில்லியன் tokens-க்கான விலையை மட்டும் வைத்து இரண்டு மாடல்களை ஒப்பிடுவது புதிய மாடலுக்கு சாதகமாகத் தோன்றும், ஏனெனில் அதே ஆவணம் புதிய மாடலில் அதிக tokens-ஆகக் கணக்கிடப்படுகிறது. ஒரு பணியை முடிப்பதற்கான செலவை வைத்து ஒப்பிடுங்கள், மேலும் நீங்கள் பயன்படுத்தத் திட்டமிட்டுள்ள மாடலில் உங்கள் உண்மையான prompts-ஐக் கணக்கிடுங்கள். ஒரு மில்லியன் Claude tokens என்பது உண்மையான உரையில் எவ்வளவு மதிப்புடையது என்பது நடைமுறையில் அந்த அளவு எப்படி இருக்கும் என்பதை விளக்குகிறது.

எப்போது output செலவு உங்கள் கட்டணத்தில் முதன்மையாகிறது?

Output-ன் விலை input-ஐ விட 5 மடங்கு அதிகமாக இருப்பதால், break-even புள்ளியை எளிதாகக் கணக்கிடலாம். உங்கள் input tokens-ஐ I என்றும், output tokens-ஐ O என்றும் வைத்துக்கொள்வோம். Input-க்கான செலவு I. Output-க்கான செலவு 5 மடங்கு O. 5 மடங்கு O என்பது I-ஐ விட அதிகமாக இருக்கும்போது, உங்கள் மொத்தச் செலவில் பாதிக்கும் மேல் output-க்குச் செல்கிறது. இது 5 input tokens-க்கு 1 output token என்ற விகிதமாகும்.

எனவே, உங்கள் prompt உங்கள் பதிலை விட ஐந்து மடங்கு நீளமாக இருந்தால், input-தான் அதிகச் செலவை ஏற்படுத்தும். அதற்கு குறைவாக இருந்தால், output-தான் அதிகச் செலவை ஏற்படுத்தும்.

[
  {
    "label": "100:1",
    "input_share_pct": 95.2,
    "output_share_pct": 4.8
  },
  {
    "label": "75:1",
    "input_share_pct": 93.75,
    "output_share_pct": 6.25
  },
  {
    "label": "20:1",
    "input_share_pct": 80,
    "output_share_pct": 20
  },
  {
    "label": "10:1",
    "input_share_pct": 66.7,
    "output_share_pct": 33.3
  },
  {
    "label": "5:1",
    "input_share_pct": 50,
    "output_share_pct": 50
  },
  {
    "label": "1:1",
    "input_share_pct": 16.7,
    "output_share_pct": 83.3
  },
  {
    "label": "1:6",
    "input_share_pct": 3.2,
    "output_share_pct": 96.8
  }
]

100:1 என்ற விகிதத்தில், output என்பது செலவில் 4.8% ஆகும்; அப்போது prompt-ஐக் குறைப்பது மட்டுமே பயனுள்ள வேலையாக இருக்கும். 5:1 என்ற விகிதத்தில் இரண்டு பக்கங்களும் சமமாக இருக்கும். 1:6 என்ற விகிதத்தில், output என்பது 96.8% ஆக இருக்கும், அப்போது prompt-ன் செலவு மிகச் சிறியதாகிவிடும். பெரும்பாலானோர் தங்கள் விகிதத்தைத் தவறாகவே கணிக்கிறார்கள், எனவே எதையும் மேம்படுத்துவதற்கு முன்பு உங்கள் logs-லிருந்து சரியான தரவை எடுக்கவும்.

ஏஜென்ட் பணிச்சுமை: நீண்ட உள்ளீடு, சுருக்கமான வெளியீடு

ஒரு retrieval agent செயல்பாட்டை எடுத்துக்கொள்வோம்: 60,000 tokens கொண்ட ஆவணங்கள் மற்றும் உரையாடல் வரலாறு உள்ளீடாக வழங்கப்பட்டு, 800 tokens கொண்ட பதில் பெறப்படுகிறது. இது 75:1 என்ற விகிதமாகும்; எழுதுவதற்கு முன்பு வாசிக்கும் எந்தவொரு செயல்பாட்டிற்கும் இது இயல்பானது.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.12,
    "output_cost": 0.008,
    "total_cost": 0.128
  },
  {
    "label": "Opus 5",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "Fable 5",
    "input_cost": 0.6,
    "output_cost": 0.04,
    "total_cost": 0.64
  }
]

ஒவ்வொரு model-லும் அந்த அழைப்பின் வெளியீடு 6.25% ஆகும், ஏனெனில் இந்த விகிதம் விலைப்பட்டியல் முழுவதும் நிலையானது. இந்த அழைப்பிற்கான கட்டணம் Opus 5-ல் $0.32, ஆகஸ்ட் மாத விலையின்படி Sonnet 5-ல் $0.128, மற்றும் Haiku 4.5-ல் $0.064 ஆகும். Opus 5-ல் ஒரு நாளைக்கு இத்தகைய 200 செயல்பாடுகள் நடந்தால், அதன் செலவு ஒரு நாளைக்கு $64 ஆகும்.

இந்தச் செலவுப் பிரிப்பைப் பார்த்தாலே, எங்கு சேமிக்க முடியும் என்பது தெளிவாகிவிடும். பதிலின் அளவை 800 tokens-லிருந்து 400 tokens-ஆகக் குறைப்பது, அழைப்பின் செலவில் சுமார் 3% மட்டுமே சேமிக்கும். ஆனால், prompt-லிருந்து தேவையற்ற 20,000 tokens-ஐ நீக்குவது, செலவில் மூன்றில் ஒரு பங்கைச் சேமிக்கும். எனவே, வாசிப்பு அதிகம் உள்ள ஏஜென்ட் செயல்பாடுகளில் வெளியீட்டின் அளவைக் குறைப்பது பெரிய பலனைத் தராது. coding agent-ன் tokens எங்கே செலவாகின்றன என்பது, அந்த prompt-ஐ நிரப்பும் காரணிகளை விரிவாக விளக்குகிறது.

பணிச்சுமை உருவாக்கம்: சுருக்கமான தூண்டுதல், நீண்ட வரைவு

இப்போது இதன் வடிவத்தை மாற்றலாம். 2,000 tokens கொண்ட ஒரு சுருக்கமான குறிப்பு, 12,000 tokens கொண்ட ஒரு வரைவு, அதாவது 1:6 என்ற விகிதம்.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.002,
    "output_cost": 0.06,
    "total_cost": 0.062,
    "batch_total_cost": 0.031
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.004,
    "output_cost": 0.12,
    "total_cost": 0.124,
    "batch_total_cost": 0.062
  },
  {
    "label": "Opus 5",
    "input_cost": 0.01,
    "output_cost": 0.3,
    "total_cost": 0.31,
    "batch_total_cost": 0.155
  },
  {
    "label": "Fable 5",
    "input_cost": 0.02,
    "output_cost": 0.6,
    "total_cost": 0.62,
    "batch_total_cost": 0.31
  }
]

வெளியீடு இந்த கட்டணத்தில் 96.8% ஆகும். Opus 5 ஒரு வரைவுக்கு $0.31 செலவாகிறது, அதே சமயம் Haiku 4.5-ல் $0.062 மட்டுமே செலவாகிறது. இந்த ஐந்து மடங்கு வித்தியாசம் பெரும்பாலும் வெளியீட்டுப் பக்கத்திலிருந்தே வருகிறது, அங்குதான் மலிவான மாதிரி உங்களுக்கு அதிக சேமிப்பைத் தருகிறது.

கடைசி நெடுவரிசை Batch API மூலம் செய்யப்படும் அதே பணியைக் குறிக்கிறது, இது உள்ளீடு மற்றும் வெளியீட்டுச் செலவில் 50% குறைக்கிறது. Opus 5 ஒரு வரைவுக்கு $0.155 ஆகக் குறைகிறது. Batch முறை முடிவுகளை உடனடியாகத் தராமல் 24 மணி நேரத்திற்குள் வழங்குகிறது, எனவே இது இரவு நேர அறிக்கை உருவாக்கம் மற்றும் மொத்த வகைப்பாட்டிற்கு (bulk classification) ஏற்றது. ஒருவர் அமர்ந்து காத்திருக்கும் எந்தவொரு பணிக்கும் இது பொருந்தாது.

ஏஜென்ட் நிலையில் கிடைக்காத வகையில், மாதிரி ரூட்டிங் (model routing) இங்கே பயன் தருகிறது. பணியின் விரிவான பகுதி இயந்திரத்தனமானதாக இருந்தால், அதாவது உரையை மறுவடிவமைப்பது அல்லது நீங்கள் ஏற்கனவே அங்கீகரித்த ஒரு வரைபடத்தை விரிவுபடுத்துவது போன்ற பணிகளுக்கு, மலிவான மாதிரி அந்த tokens-ஐ ஐந்தில் ஒரு பங்கு விலையில் உருவாக்குகிறது. Opus, Sonnet மற்றும் Haiku ஆகியவற்றிற்கு இடையே தேர்ந்தெடுப்பது தரம் எந்த அளவில் அமைகிறது என்பதை விளக்குகிறது.

Input caching தள்ளுபடிகள், உள்ளீட்டிற்கு மட்டுமே

Prompt caching என்பது உங்கள் prompt-ன் ஒரு பகுதியை server-ல் சேமித்து வைத்து, அதை மீண்டும் படிக்கும்போது சாதாரண input கட்டணத்தில் ஒரு பகுதியை மட்டும் வசூலிக்கும் முறையாகும். ஆகஸ்ட் 2026 நிலவரப்படி, 5 நிமிட cache-ஐ எழுத அடிப்படை input கட்டணத்தை விட 1.25 மடங்கு, 1 மணிநேர cache-ஐ எழுத 2 மடங்கு, மற்றும் cache hit-ஐ படிக்க 0.1 மடங்கு என கட்டண விகிதங்கள் உள்ளன.

Output இந்த சலுகையில் அடங்காது. Cached output என்று எதுவும் இல்லை. Prompt-ன் எவ்வளவு பகுதி cache hit மூலம் வந்தாலும், model எழுதும் ஒவ்வொரு token-க்கும் முழுமையான output கட்டணமே ஒவ்வொரு முறையும் வசூலிக்கப்படும்.

Opus 5-ல் அதே agent செயல்பாட்டை எடுத்துக்கொள்வோம்; இதில் 60,000 input tokens-ல் 55,000 tokens warm cache-லிருந்து பெறப்படுகின்றன.

[
  {
    "label": "No cache",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "55k prefix cache read",
    "input_cost": 0.0525,
    "output_cost": 0.02,
    "total_cost": 0.0725
  }
]

இந்த அழைப்பிற்கான கட்டணம் $0.32-லிருந்து $0.0725 ஆகக் குறைகிறது. Output வரிசையில் எந்த மாற்றமும் இல்லை: முன்னதாக $0.02, பிறகு $0.02. Caching கட்டணத்தைக் குறைப்பதோடு அதன் கட்டமைப்பையும் மாற்றுகிறது. அந்த அழைப்பில் output என்பது 6.25% ஆக இருந்தது. இப்போது அது கால் பகுதிக்கும் மேலாக உயர்ந்துள்ளது, இது அடுத்து எந்த அம்சத்தில் கவனம் செலுத்த வேண்டும் என்பதை மாற்றுகிறது.

முதல் அழைப்பு எழுதுவதற்கான (write) கட்டணத்தைச் செலுத்துகிறது. 5 நிமிட cache write என்பது அடிப்படை input கட்டணத்தை விட 1.25 மடங்கு என்பதால், ஒரே ஒரு hit-க்கு பிறகு அது தனக்கான செலவை ஈடுசெய்துவிடும். 1 மணிநேர write என்பது 2 மடங்கு என்பதால், அதற்கு இரண்டு hit-கள் தேவை. எழுதுதல் மற்றும் படித்தலுக்கான பெருக்கிகள், மற்றும் caching எப்போது லாபகரமாக இருக்காது என்பது அந்த கணக்கீடுகளை விளக்குகிறது.

நீங்கள் கட்டுப்படுத்தக்கூடிய நான்கு காரணிகள்

1. max_tokens-ஐ மாடலின் அதிகபட்ச அளவிலன்றி, உங்கள் p95 வெளியீட்டு நீளத்தில் அமைக்கவும்.
2. விரிவான விளக்கங்களை மலிவான மாடலுக்கு மாற்றவும் (Route).
3. யாருடைய காத்திருப்புக்கும் அவசியமில்லாத பணிகளை Batch செய்யவும்.
4. பதிலின் அளவை அதிகரிக்கும் தேவையற்ற அறிவுறுத்தல்களை நீக்கவும்.

max_tokens என்பது ஒரு கடினமான உச்சவரம்பு (hard ceiling). இதை அதிகமாக வைப்பதால் மட்டும் செலவு அதிகரிக்காது, ஏனெனில் நீங்கள் உருவாக்கும் டோக்கன்களுக்கு மட்டுமே கட்டணம் வசூலிக்கப்படுகிறது, உச்சவரம்பிற்கு அல்ல. தாராளமான உச்சவரம்பு, பதில் தவறாக அமையும் போது ஏற்படும் தடைகளை நீக்குகிறது. உங்கள் லாக்-களிலிருந்து output_tokens பரவலை எடுத்து, p95 சதவீதத்திற்குச் சற்று மேலே உச்சவரம்பை அமைக்கவும். stop_reason: "max_tokens" சிக்கல்களை, பதிலை மீண்டும் தொடர்வதன் மூலமோ அல்லது மீண்டும் முயற்சிப்பதன் மூலமோ குறியீட்டில் (code) கையாளவும். நீங்கள் கண்டறியும் ஒரு வெட்டுதல் (truncation), நீங்கள் பணம் செலுத்திப் பயன்படுத்தாத 4,000 டோக்கன் நீளமுள்ள தேவையற்ற உரையை விடக் குறைவான செலவையே ஏற்படுத்தும். நீண்ட நேரச் சிந்தனை (Extended thinking) output_tokens-ல் சேர்வதால், அதே ஆதாரங்களைக் கொண்டு அதற்கான பட்ஜெட்டையும் முடிவு செய்யவும்.

ஒரு பணியின் கடினமான பகுதி அதன் தீர்ப்பை விட அதன் அளவாக இருக்கும்போது, Routing சிறப்பாகச் செயல்படும். முடிவெடுக்கும் பணியை வலிமையான மாடலிடம் வைத்துவிட்டு, தட்டச்சு செய்யும் பணியை மலிவான மாடலிடம் ஒப்படைக்கவும். மாற்றப்பட்ட பதிப்பை முதலில் உங்கள் சொந்த மதிப்பீட்டுத் தொகுப்பில் (evaluation set) சோதிக்கவும், ஏனெனில் இரண்டு முறை முயற்சி செய்ய வேண்டிய மலிவான மாடல், ஒருமுறை முயற்சி செய்யும் விலையுயர்ந்த மாடலை விட அதிக செலவை ஏற்படுத்தும்.

வெளியீட்டுச் செலவைக் குறைக்கும் ஒரே வழி Batching மட்டுமே. இது இருபுறமும் 50% தள்ளுபடியைத் தருகிறது, 24 மணி நேரத்திற்குள் முடிவுகளைப் பெறலாம், மேலும் அட்டவணைப்படுத்தப்பட்ட எந்தவொரு பணியும் இதற்குத் தகுதியானது.

கடைசி காரணிதான் பலரால் தவிர்க்கப்படுகிறது. "விரிவாக இருங்கள்" (be thorough) மற்றும் "உங்கள் காரணங்களை விளக்குங்கள்" (explain your reasoning) போன்ற சொற்றொடர்கள், நீங்கள் செய்யும் ஒவ்வொரு அழைப்பிலும் வெளியீட்டு நீளத்தை அதிகரிக்கின்றன. அவற்றுக்குப் பதிலாக உங்களுக்குத் தேவையான வடிவத்தைப் பயன்படுத்தவும்: "மூன்று வாக்கியங்களுக்கு மிகாமல் பதிலளிக்கவும்" அல்லது "முன்னுரை இன்றி JSON ஆப்ஜெக்ட்டை மட்டும் வழங்கவும்". ஒவ்வொரு பதிலிலும் 300 டோக்கன்களைச் சேர்க்கும் ஒரு system prompt, அதே 300 டோக்கன்களை prompt-ல் பயன்படுத்துவதை விட ஐந்து மடங்கு அதிக செலவை ஏற்படுத்தும். இயங்கும் ஏஜெண்டின் செலவைக் கட்டுக்குள் வைத்திருத்தல் கண்காணிப்புப் பகுதியை உள்ளடக்கியது, மேலும் உங்கள் பயன்பாட்டு முறைக்கு API அல்லது flat subscription எது மலிவானது என்பதை, ஒரு வார கால டோக்கன் செலவு மேம்பாட்டிற்கு முன்பே முடிவு செய்வது நல்லது. ஒரு டெவலப்பருக்கு, இது பெரும்பாலும் Claude Pro-வின் $20 மாதக் கட்டணம் மற்றும் அதன் பயன்பாட்டு வரம்புகள் உங்கள் பணிகளை ஈடுசெய்கிறதா என்பதைப் பொறுத்தது. நீங்கள் ஏற்கனவே அந்த வரம்புகளைத் தொடுகிறீர்கள் என்றால், எந்த விண்டோவிற்காக நீங்கள் காத்திருக்கிறீர்கள் என்பதைக் கண்டறிவது முதலில் முக்கியம். ஏனெனில், சிறிய மாடல், குறைந்த context, கூடுதல் usage credits அல்லது அந்தப் பணியை metered API-க்கு மாற்றுவது போன்ற தீர்வுகள் அங்கிருந்துதான் தொடங்கும். அந்தப் பணிக்கு metered API மலிவானது எனத் தெரிந்தால், சிறிய திட்டத்திற்கு மாறுவது அல்லது ரத்து செய்வது நீங்கள் ஏற்கனவே செலுத்திய மாதக் கட்டணத்தைப் பாதிக்காது, எனவே மாறுதலில் உங்களுக்கு இழப்பு ஏதுமில்லை. நீங்கள் ஒப்பிடும் திட்டம் metered API-க்கு பதிலாக ChatGPT-யாக இருந்தால், இரண்டு சந்தா முறைகளையும் அருகருகே ஒப்பிடுவது கோடிங் பணிகளுக்கு எது மலிவானது என்பதைக் காட்டும். ஒரு டெவலப்பருக்குப் பதிலாக ஒரு குழுவிற்காக இந்தக் கேள்வி கேட்கப்பட்டால், Claude Enterprise ஒவ்வொரு இருக்கைக்கும் கட்டணம் மற்றும் இதே API விகிதத்தில் டோக்கன் கட்டணத்தை வசூலிக்கிறது என்பதை நினைவில் கொள்க. எனவே, இந்தப் பக்கத்தில் உள்ள அனைத்துக் காரணிகளும் அந்தப் பில்லின் metered பகுதிக்கும் பொருந்தும்.

FAQ

வெளியீட்டு டோக்கன்கள் (output tokens) ஏன் உள்ளீட்டு டோக்கன்களை விட அதிக விலை கொண்டவை?

அவற்றை உருவாக்குவதற்கு, ஒரு டோக்கனுக்கு அதிகப்படியான accelerator நேரம் தேவைப்படுகிறது. ஒரு prompt முழுமையாக ஒரே forward pass-ல் செயலாக்கப்படுகிறது; எனவே, model weights ஒருமுறை மட்டுமே வாசிக்கப்படுகிறது மற்றும் வன்பொருள் (hardware) multiply throughput-ஆல் கட்டுப்படுத்தப்படுகிறது. ஆனால், ஒரு பதில் ஒவ்வொரு டோக்கனாகவே உருவாக்கப்படுகிறது. ஒவ்வொரு டோக்கனுக்கும் தனித்தனி forward pass தேவைப்படுவதால், முழு model weights மீண்டும் மீண்டும் வாசிக்கப்பட வேண்டும். இதனால் வன்பொருள் memory bandwidth-ஆல் கட்டுப்படுத்தப்படுகிறது. Anthropic, Haiku 4.5 முதல் Fable 5 வரையிலான தற்போதைய முழு பட்டியலிலும், வெளியீட்டு விலையை உள்ளீட்டு விலையை விட ஐந்து மடங்கு அதிகமாக நிர்ணயித்துள்ளது.

Prompt caching வெளியீட்டு டோக்கன்களை மலிவாக்குமா?

இல்லை. Prompt caching உள்ளீட்டிற்கு மட்டுமே பொருந்தும். ஆகஸ்ட் 2026 நிலவரப்படி, cache read என்பது அடிப்படை உள்ளீட்டு விலையில் 0.1x ஆகும். 5 நிமிட காலத்திற்கு cache write என்பது 1.25x ஆகவும், 1 மணிநேர காலத்திற்கு 2x ஆகவும் இருக்கும். cache என்ன செய்தாலும், வெளியீடு ஒவ்வொரு அழைப்பிலும் முழு விலையிலேயே கணக்கிடப்படும். இதனால்தான் caching உங்கள் கட்டணத்தின் அளவை மட்டுமல்லாமல் அதன் வடிவத்தையும் மாற்றுகிறது: உள்ளீட்டுச் செலவு குறையும்போது, வெளியீட்டுச் செலவு உங்கள் கட்டணத்தில் முக்கியப் பங்காக மாறுகிறது.

பதில் சுருக்கமாக வரும்போது, அதிக max_tokens எனக்கு அதிக செலவை ஏற்படுத்துமா?

இல்லை. model உண்மையில் உருவாக்கும் டோக்கன்களுக்கு மட்டுமே நீங்கள் கட்டணம் செலுத்துகிறீர்கள். எனவே max_tokens என்பது ஒரு உச்சவரம்பு (ceiling) மட்டுமே, அது முன்பதிவு (reservation) அல்ல. இது முக்கியமானது, ஏனெனில் கட்டுப்பாடின்றி நீளும் பதிலைத் தடுக்கும் ஒரே கடினமான வரம்பு இதுவே. உங்கள் அவதானிப்பில் உள்ள output_tokens-ன் 95-வது சதவீதத்திற்கு சற்று மேலே இதை அமைக்கவும். பின்னர், பதிலைத் தானாகவே பாதியில் துண்டிப்பதற்குப் பதிலாக, stop_reason: "max_tokens"-ஐ உங்கள் code-ல் கையாளவும்.

எனது உள்ளீடு மற்றும் வெளியீட்டு டோக்கன் விகிதத்தை நான் எவ்வாறு கண்டறிவது?

ஒவ்வொரு response-லும் உள்ள usage object-லிருந்து input_tokens, output_tokens, cache_read_input_tokens மற்றும் cache_creation_input_tokens ஆகியவற்றை log செய்யவும். பின்னர் ஒரு வாரத்திற்கான மொத்த எண்ணிக்கையை வகுக்கவும். 1 வெளியீட்டிற்கு 5 உள்ளீடு என்ற விகிதத்திற்கு மேல் இருந்தால், உங்கள் செலவு prompt-ல் உள்ளது; எனவே மாறாத பகுதியை cache செய்து, மீதமுள்ளவற்றைச் சுருக்கவும். அதற்கு குறைவாக இருந்தால், உங்கள் செலவு பதிலில் உள்ளது; எனவே அதன் நீளத்தைக் கட்டுப்படுத்தி, அதிக டோக்கன்களை உருவாக்கும் படிகளை மலிவான model-க்கு அல்லது Batch API-க்கு மாற்றவும்.