Claude Input vs Output Tokens கட்டண வேறுபாடு

Output tokens-க்கு Input tokens-ஐ விட ஏன் அதிக கட்டணம்

தற்போதைய catalogue-ல் உள்ள ஒவ்வொரு Claude model-லும் Output tokens-க்கான கட்டணம், Input tokens-க்கான கட்டணத்தை விட ஐந்து மடங்கு அதிகம். இதற்குக் காரணம் computation-ன் அமைப்பாகும். Prompt-ஐ படிப்பது model மீது ஒரே pass ஆகும். Reply-ஐ எழுதும்போது ஒவ்வொரு token-க்கும் ஒரு pass தேவைப்படும். ஒவ்வொரு pass-மும் அதற்கு முந்தைய pass முடியும் வரை காத்திருக்க வேண்டும்.

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

Prefill ஒருமுறை இயங்கும்; decoding ஒவ்வொரு token-க்கும் ஒருமுறை இயங்கும்

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

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

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

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

இவற்றில் எதுவும் உங்களுக்கு exact number-ஐ வழங்காது. 5x என்பது அளவிடப்பட்ட hardware ratio என்று கருதக்கூடாது. அது Anthropic நிர்ணயித்த விலை. இந்த prefill மற்றும் decoding asymmetry-யை அடிப்படையாகக் கொண்டு அந்த விலை அமைக்கப்பட்டுள்ளது. நீங்களே சரிபார்க்கக்கூடியது அதன் திசை மட்டுமே. அதற்கு சுமார் ஒரு நிமிடம் போதும்.

Input மற்றும் output gap-ஐ நீங்களே அளவிடுங்கள்

எந்த Ubuntu box-லாவது இந்த tools-ஐ install செய்யுங்கள்:

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

இப்போது நீண்ட பதிலைக் கேட்கும் ஒரு குறுகிய prompt-ஐ stream செய்யுங்கள். வந்த ஒவ்வொரு line-க்கும் அது வந்த நேரத்தைப் பதிவு செய்யுங்கள்.

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 ஒவ்வொரு line-ன் தொடக்கத்திலும் command தொடங்கியதிலிருந்து கடந்த seconds-ஐ சேர்க்கிறது. அந்த output-லிருந்து இரண்டு விஷயங்களை கவனிக்கலாம். முதல் content_block_delta line என்பது முதல் token வருவதற்கான நேரம். முழு prefill பணியும் அதற்குள் முடிந்திருக்கும். அதன் பிறகு வரும் ஒவ்வொரு line-உம் decoding-ன் ஒரு சிறிய step ஆகும். message_stop வரும் வரை time stamps தொடர்ந்து அதிகரிக்கும்.

இப்போது இதற்கு மாறான அமைப்பைப் பயன்படுத்துங்கள். Prompt-ல் நீண்ட document-ஐ சேர்த்து, பதிலை சில tokens-க்கு வரம்பிடுங்கள்.

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 செய்ய அதிக text-ஐ வாசிக்க வேண்டும். அது வந்த பிறகு response கிட்டத்தட்ட உடனே முடிகிறது. Decode செய்ய வேண்டிய tokens சில மட்டுமே உள்ளன. Tens of thousands of tokens உள்ளே சென்றும் clock மிகக் குறைவாகவே நகர்ந்தது. சில hundred tokens வெளியே வந்தாலும் clock முழு நேரமும் இயங்கியது.

ஒவ்வொரு non-streaming response-உம், உங்களிடம் billing செய்யப்படும் numbers-ல் முடிகிறது.

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

ஒவ்வொரு request-க்கும் இந்த நான்கு fields-ஐ log செய்யுங்கள். output_tokens extended thinking-ஐயும் உள்ளடக்குகிறது. எனவே பதிலளிப்பதற்கு முன் சிந்திக்கும் model, அந்த thinking-க்கு output rate அடிப்படையில் billing செய்யப்படும். Request அனுப்புவதற்கு முன் prompt-ன் விலையை கணக்கிட, POST /v1/messages/count_tokens அதே request body-ஐ ஏற்றுக்கொண்டு, model-ஐ இயக்காமல் {"input_tokens": N}-ஐத் திருப்பி அளிக்கும்; இதற்கு கட்டணம் இல்லை. கட்டணம் இல்லாத API பகுதி இது மட்டும் அல்ல. முதல் project-க்கான budget-ஐத் தயாரிப்பதற்கு முன், Claude API-ன் எந்த பகுதிகளுக்கு உங்களிடம் ஒருபோதும் கட்டணம் வசூலிக்கப்படாது என்பதைப் பார்ப்பது பயனுள்ளதாக இருக்கும்.

2026 August நிலவரப்படி ஒரு million 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
  }
]

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

Sonnet 5 இரண்டு முறை காட்டப்படுகிறது, ஏனெனில் அதன் அறிமுகக் கட்டணம் காலாவதியாகிறது. 31 August 2026 வரை, input-க்கு $2, output-க்கு $10 வசூலிக்கப்படும். 1 September 2026 முதல், input-க்கு $3, output-க்கு $15 என்ற standard rate பொருந்தும். இது இரு பக்கங்களிலும் 50% அதிகமாகும். கீழே உள்ள ஒவ்வொரு worked example-மும் August rate-ஐ பயன்படுத்துகிறது.

Rates மாறக்கூடும். அவற்றைச் சரிபார்க்க வேண்டிய இடம் இந்தப் பக்கம் அல்ல. claude.com/pricing தான் அதிகாரப்பூர்வ source. விலை மாறினாலும் மாறாதது கணக்கிடும் முறை.

Price list காட்டாத ஒரு முக்கிய அம்சம் உள்ளது. Anthropic-ன் documentation படி, Claude 4.7 மற்றும் அதற்குப் பிந்தைய models பயன்படுத்தும் புதிய tokenizer, Sonnet 4.6 மற்றும் அதற்கு முந்தைய versions-ன் tokenizer-ஐவிட அதே text-க்கு சுமார் 30% அதிக tokens உருவாக்குகிறது. ஒரு million tokens-க்கான விலையை மட்டும் வைத்து இரண்டு models-ஐ ஒப்பிட்டால், புதிய model அதிக நன்மை தருவது போலத் தோன்றும். காரணம், அதில் அதே document அதிக tokens ஆகக் கணக்கிடப்படும். உண்மையில் முடிக்கப்பட்ட task ஒன்றுக்கான செலவை ஒப்பிடவும். நீங்கள் பயன்படுத்தத் திட்டமிடும் model-ல் உங்கள் உண்மையான prompts-ஐக் கணக்கிடவும். Providers இடையிலும் இதே சிக்கல் உள்ளது; அவற்றின் tokenizers ஒன்றுக்கொன்று இதைவிட அதிகமாக மாறுபடுகின்றன. எனவே Claude மற்றும் ChatGPT இரண்டிலும் ஒரு உண்மையான job-க்கான செலவைக் கணக்கிடுவது, இரண்டு rate cards-ஐ பக்கத்தில் வைத்து ஒப்பிடுவதைவிட அதிக தகவலை வழங்கும். ஒரு million Claude tokens உண்மையான text-ல் எவ்வளவு மதிப்புடையது என்பதைப் பற்றியும் அறியலாம்.

எப்போது output செலவு உங்கள் bill-ல் முக்கியமாகிறது?

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

அதனால், உங்கள் prompt, reply-ஐ விட ஐந்து மடங்குக்கும் அதிகமாக நீளமாக இருந்தால், 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 to 1 என்ற ratio-ல், மொத்த செலவில் output 4.8% ஆகும். எனவே prompt-ஐச் சுருக்குவது மட்டுமே பயனுள்ள நடவடிக்கையாகும். 5 to 1 என்ற ratio-ல், இரண்டு செலவுப் பகுதிகளும் சமமாக இருக்கும். 1 to 6 என்ற ratio-ல், output 96.8% ஆகும்; prompt செலவு rounding error அளவுக்கு மட்டுமே இருக்கும். பெரும்பாலானவர்கள் தங்களுடைய ratio-ஐ தவறாக மதிப்பிடுகிறார்கள். எனவே எதையும் optimize செய்வதற்கு முன், உங்கள் logs-லிருந்து அந்த ratio-ஐ பெறுங்கள்.

ஒரு agent workload: நீண்ட context உள்ளீடு, குறுகிய பதில் வெளியீடு

ஒரு retrieval agent step-ஐ எடுத்துக்கொள்ளுங்கள்: retrieved documents மற்றும் conversation history-யிலிருந்து 60,000 input tokens, அதற்கு 800 token answer. இது 75க்கு 1 என்ற விகிதமாகும். எழுதுவதற்கு முன் வாசிக்கும் எந்த workload-க்கும் இது இயல்பானது.

[
  {
    "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-லும் அந்த call-ன் 6.25% output-ஆகும்; ஏனெனில் முழு price list-லும் இந்த ratio மாறாது. August rate-ல், அந்த call-ன் விலை Opus 5-ல் $0.32, Sonnet 5-ல் $0.128, Haiku 4.5-ல் $0.064. ஒரு நாளில் Opus 5-ல் இதுபோன்ற 200 steps செய்தால், ஒரு நாளுக்கான செலவு $64 ஆகும்.

இந்தப் பிரிவைப் பார்த்தவுடன் எந்த மாற்றம் முக்கியம் என்பது தெளிவாகும். Answer-ஐ 800 tokens-இலிருந்து 400 tokens-ஆகக் குறைத்தால், call-ன் செலவில் சுமார் 3% மட்டுமே சேமிக்கப்படும். Prompt-இலிருந்து 20,000 tokens அளவிலான stale context-ஐ நீக்கினால், அதன் செலவில் சுமார் மூன்றில் ஒரு பகுதி சேமிக்கப்படும். Read-heavy agent-ல் output length-ஐக் குறைப்பது பெரும்பாலும் பயனற்ற முயற்சியாகும். coding agent-ன் tokens உண்மையில் எங்கு செல்கின்றன என்பது, அந்த prompt-ஐ முதலில் நிரப்புவது என்ன என்பதை விளக்குகிறது.

ஒரு generation workload: குறுகிய prompt, நீண்ட draft

இப்போது அமைப்பை மாற்றிப் பார்ப்போம். 2,000 token கொண்ட brief மற்றும் 12,000 token கொண்ட draft; விகிதம் 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
  }
]

இந்த bill-இல் output என்பது 96.8% ஆகும். ஒரு draft-க்கு Opus 5-ன் செலவு $0.31; Haiku 4.5-ல் அது $0.062. இந்த ஐந்து மடங்கு வித்தியாசம் பெரும்பாலும் output பகுதியிலிருந்தே வருகிறது. அதனால் குறைந்த விலை model அதிகமாகச் சேமிக்க உதவுவது இதே பகுதியில்தான்.

கடைசி column, அதே வேலையை Batch API மூலம் செய்வதற்கானது. இதில் input மற்றும் output இரண்டிற்கும் 50% தள்ளுபடி கிடைக்கும். ஒரு draft-க்கு Opus 5-ன் செலவு $0.155 ஆகக் குறையும். Batch முடிவுகளை உடனடியாக வழங்காது; 24 மணி நேரத்திற்குள் வழங்கும். எனவே இது overnight report generation மற்றும் bulk classification-க்கு ஏற்றது. ஒருவர் அமர்ந்து முடிவுக்காகக் காத்திருக்கும் எந்தப் பணிக்கும் இது ஏற்றதல்ல.

Agent step-ல் ஒருபோதும் கிடைக்காத வகையில், இங்கு model routing பயனளிக்கிறது. பணியின் verbose பகுதி mechanical ஆக இருந்தால், ஏற்கனவே நீங்கள் approve செய்த text-ஐ reformat செய்வது அல்லது outline-ஐ விரிவாக்குவது போன்ற பணிகளுக்கு, குறைந்த விலை model அந்த tokens-ஐ ஐந்தில் ஒரு பங்கு விலையில் உருவாக்கும். Opus, Sonnet மற்றும் Haiku-க்கு இடையே தேர்வு செய்தல் quality line உண்மையில் எங்கு உள்ளது என்பதை விளக்குகிறது.

Caching input-க்கு மட்டும் discount வழங்கும்

Prompt caching, உங்கள் prompt-ன் ஒரு prefix-ஐ server-ல் சேமித்து வைக்கும். அதை மீண்டும் படிக்கும்போது, input rate-ன் ஒரு பகுதி மட்டுமே கட்டணமாகும். August 2026 நிலவரப்படி, 5 minute cache-ஐ எழுதுவதற்கு base input rate-ன் 1.25x, 1 hour cache-ஐ எழுதுவதற்கு 2x, cache hit-ஐ படிப்பதற்கு 0.1x என்ற multipliers உள்ளன.

Output இந்த சலுகையில் சேராது. Cached output என்ற ஒன்று இல்லை. Model எழுதும் ஒவ்வொரு token-க்கும், prompt-ன் எவ்வளவு பகுதி cache hit ஆக திரும்பி வந்தாலும், ஒவ்வொரு முறையும் full output rate-ல் கட்டணம் விதிக்கப்படும்.

55,000 input tokens, மொத்த 60,000 input tokens-ல், warm cache-இலிருந்து வழங்கப்படும் அதே agent step-ஐ Opus 5-ல் எடுத்துக்கொள்ளுங்கள்.

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

Call-ன் கட்டணம் $0.32 இலிருந்து $0.0725 ஆகக் குறைகிறது. Output line மாறாது: முன்பு $0.02, பின்னர் $0.02. Caching மொத்தக் கட்டணத்தைக் குறைப்பதுடன், அதன் அமைப்பையும் மாற்றுகிறது. அந்த call-ன் 6.25% output ஆக இருந்தது. இப்போது அது call-ன் நான்கில் ஒரு பகுதியை விட அதிகமாக உள்ளது. ஆகவே அடுத்ததாக எந்த lever-ஐ பயன்படுத்துவது பயனுள்ளதாக இருக்கும் என்பதும் மாறுகிறது.

முதல் call-ல் write கட்டணம் செலுத்தப்படும். 5 minute cache write-க்கு base input-ன் 1.25x கட்டணம் என்பதால், ஒரே ஒரு hit ஏற்பட்ட பிறகே அதன் செலவு ஈடாகிவிடும். 1 hour write-க்கு 2x கட்டணம் என்பதால், அதற்கு இரண்டு hits தேவைப்படும். write மற்றும் read multipliers, மேலும் caching எப்போது பயனளிக்காமல் நிற்கிறது அந்தக் கணக்கை விளக்குகிறது.

நீங்கள் கட்டுப்படுத்தக்கூடிய நான்கு வழிகள்

1. max_tokens-ஐ model maximum-க்கு அல்ல, உங்கள் p95 output length-க்கு அமைக்கவும்.
2. அதிக விளக்கம் தேவைப்படும் steps-ஐ குறைந்த செலவுள்ள model-க்கு route செய்யவும்.
3. யாரும் காத்திருக்காத பணிகளை batch செய்யவும்.
4. replies-ஐ தேவையற்ற அளவு நீளமாக்கும் instructions-ஐ நீக்கவும்.

max_tokens என்பது கடுமையான உச்சவரம்பாகும். அதை உயரமாக அமைத்ததற்காக மட்டும் எந்தச் செலவும் ஏற்படாது; உருவாக்கப்பட்ட tokens-க்கே கட்டணம் வசூலிக்கப்படும், ceiling-க்கு ஒருபோதும் கட்டணம் இல்லை. உயர்ந்த cap செய்வது, தவறாக நீளும் reply-க்கு இருக்கும் வரம்பை மட்டும் நீக்குகிறது. உங்கள் logs-இலிருந்து output_tokens distribution-ஐ எடுத்துப் பார்த்து, cap-ஐ 95th percentile-க்கு சற்றுமேல் அமைக்கவும். stop_reason: "max_tokens" ஏற்பட்டால், response-ஐத் தொடர்வதன் மூலமோ retry செய்வதன் மூலமோ code-ல் கையாளவும். நீங்கள் கண்டறியும் truncation-க்கான செலவு, பணம் செலுத்தி பின்னர் நிராகரிக்கும் 4,000 token நீண்ட விளக்கத்தைவிடக் குறைவு. Extended thinking-மும் output_tokens-க்குள் சேரும். எனவே அதற்கான budget-ஐயும் இதே தரவின் அடிப்படையில் அமைக்கவும்.

ஒரு step-ன் அதிகச் செலவு judgement-ல் அல்ல, volume-ல் இருக்கும்போது routing பயனுள்ளதாக இருக்கும். முடிவெடுப்பதை வலுவான model-லேயே வைத்துக்கொண்டு, typing பணியை குறைந்த செலவுள்ள model-க்கு ஒப்படைக்கவும். முதலில் உங்கள் சொந்த evaluation set-ல் routed version-ஐ அளவிடவும். ஏனெனில் இரண்டு attempts தேவைப்படும் மலிவான model, ஒரே expensive attempt-ஐவிட அதிகச் செலவாகலாம்.

Output-க்கு discount வழங்கும் ஒரே வழி batching ஆகும். இரு தரப்பிலும் 50% தள்ளுபடி கிடைக்கும். Results 24 hours-க்குள் கிடைக்கும். Schedule அடிப்படையில் இயங்கும் எதுவும் இதற்குத் தகுதி பெறும்.

மக்கள் தவிர்க்கும் வழி இதுவே கடைசி வழியாகும். "be thorough", "explain your reasoning" போன்ற phrases, நீங்கள் செய்யும் ஒவ்வொரு call-லும் output length-ஐ அதிகரிக்கும். அவற்றுக்கு பதிலாக நீங்கள் விரும்பும் output வடிவத்தைத் தெளிவாகக் குறிப்பிடவும்: "Answer in at most three sentences" அல்லது "Return only the JSON object, with no preamble". ஒவ்வொரு reply-க்கும் 300 tokens சேர்க்கும் system prompt-ன் செலவு, அதே 300 tokens prompt-ல் ஏற்படுத்தும் செலவைவிட ஐந்து மடங்கு அதிகம். தொடர்ந்து இயங்கும் agent-ன் செலவுகளை கட்டுப்பாட்டில் வைத்தல் monitoring பகுதியை விளக்குகிறது. மேலும், உங்கள் பயன்பாட்டு முறைக்கு API அல்லது flat subscription எது குறைந்த செலவு என்பதைத் தீர்மானித்தல் அவசியம்; subscription ஏற்கனவே ஏற்றுக்கொண்டிருக்கும் per-token செலவை fine-tune செய்வதில் ஒரு வாரம் செலவிடுவதற்கு முன்பே இதை முடிவு செய்ய வேண்டும். ஒரு developer-க்கு, இது பெரும்பாலும் Claude Pro-ன் மாதத்திற்கு $20 கட்டணமும் அதனுடன் வரும் usage limits-உம் நீங்கள் இல்லையெனில் metering செய்ய வேண்டிய பணியை உள்ளடக்குகிறதா என்பதிலேயே அமையும். ஏற்கனவே session நடுவில் அந்த limits-ஐ அடைந்துவிட்டால், நீங்கள் எந்த window-க்காகக் காத்திருக்கிறீர்கள் என்பதைத் தீர்மானித்தல் முதலில் செய்ய வேண்டியது. அதன்பிறகு தீர்வு smaller model, lighter context, extra usage credits, அல்லது அந்தப் பணியை metered API-க்கு மாற்றுதல் ஆகியவற்றில் ஒன்றாக இருக்கும். அந்தப் பணிக்கு metered API குறைந்த செலவுள்ள தேர்வாக இருந்தால், smaller plan-க்கு மாறுதல் அல்லது subscription-ஐ cancel செய்தல் நீங்கள் ஏற்கனவே செலுத்திய month-ஐ பாதிக்காது. எனவே வெளியேறும் போது இந்த மாற்றத்தால் உங்களுக்கு எந்தச் செலவும் ஏற்படாது. நீங்கள் Pro-வை metered API-க்கு பதிலாக ChatGPT-யுடன் ஒப்பிடுகிறீர்கள் என்றால், இரண்டு subscription tiers-ஐ பக்கப்பக்கமாகக் காட்டும் ஒப்பீடு coding work-க்கு எது குறைந்த செலவு என்பதை காட்டும். இந்தக் கேள்வி ஒரு developer-க்காக அல்ல, ஒரு team-க்காகக் கேட்கப்பட்டால், Claude Enterprise, per-seat fee-ஐ இதே API rates-ல் metered tokens-உடன் இணைக்கிறது என்பதை நினைவில் கொள்ளவும். எனவே இந்தப் பக்கத்தில் கூறப்பட்ட ஒவ்வொரு வழியும் அந்த bill-ன் metered பகுதியுக்கும் பொருந்தும்.

FAQ

Output tokens-க்கான கட்டணம், input tokens-ஐ விட ஏன் அதிகம்?

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

Prompt caching செய்தால் output tokens-க்கான கட்டணம் குறையுமா?

இல்லை. Prompt caching input-க்கு மட்டும் பொருந்தும். August 2026 நிலவரப்படி, cache read-க்கு base input rate-ன் 0.1x கட்டணம் வசூலிக்கப்படுகிறது. 5 minute duration-க்கான cache write-க்கு 1.25x கட்டணமும், 1 hour duration-க்கான cache write-க்கு 2x கட்டணமும் வசூலிக்கப்படுகிறது. Cache என்ன செய்திருந்தாலும், ஒவ்வொரு call-லும் output-க்கு முழு rate-ல் கட்டணம் விதிக்கப்படும். அதனால் caching உங்கள் bill-ன் அளவை மட்டுமல்ல, அதன் அமைப்பையும் மாற்றுகிறது: input பகுதியின் செலவு குறைந்ததும், கவனம் செலுத்த வேண்டிய முக்கியப் பகுதி output ஆகிறது.

Reply சுருக்கமாக வந்தால், அதிகமான max_tokens எனக்கு கட்டணம் ஏற்படுத்துமா?

இல்லை. Model உண்மையில் உருவாக்கும் tokens-க்கே கட்டணம் விதிக்கப்படும். எனவே max_tokens என்பது அதிகபட்ச வரம்பு; முன்பதிவு செய்யப்பட்ட அளவு அல்ல. இருப்பினும் இது முக்கியமானது, ஏனெனில் கட்டுப்பாடின்றி நீளும் reply-க்கான ஒரே கடினமான வரம்பு இதுவாகும். நீங்கள் கவனித்த output_tokens-ன் 95th percentile-ஐ விட சிறிது அதிகமாக இதை அமைக்கவும். பின்னர், அமைதியாக துண்டிக்கப்பட்ட answer-ஐ வெளியிடாமல், stop_reason: "max_tokens"-ஐ code-ல் கையாளவும்.

எனது input முதல் output token ratio-வை எவ்வாறு கண்டறிவது?

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