Claudeలో Input, Output Tokens ధర తేడా ఎందుకు?
Claudeలో output tokens ధర input tokens కంటే ఐదు రెట్లు. Prefill, decoding వేగాల తేడా agent నెలవారీ బిల్లును ఎలా మార్చుతుందో నిజమైన ఉదాహరణలతో తెలుసుకోండి.
ఇన్పుట్ టోకెన్ల కంటే అవుట్పుట్ టోకెన్లకు ఎక్కువ ఖర్చు ఎందుకు అవుతుంది
ప్రస్తుత catalogue లోని ప్రతి Claude model లోనూ అవుట్పుట్ టోకెన్ల ధర, ఇన్పుట్ టోకెన్ల ధరకు ఐదు రెట్లు ఉంటుంది. దీనికి కారణం 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 ప్రచురించిన rates ఆధారంగా క్రింద వివరించాం. ఈ rates ను 9 October 2026 న తనిఖీ చేశాం.
Prefill ఒక్కసారి నడుస్తుంది, decoding ప్రతి token కు ఒక్కసారి నడుస్తుంది
Inference server ఒక request ను వేర్వేరు ఖర్చులు కలిగిన రెండు దశల్లో నిర్వహిస్తుంది. Prefill prompt ను చదువుతుంది. Decoding ప్రత్యుత్తరాన్ని రాస్తుంది.
Prefill మొత్తం prompt ను ఒకేసారి process చేస్తుంది. ప్రతి prompt token ఒకే forward pass లో network లోకి ప్రవేశిస్తుంది. అందువల్ల attention మరియు feed-forward పని, ఒకేసారి వేలాది tokens ను కవర్ చేసే కొద్ది సంఖ్యలో పెద్ద matrix multiplications గా మారుతుంది. Model weights ను memory నుంచి ఒక్కసారి చదవడం మొత్తం prompt కు సరిపోతుంది. Accelerator యొక్క matrix units నిరంతరం busy గా ఉంటాయి. అందువల్ల prefill compute-bound గా ఉంటుంది: పరిమితి chip ఎంత వేగంగా multiplication చేయగలదన్నదే.
Decoding ఇలా పనిచేయదు, ఎందుకంటే token 2, token 1 పై ఆధారపడి ఉంటుంది. Model ఇప్పుడే ఉత్పత్తి చేసిన token, తదుపరి దశ input లో భాగమవుతుంది. అందువల్ల ఈ దశలను ఒకేసారి run చేయలేరు. ప్రతి 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 పైనే ఉంటుంది. ప్రస్తుతం process అవుతున్న ప్రతి request ఒక KV cache (key/value cache, ఇప్పటివరకు ఉన్న ప్రతి token కు సంబంధించిన stored 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. ఆ line లోనే మొత్తం prefill పూర్తవుతుంది. దాని తరువాత ప్రతి line decoding లోని ఒక చిన్న step ను సూచిస్తుంది. 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 లోపలికి వెళ్లినా clock స్వల్పంగా మాత్రమే కదిలింది. కొన్ని వందల 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 లో thinking tokens కూడా ఉంటాయి. అందువల్ల సమాధానం ఇవ్వడానికి ముందు ఆలోచించే model, ఆ thinking కు output rate ప్రకారం bill చేస్తుంది. పంపించే ముందు prompt ధరను తెలుసుకోవడానికి POST /v1/messages/count_tokens అదే request body ను స్వీకరించి, model ను run చేయకుండా {"input_tokens": N} ను తిరిగి ఇస్తుంది. దీనికి charge ఉండదు. ఖర్చు లేని API భాగం ఇదొక్కటే కాదు. మొదటి project కోసం budget రూపొందించే ముందు మీకు ఎప్పటికీ bill చేయని Claude API భాగాలు ఏవో పరిశీలించడం ఉపయోగకరం.
2026 October నాటికి ఒక మిలియన్ tokens కు Claude వసూలు చేసే ధర
ఈ చార్ట్ వెనుక ఉన్న డేటా
[
{
"label": "Haiku 4.5",
"input_usd": 1,
"output_usd": 5,
"output_multiple": 5
},
{
"label": "Sonnet 5",
"input_usd": 2,
"output_usd": 10,
"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 కోసం $5 మరియు $25 వసూలు చేస్తుంది. అత్యంత ఖరీదైన Fable 5 కోసం $10 మరియు $50 వసూలు చేస్తుంది. ఆ మొదటి row ను విస్మరించే ముందు ఆ Fable 5 ధరలతో మీకు ఏమి లభిస్తుందో చదవడం ఉపయోగకరం. పరిధిలో పైకి వెళ్తే రెండు వైపులా ఒకే factor గుణించబడుతుంది. అందువల్ల మొత్తం ఖర్చు మారుతుంది, కానీ input మరియు output మధ్య విభజన మాత్రం యథాతథంగా ఉంటుంది.
Sonnet 5 కోసం input కు $2, output కు $10 వసూలు చేస్తుంది. Anthropic దీనిని 31 August 2026 వరకు introductory pricing గా ఆ ధరతో విడుదల చేసింది. 1 September నుంచి ధరలు $3 మరియు $15కు పెరుగుతాయని ప్రకటించింది. అయితే 10 August 2026న $2 మరియు $10ను standard price గా నిర్ణయించింది. ఆ పెంపు అమల్లోకి రాలేదు. కాబట్టి కింద ఉన్న ప్రతి worked example లో ఈరోజు మీరు చెల్లించే ధరనే ఉపయోగించారు.
ఈ పేజీ మొదట ప్రచురించబడిన తరువాత Anthropic మరిన్ని కొత్త models ను కూడా విడుదల చేసింది. ప్రస్తుతం claude.com/pricing పై పైన పేర్కొన్న నాలుగు models అందుబాటులో ఉన్న legacy models గా చూపబడుతున్నాయి. కొత్త models కూడా అదే 5x ratio ను కొనసాగిస్తాయి. Opus 5.5 కోసం $4 మరియు $20, Sonnet 5.5 కోసం $2 మరియు $10, Fable 5.1 కోసం $10 మరియు $50 వసూలు చేస్తారు. Haiku 5.5 కోసం 100,000 tokens వరకు $0.10 మరియు $0.50 వసూలు చేస్తారు. దానిని మించి $0.50 మరియు $2.50 అవుతుంది. కింద ఉన్న ప్రతి Opus 5 సంఖ్య Opus 5.5లో 20% తక్కువగా ఉంటుంది.
ధరలు మారవచ్చు. వాటిని తనిఖీ చేయాల్సిన సరైన ప్రదేశం ఈ పేజీ కాదు. claude.com/pricingనే అధికారిక ఆధారం. ధర మారినా పద్ధతి మాత్రం మారదు.
ధరల జాబితాలో కనిపించని ఒక ముఖ్యమైన విషయం ఉంది. Anthropic documentation ప్రకారం Claude 4.7 మరియు తరువాతి models కొత్త tokenizer ను ఉపయోగిస్తాయి. Sonnet 4.6 మరియు అంతకుముందు versions లోని tokenizer తో పోలిస్తే, అదే text కోసం ఇవి సుమారు 30% ఎక్కువ tokens ఉత్పత్తి చేస్తాయి. ఒక మిలియన్ tokens కు ధర ఆధారంగా మాత్రమే రెండు models ను పోల్చితే కొత్త model వాస్తవానికి ఉన్నదానికంటే చౌకగా కనిపిస్తుంది. కారణం, అదే document లో దానికి ఎక్కువ tokens అవసరం అవుతాయి. పూర్తయిన task కు అయ్యే ఖర్చు ఆధారంగా పోల్చండి. మీరు వాస్తవంగా ఉపయోగించాలనుకుంటున్న model పై మీ నిజమైన prompts ను లెక్కించండి. Providers మధ్య కూడా ఇదే సమస్య ఉంటుంది. వాటి tokenizers పరస్పరం ఇంతకంటే ఎక్కువగా భిన్నంగా ఉంటాయి. అందువల్ల రెండు rate cards ను పక్కపక్కన పెట్టడం కంటే Claude మరియు ChatGPT రెండింటిలోనూ ఒక నిజమైన పని ఖర్చును లెక్కించడం ఎక్కువ సమాచారాన్ని ఇస్తుంది. ఒక మిలియన్ Claude tokens వాస్తవ text లో ఎంత విలువ కలిగి ఉంటాయో ఆ పరిమాణం ఆచరణలో ఎలా ఉంటుందో వివరిస్తుంది.
మీ బిల్లులో output ఎప్పుడు ప్రధాన భాగంగా మారుతుంది?
output ధర input కంటే 5 రెట్లు ఉంటే, సమాన ఖర్చు వచ్చే స్థాయిని సులభంగా లెక్కించవచ్చు. మీ 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 నిష్పత్తిలో output మొత్తం ఖర్చులో 4.8% ఉంటుంది. ఈ సందర్భంలో prompt ను చిన్నదిగా చేయడమే చేయదగిన ముఖ్యమైన పని. 5 to 1 వద్ద రెండు వైపుల ఖర్చు సమానంగా ఉంటుంది. 1 to 6 వద్ద output 96.8% ఉంటుంది. prompt ఖర్చు rounding error స్థాయిలో ఉంటుంది. చాలామంది తమ స్వంత నిష్పత్తిని తప్పుగా అంచనా వేస్తారు. కాబట్టి ఏదైనా optimization చేయడానికి ముందు దాన్ని మీ logs నుంచి తీసుకోండి.
ఏజెంట్ workload: పెద్ద context లోపలికి, చిన్న సమాధానం బయటకు
ఒక retrieval agent దశను తీసుకుందాం: retrieved documents మరియు conversation history నుంచి 60,000 input tokens, సమాధానంగా 800 tokens. ఇది 75 to 1 నిష్పత్తి. చదివిన తర్వాత రాసే ఏ workloadకైనా ఇది సాధారణమే.
ఈ చార్ట్ వెనుక ఉన్న డేటా
[
{
"label": "Haiku 4.5",
"input_cost": 0.06,
"output_cost": 0.004,
"total_cost": 0.064
},
{
"label": "Sonnet 5",
"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
}
]మొత్తం price list అంతటా ratio స్థిరంగా ఉండటంతో, ప్రతి modelలో ఆ callలో output వాటా 6.25%. ఈ call ఖర్చు Opus 5లో $0.32, Sonnet 5లో $0.128, Haiku 4.5లో $0.064. Opus 5లో రోజుకు అలాంటి 200 దశలు నడిపితే రోజుకు $64 అవుతుంది.
ఈ విభజనను చూసిన తర్వాత ఏ అంశాన్ని మార్చాలో స్పష్టంగా తెలుస్తుంది. సమాధానాన్ని 800 tokens నుంచి 400కి తగ్గిస్తే call ఖర్చులో సుమారు 3% మాత్రమే ఆదా అవుతుంది. prompt నుంచి పాత contextలోని 20,000 tokens తొలగిస్తే ఖర్చులో సుమారు మూడో వంతు ఆదా అవుతుంది. చదవడంపై ఆధారపడే agentలో output పొడవును కుదించడం దాదాపు వృథా ప్రయత్నం. 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",
"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% తగ్గింపు ఇస్తుంది. Batchలో Opus 5 ప్రతి draftకు $0.155కు తగ్గుతుంది. Batch ఫలితాలను వెంటనే కాకుండా 24 గంటల్లో అందిస్తుంది. అందువల్ల overnight report generation మరియు bulk classificationకు ఇది సరిపోతుంది. అయితే ఒక వ్యక్తి కూర్చొని ఫలితం కోసం వేచి ఉండే పనులకు ఇది సరిపోదు.
ఇక్కడ model routing ఉపయోగించడం agent దశలో ఎప్పుడూ లభించని ప్రయోజనాన్ని ఇస్తుంది. పని యొక్క verbose భాగం mechanicalగా ఉంటే, ఉదాహరణకు text reformatting లేదా మీరు ఇప్పటికే approve చేసిన outlineను విస్తరించడం వంటి పనులైతే, చౌకైన model ఆ tokenలను ఐదో వంతు ధరకు ఉత్పత్తి చేస్తుంది. Opus, Sonnet మరియు Haiku మధ్య ఎంపికలో వాస్తవ quality పరిమితి ఎక్కడ ఉంటుందో వివరించారు.
క్యాషింగ్ input ఖర్చును మాత్రమే తగ్గిస్తుంది
Prompt caching మీ prompt యొక్క prefix ను server పై నిల్వ చేస్తుంది. దాన్ని మళ్లీ చదివేటప్పుడు input rate లోని కొంత భాగాన్ని మాత్రమే వసూలు చేస్తుంది. 9 October 2026 నాటికి, ఈ పేజీలో ధరలు చూపించిన models కు multipliers ఇలా ఉన్నాయి: 5 minute cache రాయడానికి base input rate కు 1.25x, 1 hour cache రాయడానికి 2x, మరియు cache hit ను చదవడానికి 0.1x. కొత్త models లో cache hit చదవడానికి ఇంకా తక్కువ ఖర్చు అవుతుంది: Opus 5.5 మరియు Sonnet 5.5 పై 0.05x, Fable 5.1 పై 0.025x.
Output ఈ సౌకర్యంలో భాగం కాదు. Cached output ఉండదు. Model రాసే ప్రతి token కు ప్రతిసారీ పూర్తి output rate వర్తిస్తుంది. Prompt లో ఎంత భాగం cache hit గా వచ్చినా ఇది మారదు.
55,000 input tokens లో 60,000 tokens warm cache నుంచి వచ్చినప్పుడు, Opus 5 పై అదే agent step ను తీసుకోండి.
ఈ చార్ట్ వెనుక ఉన్న డేటా
[
{
"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 లో output వాటా 6.25%. ఇప్పుడు అది call లో పావు వంతుకంటే ఎక్కువగా ఉంది. అందువల్ల తరువాత ఏ ఖర్చు నియంత్రణ చర్య తీసుకోవాలో మారుతుంది.
మొదటి call లో cache రాయడానికి అయ్యే ఖర్చు చెల్లించాలి. 5 minute cache రాయడానికి base input rate కు 1.25x ఖర్చవుతుంది. కాబట్టి ఒక్క hit తర్వాతే ఆ ఖర్చు తిరిగి వస్తుంది. 1 hour cache రాయడానికి 2x ఖర్చవుతుంది. అందువల్ల దీనికి రెండు hits అవసరం. write మరియు read multipliers, అలాగే caching ద్వారా ఆదా ఆగిపోయే స్థానం ఆ లెక్కను వివరిస్తుంది.
మీరు నియంత్రించగల నాలుగు మార్గాలు
max_tokensను model maximum వద్ద కాకుండా, మీ p95 output length వద్ద సెట్ చేయండి.- ఎక్కువ output అవసరమయ్యే దశలను తక్కువ ఖర్చు model కు పంపండి.
- ఎవరూ ఎదురుచూడని పనులను batch చేయండి.
- సమాధానాలను అనవసరంగా పొడిగించే instructions ను తొలగించండి.
max_tokens ఒక hard ceiling. దీన్ని ఎక్కువగా సెట్ చేసినందుకు మాత్రమే ఖర్చు ఉండదు, ఎందుకంటే మీకు ఉత్పత్తి చేసిన tokens కోసం మాత్రమే billing జరుగుతుంది; ceiling కోసం ఎప్పుడూ billing జరగదు. అధిక cap వల్ల తప్పుగా సాగిన reply పై పరిమితి తొలగిపోతుంది. మీ logs నుంచి output_tokens distribution ను తీసుకుని, cap ను 95th percentile కంటే కొద్దిగా ఎక్కువగా సెట్ చేయండి. stop_reason: "max_tokens" ను code లో నిర్వహించడానికి response ను కొనసాగించండి లేదా retry చేయండి. మీరు గుర్తించి నిర్వహించే truncation ఖర్చు, చెల్లించి తర్వాత పారేసే 4,000 tokenల పొడవైన సమాధానం కంటే తక్కువగా ఉంటుంది. Thinking కూడా output_tokens లోకి చేరి max_tokens పై లెక్కలోకి వస్తుంది. అందువల్ల అదే ఆధారంతో cap పరిమాణాన్ని నిర్ణయించండి. Adaptive thinking కలిగిన models లో thinking నిరంతరం reply ను ఆక్రమిస్తే effort level ను తగ్గించండి.
ఒక దశలో ఖరీదైన భాగం judgement కంటే volume అయినప్పుడు routing పనిచేస్తుంది. నిర్ణయాన్ని strong model వద్ద ఉంచి, typing పనిని తక్కువ ఖర్చు ఉన్న దానికి అప్పగించండి. Routed version ను ముందుగా మీ స్వంత evaluation set పై కొలవండి. రెండు attempts అవసరమయ్యే చవక model, ఒక ఖరీదైన attempt కంటే ఎక్కువ ఖర్చు కావచ్చు.
Output పై discount ఇచ్చే ఏకైక మార్గం batching. రెండు వైపులా 50% discount లభిస్తుంది, results 24 గంటల్లో వస్తాయి, మరియు 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 ఖర్చును భరించగలిగేది కావచ్చు. ఒక developer కోసం ఇది ప్రధానంగా Claude Pro యొక్క నెలకు $20 ధర మరియు దానితో వచ్చే usage limits మీరు లేకపోతే meter చేసే పనిని కవర్ చేస్తాయా అనే దానిపై ఆధారపడి ఉంటుంది. మీరు session మధ్యలోనే ఆ limits ను చేరుకుంటే, ముందుగా మీరు ఏ window కోసం ఎదురుచూస్తున్నారో గుర్తించడం అవసరం. ఆ తర్వాత పరిష్కారం smaller model, lighter context, అదనపు usage credits, లేదా ఆ పనిని metered API పైకి మార్చడం కావచ్చు. Metered API ఆ పనికి చవకైన ఎంపికగా తేలితే, చిన్న plan కు మారడం లేదా దాన్ని cancel చేయడం ఇప్పటికే చెల్లించిన నెలను ప్రభావితం చేయదు. అందువల్ల మార్పు చేసే సమయంలో అదనపు ఖర్చు ఉండదు. మీరు Pro తో పోలుస్తున్న plan ChatGPT దిదైతే, metered API ది కాకపోతే, రెండు subscription ladders ను పక్కపక్కన ధరలతో చూడడం coding work కు ఏది చవకో చూపిస్తుంది. ఈ ప్రశ్నను ఒక developer కోసం కాకుండా team కోసం అడుగుతున్నట్లయితే, Claude Enterprise ప్రతి seat కు fee తో పాటు ఇదే API rates వద్ద tokens ను meter చేస్తుంది అని గుర్తుంచుకోండి. అందువల్ల ఈ పేజీలోని ప్రతి మార్గం ఆ bill లోని metered భాగానికి ఇప్పటికీ వర్తిస్తుంది.
FAQ
అవుట్పుట్ tokens, ఇన్పుట్ tokens కంటే ఎందుకు ఎక్కువ ఖర్చవుతాయి?
వాటిని ఉత్పత్తి చేయడానికి ప్రతి tokenకు accelerator సమయం చాలా ఎక్కువగా అవసరం అవుతుంది. Prompt మొత్తం ఒకే forward passలో process అవుతుంది. అందువల్ల model weights ను ఒక్కసారి చదవడం ద్వారా వేల tokensను process చేయవచ్చు. ఈ దశలో hardware multiply throughput ద్వారా పరిమితం అవుతుంది. Reply ఒక్కో token చొప్పున ఉత్పత్తి అవుతుంది. ప్రతి tokenకు full model weights ను మళ్లీ చదివే ప్రత్యేక forward pass అవసరం అవుతుంది. అందువల్ల ఈ దశలో hardware memory bandwidth ద్వారా పరిమితం అవుతుంది. Haiku 5.5 నుంచి Fable 5.1 వరకు ప్రస్తుత catalogue అంతటా Anthropic outputకు input కంటే ఐదు రెట్లు ధర వసూలు చేస్తుంది.
Prompt caching వల్ల output tokens చవక అవుతాయా?
కాదు. Prompt caching ఇన్పుట్కు మాత్రమే వర్తిస్తుంది. 9 October 2026 నాటికి, చాలా modelsలో cache read కు base input rateలో 0.1x ఖర్చవుతుంది. Opus 5.5 మరియు Sonnet 5.5లో ఇది 0.05x, Fable 5.1లో 0.025x. 5 minute duration కోసం cache writesకు 1.25x, 1 hour duration కోసం 2x ఖర్చవుతుంది. Cache ఏది చేసినా, ప్రతి callలో outputకు పూర్తి rateతోనే billing జరుగుతుంది. అందుకే caching మీ bill పరిమాణాన్ని మాత్రమే కాకుండా దాని నిర్మాణాన్ని కూడా మారుస్తుంది. Input భాగం గణనీయంగా తగ్గిన తర్వాత, ఖర్చు తగ్గించడానికి ప్రధానంగా పరిశీలించాల్సిన భాగం output అవుతుంది.
Reply తక్కువగా వచ్చినా అధిక max_tokens వల్ల నాకు ఖర్చవుతుందా?
కాదు. Model వాస్తవంగా ఉత్పత్తి చేసిన tokensకు మాత్రమే billing జరుగుతుంది. కాబట్టి max_tokens ఒక ceiling మాత్రమే, ముందస్తు reservation కాదు. అయినప్పటికీ ఇది ముఖ్యమే, ఎందుకంటే నియంత్రణ లేకుండా పొడవుగా సాగే replyపై ఉన్న ఏకైక కఠిన పరిమితి ఇదే. మీరు గమనించిన output_tokens యొక్క 95th percentile కంటే కొద్దిగా ఎక్కువగా దీన్ని set చేయండి. తరువాత stop_reason: "max_tokens" ను silently truncated answerగా పంపకుండా codeలో handle చేయండి.
నా 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 to 1 కంటే ఎక్కువగా ఉంటే, మీ ఖర్చు promptలోనే ఎక్కువగా ఉంది. కాబట్టి స్థిరంగా ఉండే భాగాన్ని cache చేసి, మిగతా భాగాన్ని తగ్గించండి. అది దాని కంటే తక్కువగా ఉంటే, మీ ఖర్చు replyలో ఎక్కువగా ఉంది. కాబట్టి దాని పొడవును పరిమితం చేయండి. ఎక్కువ outputను ఉత్పత్తి చేసే దశలను చవకైన modelకు లేదా Batch APIకు మార్చండి.