ద్వారా Claudeలో input, output token ఖర్చుల తేడా ఎందుకు?
Claudeలో output tokens ఖర్చు input కంటే ఐదు రెట్లు. Prefill, decoding తేడా మీ agent billను ఎలా మార్చుతుందో 60,000/800 మరియు 2,000/12,000 ఉదాహరణలతో చూడండి.
ఇన్‌పుట్ టోకెన్ల కంటే అవుట్‌పుట్ టోకెన్లకు ఎక్కువ ఖర్చు ఎందుకు అవుతుంది
ప్రస్తుత catalogue లోని ప్రతి Claude model లో output tokens ఖర్చు, input tokens ఖర్చుకు ఐదు రెట్లు ఉంటుంది. దీనికి కారణం computation నిర్మాణం. Prompt ను చదవడానికి model పై ఒక pass సరిపోతుంది. Reply ను రాయడానికి ప్రతి token కు ఒక pass అవసరం. ప్రతి pass, దాని ముందు pass పూర్తయ్యే వరకు వేచి ఉండాలి.
Price list లోని ప్రతి rowలో ఈ నిష్పత్తి ఒకేలా ఉంటుంది. అందువల్ల మీరు ఎంచుకునే 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 reply ను రాస్తుంది.
Prefill మొత్తం prompt ను ఒకేసారి తీసుకుంటుంది. ప్రతి prompt token ఒకే forward pass లో network లోకి ప్రవేశిస్తుంది. అందువల్ల attention మరియు feed-forward పనులు ఒకేసారి వేలాది tokens ను ప్రాసెస్ చేసే కొద్ది పెద్ద matrix multiplications గా మారతాయి. Model weights ను memory నుంచి ఒకసారి చదవడం మొత్తం prompt కు సరిపోతుంది. Accelerator యొక్క matrix units నిరంతరం busyగా ఉంటాయి. అందువల్ల prefill compute-bound: పరిమితి chip ఎంత వేగంగా multiply చేయగలదో దానిపై ఉంటుంది.
Decoding ఆ విధంగా పనిచేయదు, ఎందుకంటే token 2, token 1పై ఆధారపడి ఉంటుంది. Model ఇప్పుడే ఉత్పత్తి చేసిన token తదుపరి దశ input లో భాగమవుతుంది. అందువల్ల ఈ దశలను ఒకేసారి నడపలేం. ప్రతి 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 మొత్తంగా అందుబాటులో ఉండటానికి ఇదే కారణం. పరిమితి మళ్లీ memoryపైనే ఉంటుంది. In-flight లో ఉన్న ప్రతి request ఒక KV cache (key/value cache, ఇప్పటివరకు వచ్చిన ప్రతి token కు నిల్వ చేసిన attention state) ను ఉంచుతుంది. ఉత్పత్తి అయ్యే ప్రతి token తో ఆ cache పెరుగుతుంది. అది accelerator ను నింపినప్పుడు batch ఇక పెరగదు.
ఇవేవీ మీకు ఖచ్చితమైన సంఖ్యను ఇవ్వవు. 5x ను కొలిచిన hardware ratioగా పరిగణించకూడదు. ఇది Anthropic నిర్ణయించిన ధర. ఈ ధర prefill మరియు decoding మధ్య ఉన్న అసమానతను పరిగణనలోకి తీసుకుంటుంది. మీరు స్వయంగా నిర్ధారించగలది దిశ మాత్రమే. దానికి సుమారు ఒక నిమిషం పడుతుంది.
మీ 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 వరకు పట్టిన సమయం మీ time to first token. Prefill మొత్తం ఆ సమయంలోనే పూర్తవుతుంది. దాని తర్వాతి ప్రతి line decodingలోని ఒక చిన్న దశను సూచిస్తుంది. message_stop వచ్చే వరకు timestamps పెరుగుతూనే ఉంటాయి.
ఇప్పుడు ఆకారాన్ని మార్చండి. Promptలో దీర్ఘమైన documentను ఉంచి, answerను కొన్ని 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 కొన్ని మాత్రమే మిగిలి ఉంటాయి. పదివేల tokensకు పైగా inputగా వెళ్లినా clockలో మార్పు చాలా తక్కువగా ఉంటుంది. కొన్ని వందల tokens outputగా వచ్చినా 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ను run చేయకుండా {"input_tokens": N} ను return చేస్తుంది. దీనికి ఎలాంటి charge ఉండదు. Charge లేని API భాగం ఇదొక్కటే కాదు. మొదటి projectకు budget రూపొందించే ముందు Claude APIలో మీకు ఎప్పుడూ billing జరగని భాగాలు చూడటం ఉపయోగకరం.
2026 ఆగస్టు నాటికి ప్రతి మిలియన్ tokens కు Claude వసూలు చేసే ధర
The data behind this chart
[
{
"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 వసూలు చేస్తుంది. ఆ మొదటి row ను పక్కన పెట్టే ముందు ఆ Fable 5 ధరలకు మీకు ఏమి లభిస్తుందో చదవడం ఉపయోగకరం. ధరల శ్రేణిలో పైకి వెళ్లినప్పుడు రెండు వైపులా ఒకే factor గుణించబడుతుంది. అందువల్ల మీ మొత్తం ఖర్చు మారుతుంది, కానీ input మరియు output మధ్య విభజన మాత్రం అలాగే ఉంటుంది.
Sonnet 5 రెండుసార్లు కనిపిస్తుంది, ఎందుకంటే దాని ప్రారంభ ధర గడువు ముగుస్తుంది. 31 August 2026 వరకు input కు $2, output కు $10 వసూలు చేస్తుంది. 1 September 2026 నుంచి $3 input ధర, $15 output ధర కలిగిన standard rate వర్తిస్తుంది. ఇది రెండు వైపులా 50% ఎక్కువ. దిగువన ఉన్న ప్రతి worked example August rate ను ఉపయోగిస్తుంది.
ధరలు మారుతుంటాయి. వాటిని తనిఖీ చేయడానికి ఈ page ను ఉపయోగించకండి. claude.com/pricingనే ప్రామాణిక మూలం. ధర మారిన తర్వాత కూడా వర్తించేది పద్ధతి.
ధరల జాబితాలో కనిపించని ఒక ముఖ్యమైన విషయం ఉంది. Anthropic documentation ప్రకారం Claude 4.7 మరియు తరువాతి models, Sonnet 4.6 మరియు అంతకుముందు versions లోని tokenizer కంటే కొత్త tokenizer ను ఉపయోగిస్తాయి. అదే text కు ఇది సుమారు 30% ఎక్కువ tokens ఉత్పత్తి చేస్తుంది. ప్రతి million tokens ధర ఆధారంగా మాత్రమే రెండు models ను పోలిస్తే newer model కు అనుకూలంగా తప్పుదారి పట్టించే ఫలితం వస్తుంది, ఎందుకంటే అదే document దానిలో ఎక్కువ tokens గా లెక్కించబడుతుంది. Finished task కు అయ్యే ఖర్చు ఆధారంగా పోల్చండి. మీరు వాస్తవంగా ఉపయోగించబోయే model పై మీ నిజమైన prompts ను లెక్కించండి. Providers మధ్య కూడా ఇదే సమస్య ఉంటుంది. వాటి tokenizers ఒకదానితో ఒకటి ఇంతకంటే ఎక్కువగా భిన్నంగా ఉండవచ్చు. అందువల్ల Claude మరియు ChatGPT రెండింటిలోనూ ఒక వాస్తవ job ఖర్చును లెక్కించడం రెండు rate cards ను పక్కపక్కన ఉంచడం కంటే ఎక్కువ సమాచారం ఇస్తుంది. ఒక మిలియన్ Claude tokens వాస్తవ text లో ఎంత విలువ కలిగి ఉంటాయో ఆ పరిమాణం ఆచరణలో ఎలా కనిపిస్తుందో వివరిస్తుంది.
మీ బిల్లులో output ఖర్చు ఎప్పుడు ప్రధానంగా మారుతుంది?
output ధర input కంటే 5 రెట్లు ఉంటే, సమతుల్య స్థితిని సులభంగా లెక్కించవచ్చు. మీ input tokens ను I గా, output tokens ను O గా పరిగణించండి. Input ఖర్చు I. Output ఖర్చు O కి 5 రెట్లు. 5 times O, I కంటే ఎక్కువగా ఉన్నప్పుడు మొత్తం ఖర్చులో సగానికి మించి output ఖర్చే ఉంటుంది. దీనికి token ratio 5 input కు 1 output.
అందువల్ల మీ prompt, reply కంటే ఐదు రెట్లకంటే ఎక్కువ పొడవుగా ఉంటే input పెద్ద ఖర్చు అంశంగా ఉంటుంది. దాని కంటే తక్కువగా ఉంటే output పెద్ద ఖర్చు అంశంగా ఉంటుంది.
The data behind this chart
[
{
"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 నిష్పత్తిలో output ఖర్చు మొత్తం ఖర్చులో 4.8% ఉంటుంది. కాబట్టి prompt ను చిన్నదిగా చేయడం మాత్రమే చేయదగిన పని. 5 to 1 వద్ద రెండు వైపుల ఖర్చులు సమానంగా ఉంటాయి. 1 to 6 వద్ద output ఖర్చు 96.8% ఉంటుంది. Prompt ఖర్చు rounding error స్థాయికి తగ్గిపోతుంది. చాలామంది తమ నిష్పత్తిని తప్పుగా అంచనా వేస్తారు. అందువల్ల ఏదైనా optimize చేయడానికి ముందు ఆ నిష్పత్తిని logs నుంచి తీసుకోండి.
ఒక agent workload: లోపలికి ఎక్కువ context, బయటికి చిన్న సమాధానం
ఒక retrieval agent step తీసుకోండి: retrieved documents మరియు conversation history నుంచి 60,000 input tokens, అలాగే 800 tokenల సమాధానం. ఇది 75 to 1 నిష్పత్తి. చదివిన తర్వాత రాసే ఏ పనికైనా ఇది సాధారణమే.
The data behind this chart
[
{
"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లో output ఆ callలో 6.25% మాత్రమే, ఎందుకంటే మొత్తం price list అంతటా ఈ నిష్పత్తి స్థిరంగా ఉంటుంది. August rate ప్రకారం ఈ callకు Opus 5లో $0.32, Sonnet 5లో $0.128, Haiku 4.5లో $0.064 ఖర్చవుతుంది. Opus 5లో రోజుకు ఇలాంటి 200 steps చేస్తే రోజుకు $64 ఖర్చవుతుంది.
ఈ విభజనను చూసిన వెంటనే ప్రభావవంతమైన మార్పు స్పష్టమవుతుంది. సమాధానాన్ని 800 tokens నుంచి 400 tokensకు తగ్గిస్తే call ఖర్చులో సుమారు 3% మాత్రమే ఆదా అవుతుంది. Prompt నుంచి పాతబడిన contextలో 20,000 tokens తొలగిస్తే దాదాపు మూడో వంతు ఖర్చు తగ్గుతుంది. Read-heavy agentలో output lengthను కుదించడం దాదాపు వృథా ప్రయత్నమే. coding agent tokens వాస్తవంగా ఎక్కడ ఖర్చవుతాయో ఆ promptను మొదటగా నింపే అంశాలను వివరిస్తుంది.
జెనరేషన్ workload: చిన్న prompt, పొడవైన draft
ఇప్పుడు నిష్పత్తిని మార్చి చూద్దాం. 2,000 tokens గల brief, 12,000 tokens గల draft — నిష్పత్తి 1 కు 6.
The data behind this chart
[
{
"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
}
]ఈ బిల్లులో output వాటా 96.8%. Haiku 4.5లో draft కు $0.062 ఖర్చవుతుండగా, Opus 5లో $0.31 ఖర్చవుతుంది. ఈ ఐదు రెట్ల వ్యత్యాసం దాదాపు పూర్తిగా output భాగం వల్లే వస్తుంది. అందువల్ల చౌకైన model ద్వారా అత్యధిక ఆదా ఇక్కడే లభిస్తుంది.
చివరి కాలమ్ Batch API ద్వారా ఇదే job కు సంబంధించినది. ఇది input మరియు output రెండింటిపై 50% తగ్గింపును ఇస్తుంది. Opus 5లో ప్రతి draft ఖర్చు $0.155కు తగ్గుతుంది. Batch ఫలితాలను వెంటనే కాకుండా 24 గంటల్లో అందిస్తుంది. అందువల్ల overnight report generation మరియు bulk classification కు ఇది అనుకూలం. ఒక వ్యక్తి కూర్చొని ఫలితం కోసం వేచి ఉండే పనులకు ఇది అనుకూలం కాదు.
Agent దశలో ఎప్పుడూ లేని విధంగా ఇక్కడ model routing ప్రయోజనం ఇస్తుంది. Job లోని verbose భాగం యాంత్రికమైనదైతే — ఉదాహరణకు, text ను reformat చేయడం లేదా మీరు ఇప్పటికే ఆమోదించిన outline ను విస్తరించడం — చౌకైన model ఆ tokens ను ఐదో వంతు ఖర్చుతో ఉత్పత్తి చేస్తుంది. Opus, Sonnet మరియు Haiku మధ్య ఎంపికలో quality line వాస్తవంగా ఎక్కడ ఉందో వివరించబడింది.
క్యాషింగ్ input ఖర్చును మాత్రమే తగ్గిస్తుంది
Prompt caching మీ prompt యొక్క ఒక prefix ను serverలో నిల్వ చేస్తుంది. దాన్ని మళ్లీ చదివేటప్పుడు input rate లోని కొంత భాగాన్ని మాత్రమే వసూలు చేస్తుంది. August 2026 నాటికి multipliers ఇవి: 5 minute cache రాయడానికి base input rate కు 1.25x, 1 hour cache రాయడానికి 2x, cache hit ను చదవడానికి 0.1x.
Output ఈ లెక్కలోకి రాదు. Cached output ఉండదు. Model రాసే ప్రతి token కు ప్రతిసారీ పూర్తి output rate ప్రకారం charge అవుతుంది. Prompt లో ఎంత భాగం cache hit గా తిరిగి వచ్చినా ఇది మారదు.
55,000 input tokens warm cache నుంచి అందిన పరిస్థితిలో, Opus 5 పై అదే agent step ను తీసుకోండి. మొత్తం input tokens సంఖ్య 60,000.
The data behind this chart
[
{
"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 bill ను తగ్గించడమే కాకుండా, దాని నిర్మాణాన్ని కూడా మారుస్తుంది. ఆ call లో output వాటా 6.25%. ఇప్పుడు అది మొత్తం ఖర్చులో నాలుగో వంతుకంటే ఎక్కువగా ఉంది. అందువల్ల తరువాత ఏ ఖర్చు నియంత్రణ చర్య తీసుకోవాలో మారుతుంది.
మొదటి call లో write ఖర్చు చెల్లించాలి. 5 minute cache write కు base input ఖర్చుకు 1.25x అవుతుంది. అందువల్ల ఒక్క hit వచ్చిన తర్వాతే అది తన ఖర్చును తిరిగి పొందుతుంది. 1 hour write కు 2x ఖర్చవుతుంది. అందువల్ల దానికి రెండు hits అవసరం. write మరియు read multipliers, అలాగే caching ఎప్పుడు ప్రయోజనకరంగా ఉండదో ఆ లెక్కను వివరంగా చూపిస్తుంది.
మీ నియంత్రణలో ఉన్న నాలుగు మార్గాలు
max_tokensను model maximum వద్ద కాకుండా, మీ p95 output length వద్ద సెట్ చేయండి.- ఎక్కువ వివరాలు అవసరమైన దశలను తక్కువ ఖర్చు model కు route చేయండి.
- ఎవరూ ఎదురుచూడని పనులను batch చేయండి.
- సమాధానాలను అనవసరంగా పొడిగించే instructions ను తొలగించండి.
max_tokens ఒక కఠిన పరిమితి. దాన్ని ఎక్కువగా సెట్ చేసినంత మాత్రాన ఖర్చు ఉండదు, ఎందుకంటే ఉత్పత్తి అయిన tokens కు మాత్రమే billing జరుగుతుంది; ceiling కు ఎప్పుడూ billing జరగదు. అధిక cap వల్ల తప్పు దిశలో వెళ్లిన reply పై పరిమితి తొలగిపోతుంది. మీ logs నుంచి output_tokens distribution ను తీసుకుని, cap ను 95th percentile కంటే కొద్దిగా ఎక్కువగా సెట్ చేయండి. stop_reason: "max_tokens" ను code లో నిర్వహించండి: response ను కొనసాగించండి లేదా retry చేయండి. మీరు గుర్తించగలిగే truncation ఖర్చు, చెల్లించి చివరికి విస్మరించే 4,000 token పొడవైన ramble కంటే తక్కువ. Extended thinking కూడా output_tokens లోకి చేరుతుంది. కాబట్టి అదే ఆధారాల ప్రకారం ఆ budget ను సెట్ చేయండి.
ఒక దశలో ఖరీదైన భాగం judgement కాకుండా volume అయినప్పుడు routing పనిచేస్తుంది. నిర్ణయం తీసుకునే పనిని strong model వద్ద ఉంచి, typing పనిని తక్కువ ఖర్చు model కు అప్పగించండి. ముందుగా మీ స్వంత evaluation set పై routed version ను కొలవండి. ఎందుకంటే రెండు attempts అవసరమయ్యే cheap model, ఒక expensive attempt కంటే ఎక్కువ ఖర్చు కావచ్చు.
Output పై discount ఇచ్చే ఏకైక మార్గం batching. రెండు వైపులా 50% తగ్గింపు, 24 గంటల్లో results, మరియు schedule ఆధారంగా నడిచే ఏ పని అయినా దీనికి అర్హత పొందుతుంది.
చివరి మార్గాన్ని చాలామంది విస్మరిస్తారు. "be thorough", "explain your reasoning" వంటి phrases మీరు ఎప్పుడైనా చేసే ప్రతి call లో output length ను పెంచుతాయి. వాటి బదులు మీకు కావలసిన ఆకృతిని స్పష్టంగా చెప్పండి: "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 ఖర్చును మీరు ఒక వారం tuning చేయడం కంటే ఇది ఉపయోగకరం. ఒక developer కోసం, ప్రధానంగా Claude Pro యొక్క నెలకు $20 ఖర్చు మరియు దానితో వచ్చే usage limits మీరు లేకపోతే metering చేసే పనిని కవర్ చేస్తున్నాయా అనేదే విషయం. మీరు ఇప్పటికే mid-session లో ఆ limits ను తాకుతుంటే, మీరు ఏ window కోసం ఎదురుచూస్తున్నారో గుర్తించడం మొదటి పని. అక్కడి నుంచి పరిష్కారం smaller model, lighter context, అదనపు usage credits లేదా ఆ పనిని metered API పైకి మార్చడం కావచ్చు. Metered API ఆ పనికి తక్కువ ఖర్చు అయ్యే ఎంపిక అని తేలితే, చిన్న plan కు మారడం లేదా దాన్ని cancel చేయడం మీరు ఇప్పటికే చెల్లించిన నెలను ప్రభావితం చేయదు. కాబట్టి మార్పు చేయడానికి అదనపు ఖర్చు ఉండదు. మీరు Pro తో పోల్చుతున్న plan metered API కాకుండా ChatGPT ది అయితే, రెండు subscription ladders ను పక్కపక్కన ధరలతో పోల్చడం coding పనికి ఏది తక్కువ ఖర్చో చూపిస్తుంది. ఈ ప్రశ్నను ఒక developer కోసం కాకుండా team కోసం అడిగితే, Claude Enterprise ప్రతి 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 వ్యవధి గల cache writeకు 1.25x, 1 hour వ్యవధి గల cache writeకు 2x ఖర్చు అవుతుంది. Cache ఏం చేసినా, ప్రతి callలో outputకు పూర్తి rateతోనే billing జరుగుతుంది. అందుకే caching మీ bill పరిమాణంతో పాటు దాని నిర్మాణాన్ని కూడా మారుస్తుంది: input భాగం తగ్గిపోయిన తర్వాత, ఖర్చు తగ్గించడానికి ప్రధానంగా పరిశీలించాల్సింది output భాగమే.
Reply చిన్నదిగా వచ్చినా అధిక max_tokens వల్ల నాకు డబ్బు ఖర్చవుతుందా?
లేదు. Model వాస్తవంగా రూపొందించిన tokensకే మీకు billing జరుగుతుంది. కాబట్టి max_tokens ఒక గరిష్ఠ పరిమితి మాత్రమే, ముందస్తు reservation కాదు. అయినప్పటికీ ఇది ముఖ్యమే, ఎందుకంటే అదుపు తప్పి పొడవుగా మారే replyకు ఉన్న ఏకైక కఠిన పరిమితి ఇదే. మీరు గమనించిన output_tokens యొక్క 95th percentile కంటే కొద్దిగా ఎక్కువగా దీన్ని సెట్ చేయండి. తరువాత నిశ్శబ్దంగా కత్తిరించబడిన answerను పంపకుండా, stop_reason: "max_tokens" ను codeలో నిర్వహించండి.
నా input-to-output token ratioను ఎలా కనుగొనాలి?
ప్రతి responseలోని usage object నుంచి input_tokens, output_tokens, cache_read_input_tokens మరియు cache_creation_input_tokens ను log చేయండి. తరువాత ఒక వారం మొత్తాలను భాగించండి. Input-to-output నిష్పత్తి 5కు 1 కంటే ఎక్కువగా ఉంటే, మీ ఖర్చు promptలోనే ఉంది. కాబట్టి స్థిరమైన భాగాన్ని cache చేసి, మిగిలినదాన్ని తగ్గించండి. దాని కంటే తక్కువగా ఉంటే, మీ ఖర్చు replyలో ఉంది. కాబట్టి దాని పొడవుకు పరిమితి విధించండి. ఎక్కువ outputను రూపొందించే దశలను చౌకైన modelకు లేదా Batch APIకు తరలించండి.