Claudeలో Input, Output Tokens ఖర్చు తేడా ఎందుకు?

ఇన్‌పుట్ టోకెన్ల కంటే అవుట్‌పుట్ టోకెన్లకు ఎక్కువ ఖర్చు ఎందుకు అవుతుంది

ప్రస్తుత catalogue లోని ప్రతి Claude modelలో output tokens ఖర్చు input tokens ఖర్చుకు ఐదు రెట్లు ఉంటుంది. దీనికి కారణం computation విధానం. Prompt ను model ఒక passలో చదువుతుంది. Reply ను రాయేటప్పుడు ప్రతి tokenకు ఒక pass అవసరం. ప్రతి pass, దానికి ముందు ఉన్న pass పూర్తయ్యే వరకు వేచి ఉండాలి.

Price listలోని ప్రతి వరుసలో ఈ నిష్పత్తి ఒకే విధంగా ఉంటుంది. అందువల్ల మీరు ఎంచుకునే 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 ఉంటుంది. ఒక్క token ను ఉత్పత్తి చేయడానికి ప్రతి pass 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 పైనే ఉంటుంది. అమలులో ఉన్న ప్రతి request ఒక KV cache (key/value cache; ఇప్పటివరకు ఉన్న ప్రతి token కు సంబంధించిన నిల్వచేసిన attention state) ను కలిగి ఉంటుంది. ఉత్పత్తి అయ్యే ప్రతి token తో ఆ cache పెరుగుతుంది. అది accelerator ను పూర్తిగా నింపినప్పుడు batch ను ఇక పెంచలేరు.

ఇవేవీ మీకు ఖచ్చితమైన సంఖ్యను ఇవ్వవు. 5x ను కొలిచిన hardware ratio గా పరిగణించకూడదు. ఇది Anthropic నిర్ణయించిన ధర; ఈ అసమానతను పరిగణనలోకి తీసుకుని నిర్ణయించారు. మీరు స్వయంగా నిర్ధారించగల విషయం దిశ మాత్రమే. దానికి సుమారు ఒక నిమిషం పడుతుంది.

ఇన్‌పుట్ మరియు అవుట్‌పుట్ మధ్య వ్యవధిని మీరే కొలవండి

ఏదైనా Ubuntu సిస్టమ్‌లో ఈ 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 వచ్చిన వరకు time stamps క్రమంగా పెరుగుతాయి.

ఇప్పుడు దీనికి విరుద్ధమైన ఆకృతిని ప్రయత్నించండి. 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'

Short prompt తో పోలిస్తే మొదటి delta కు ఎక్కువ సమయం పడుతుంది. ఎందుకంటే prefill చదవాల్సిన text చాలా ఎక్కువగా ఉంటుంది. అది వచ్చిన తరువాత response దాదాపు వెంటనే పూర్తవుతుంది. ఎందుకంటే decode చేయాల్సిన tokens కొన్ని మాత్రమే మిగిలి ఉంటాయి. పదివేల tokens ఇన్‌పుట్‌గా వెళ్లినా clock లో మార్పు చాలా తక్కువగా ఉంటుంది. కొన్ని వందల tokens మాత్రమే output గా వచ్చినా clock మొత్తం సమయం నడుస్తుంది.

ప్రతి non-streaming response చివర మీరు చెల్లించాల్సిన usage 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 ప్రకారం charge అవుతుంది. Prompt పంపించే ముందు దాని ధరను అంచనా వేయడానికి POST /v1/messages/count_tokens అదే request body ను స్వీకరించి, model ను run చేయకుండా {"input_tokens": N} ను తిరిగి ఇస్తుంది. దీనికి charge ఉండదు. అయితే charge లేని API భాగం ఇదొక్కటే కాదు. మొదటి project కు budget రూపొందించే ముందు Claude API లో మీకు ఎప్పటికీ charge చేయని భాగాలు పరిశీలించడం ఉపయోగకరం.

ఆగస్టు 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
  }
]

చివరి కాలమ్ output ను input తో భాగించిన నిష్పత్తి. ప్రతి వరుసలో ఇది 5గా ఉంటుంది. Haiku 4.5 కోసం input కు $1, output కు $5 వసూలు చేస్తుంది. Opus 5 కోసం వరుసగా $5 మరియు $25 వసూలు చేస్తుంది. అత్యంత ఖరీదైన Fable 5 కోసం $10 మరియు $50 వసూలు చేస్తుంది. ఆ మొదటి వరుసను పక్కన పెట్టే ముందు ఆ Fable 5 ధరలకు మీకు ఏమి లభిస్తుందో చదవడం ఉపయోగకరం. ఈ శ్రేణిలో పైకి వెళ్లినప్పుడు input, output రెండింటి ధరలు ఒకే గుణకంతో పెరుగుతాయి. అందువల్ల మొత్తం ఖర్చు మారుతుంది, కానీ input నుంచి output కు ఉన్న విభజన మాత్రం అలాగే ఉంటుంది.

Sonnet 5 రెండుసార్లు కనిపిస్తుంది, ఎందుకంటే దాని ప్రారంభ ధర గడువు ముగుస్తుంది. 31 August 2026 వరకు input కు $2, output కు $10 వసూలు చేస్తుంది. 1 September 2026 నుంచి $3 మరియు $15 అనే ప్రామాణిక ధర వర్తిస్తుంది. ఇది రెండు వైపులా 50% ఎక్కువ. దిగువన ఉన్న ప్రతి worked example ఆగస్టు ధరను ఉపయోగిస్తుంది.

ధరలు మారవచ్చు. వాటిని తనిఖీ చేయడానికి ఈ పేజీని ఉపయోగించకండి. 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 తో లెక్కించండి. Claude యొక్క ఒక మిలియన్ tokens వాస్తవ text లో ఎంత విలువ కలిగి ఉంటాయో ఇందులో వివరించబడింది.

మీ బిల్లులో output ఎప్పుడు ప్రధాన భాగంగా మారుతుంది?

output ధర input ధరకు 5 రెట్లు ఉంటే, break-even ను సులభంగా గుర్తుంచుకోవచ్చు. మీ input tokens ను Iగా, output tokens ను Oగా పరిగణించండి. Input ఖర్చు I. Output ఖర్చు Oకు 5 రెట్లు. 5 రెట్లు O, I కంటే ఎక్కువైనప్పుడు output మీ మొత్తం ఖర్చులో సగాన్ని మించుతుంది. అంటే token ratio 5 input : 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 స్థాయిలో ఉంటుంది. చాలామంది తమ స్వంత ratio ను తప్పుగా అంచనా వేస్తారు. కాబట్టి ఏదైనా optimize చేయడానికి ముందు దాన్ని మీ logs నుంచి తీసుకోండి.

ఒక agent workload: దీర్ఘమైన context లోపలికి, చిన్న సమాధానం బయటకు

ఒక retrieval agent దశను తీసుకోండి: retrieved documents మరియు conversation history నుంచి 60,000 input tokens, సమాధానంగా 800 tokens. ఇది 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లో output వాటా 6.25%. మొత్తం price list అంతటా ratio స్థిరంగా ఉండటమే దీనికి కారణం. August rate ప్రకారం, Opus 5లో ఈ call ఖర్చు $0.32, Sonnet 5లో $0.128, Haiku 4.5లో $0.064. Opus 5లో రోజుకు ఇలాంటి 200 దశలు అమలు చేస్తే, రోజుకు $64 ఖర్చవుతుంది.

ఈ విభజనను చూసిన వెంటనే ఏ మార్పు ఎక్కువ ప్రభావం చూపుతుందో స్పష్టమవుతుంది. సమాధానాన్ని 800 tokens నుంచి 400 tokensకు తగ్గిస్తే callలో సుమారు 3% మాత్రమే ఆదా అవుతుంది. prompt నుంచి 20,000 tokens పాత contextను తొలగిస్తే ఖర్చులో సుమారు మూడవ వంతు ఆదా అవుతుంది. Read-heavy agentలో output lengthను తగ్గించడంపై ఎక్కువ దృష్టి పెట్టడం దాదాపు వృథా ప్రయత్నమే. coding agent tokens వాస్తవంగా ఎక్కడ వినియోగిస్తుందో ఆ promptను మొదట నింపేది ఏమిటో వివరిస్తుంది.

జనరేషన్ 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 పై అదే draft కు ధర $0.062. ఈ ఐదు రెట్ల వ్యత్యాసం దాదాపు పూర్తిగా output భాగం వల్లే వస్తుంది. అందువల్ల తక్కువ ధర కలిగిన model ఇక్కడే మీకు ఎక్కువ ఆదా చేస్తుంది.

చివరి column అదే పనిని Batch API ద్వారా చూపిస్తుంది. ఇది input మరియు output రెండింటిపై 50% తగ్గింపు ఇస్తుంది. Opus 5 ధర ప్రతి draft కు $0.155కు తగ్గుతుంది. Batch ఫలితాలను వెంటనే కాకుండా 24 గంటల్లో అందిస్తుంది. కాబట్టి ఇది రాత్రివేళ report generation మరియు bulk classification కు సరిపోతుంది. ఒక వ్యక్తి కూర్చుని ఫలితం కోసం వేచి ఉండే పనులకు ఇది సరిపోదు.

ఇక్కడ model routing ఉపయోగపడుతుంది. Agent దశలో ఇది సాధారణంగా ఉపయోగపడదు. పని యొక్క verbose భాగం యాంత్రికమైనదైతే, ఉదాహరణకు text ను reformat చేయడం లేదా మీరు ఇప్పటికే ఆమోదించిన outline ను విస్తరించడం వంటివి, చౌకైన model ఆ tokens ను ఐదో వంతు ధరకు ఉత్పత్తి చేస్తుంది. Opus, Sonnet మరియు Haiku మధ్య ఎంపికలో నాణ్యత పరిమితి వాస్తవంగా ఎక్కడ ఉందో వివరించాం.

Caching input ను మాత్రమే తగ్గిస్తుంది

Prompt caching మీ prompt లోని ఒక prefix ను server పై నిల్వ చేస్తుంది. దాన్ని మళ్లీ చదివినప్పుడు input rate లోని కొంత భాగం మాత్రమే వసూలు చేస్తుంది. August 2026 నాటికి multipliers ఇలా ఉన్నాయి: 5 minute cache ను write చేయడానికి base input rate కు 1.25x, 1 hour cache ను write చేయడానికి 2x, cache hit ను read చేయడానికి 0.1x.

Output ఈ లెక్కలో ఉండదు. Cached output ఉండదు. Model రాసే ప్రతి token కు, prompt లో ఎంత భాగం cache hit అయినా, ప్రతిసారీ పూర్తి output rate ప్రకారం charge అవుతుంది.

55,000 input tokens లో 60,000 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 bill ను తగ్గించడమే కాకుండా, దాని నిర్మాణాన్ని కూడా మారుస్తుంది. ఆ call లో output వాటా 6.25%. ఇప్పుడు అది call లో నాలుగో వంతుకంటే ఎక్కువగా ఉంది. అందువల్ల తరువాత ఏ ఖర్చు తగ్గింపు చర్య తీసుకోవాలో మారుతుంది.

మొదటి call లో write ఖర్చు చెల్లించాలి. 5 minute cache write కు base input rate యొక్క 1.25x ఖర్చవుతుంది. అందువల్ల ఒక్క hit తర్వాతే దాని ఖర్చు తిరిగి వస్తుంది. 1 hour write కు 2x ఖర్చవుతుంది. అందువల్ల దానికి రెండు hits అవసరం. write మరియు read multipliers, అలాగే caching ఎప్పుడు ప్రయోజనకరంగా ఉండదు ఆ లెక్కను వివరిస్తుంది.

మీ నియంత్రణలో ఉన్న నాలుగు మార్గాలు

1. max_tokens ను model maximum వద్ద కాకుండా మీ p95 output length వద్ద సెట్ చేయండి.
2. ఎక్కువ వివరణ అవసరమైన దశలను చవకైన model కు route చేయండి.
3. ఎవరూ వేచి ఉండని పనులను batch చేయండి.
4. ప్రత్యుత్తరాలను అనవసరంగా పొడిగించే instructions ను తొలగించండి.

max_tokens ఒక కఠినమైన గరిష్ఠ పరిమితి. దీన్ని ఎక్కువగా సెట్ చేసినందుకు మాత్రమే ఖర్చు ఉండదు, ఎందుకంటే ఉత్పత్తి అయిన tokens కు మాత్రమే billing జరుగుతుంది; ceiling కు ఎప్పుడూ billing జరగదు. పెద్ద cap చేయడం వల్ల తప్పుగా సాగిన reply పై ఉన్న పరిమితి తొలగిపోతుంది. మీ logs నుంచి output_tokens distribution ను తీసుకుని, cap ను 95వ percentile కంటే కొద్దిగా ఎక్కువగా సెట్ చేయండి. stop_reason: "max_tokens" ను code లో నిర్వహించండి: response ను కొనసాగించండి లేదా retry చేయండి. మీరు గుర్తించే truncation ఖర్చు, చెల్లించి తర్వాత పారేసే 4,000 token ramble కంటే తక్కువగా ఉంటుంది. Extended thinking కూడా output_tokens లోకి వస్తుంది. కాబట్టి అదే ఆధారాలతో దాని budget ను సెట్ చేయండి.

ఒక దశలో ఖరీదైన భాగం judgement కాకుండా volume అయినప్పుడు routing పనిచేస్తుంది. నిర్ణయం కోసం బలమైన model ను ఉంచి, typing పనిని చవకైనదానికి అప్పగించండి. Routed version ను ముందుగా మీ స్వంత evaluation set పై కొలవండి. రెండు attempts అవసరమయ్యే చవకైన model, ఒక ఖరీదైన 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 మీరు లేకపోతే meter చేసే పనిని కవర్ చేస్తాయా అనే దానిపై ఆధారపడి ఉంటుంది. మీరు ఇప్పటికే session మధ్యలో ఆ limits ను తాకుతుంటే, మీరు ఏ window కోసం వేచి ఉన్నారో తెలుసుకోవడం ముందుగా చేయాలి. అక్కడి నుంచి పరిష్కారం smaller model, lighter context, extra usage credits, లేదా ఆ పనిని metered API పైకి మార్చడం కావచ్చు. Metered API ఆ పనికి చవకైన ఎంపికగా తేలితే, చిన్న plan కు తగ్గడం లేదా దాన్ని cancel చేయడం మీరు ఇప్పటికే చెల్లించిన నెలను ప్రభావితం చేయదు. అందువల్ల మార్పు చేయడం వల్ల అదనపు నష్టం ఉండదు. మీరు metered APIకి బదులుగా ChatGPT యొక్క plan తో Pro ను పోలుస్తుంటే, పక్కపక్కన చూపించిన రెండు subscription ladders ధరలు coding పనికి ఏది చవకగా వస్తుందో చూపిస్తుంది. ఈ ప్రశ్న ఒక developer కోసం కాకుండా team కోసం అడుగుతున్నట్లయితే, Claude Enterprise ప్రతి seat కు fee తో పాటు ఇదే API rates వద్ద metered tokens ను కలుపుతుంది అని గమనించండి. కాబట్టి ఈ పేజీలోని ప్రతి మార్గం ఆ bill లోని metered భాగానికి ఇప్పటికీ వర్తిస్తుంది.

FAQ

అవుట్‌పుట్ tokens కు ఇన్‌పుట్ tokens కంటే ఎక్కువ ఖర్చు ఎందుకు అవుతుంది?

వాటిని ఉత్పత్తి చేయడానికి ప్రతి token కు accelerator సమయం చాలా ఎక్కువగా పడుతుంది. Prompt ను మొత్తం ఒకేసారి forward pass లో ప్రాసెస్ చేస్తారు. అందువల్ల model weights ను ఒక్కసారి చదవడమే వేల tokens కు సరిపోతుంది. ఈ సందర్భంలో hardware పరిమితి multiply throughput అవుతుంది. Reply ను ఒక్కో token చొప్పున ఉత్పత్తి చేస్తారు. ప్రతి token కోసం full model weights ను మళ్లీ చదివే ప్రత్యేక forward pass అవసరం. అందువల్ల ఇక్కడ hardware పరిమితి memory bandwidth అవుతుంది. Haiku 4.5 నుంచి Fable 5 వరకు ప్రస్తుత మొత్తం catalogue లో input కంటే output కు Anthropic 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 కోసం 2x ఖర్చవుతుంది. Cache ఏమి చేసినా, ప్రతి call లో output కు పూర్తి rate వర్తిస్తుంది. అందుకే caching మీ bill పరిమాణాన్ని మాత్రమే కాకుండా దాని నిర్మాణాన్ని కూడా మారుస్తుంది. Input భాగం తగ్గిపోయిన తర్వాత, తగ్గించడానికి ఎక్కువ ప్రాధాన్యం ఉన్న భాగం output అవుతుంది.

Reply చిన్నదిగా వచ్చినా అధిక max_tokens వల్ల నాకు ఖర్చు అవుతుందా?

లేదు. Model వాస్తవంగా ఉత్పత్తి చేసిన tokens కు మాత్రమే మీరు చెల్లిస్తారు. అందువల్ల max_tokens ఒక గరిష్ఠ పరిమితి మాత్రమే; ముందస్తు reservation కాదు. అయినప్పటికీ ఇది ముఖ్యమే, ఎందుకంటే అదుపు తప్పి పొడవుగా సాగే reply కు ఉన్న ఏకైక కఠిన పరిమితి ఇదే. మీరు గమనించిన output_tokens లో 95th percentile కంటే max_tokens ను కొద్దిగా ఎక్కువగా సెట్ చేయండి. ఆ తర్వాత మౌనంగా కత్తిరించబడిన answer ను పంపకుండా, కోడ్‌లో stop_reason: "max_tokens" ను నిర్వహించండి.

నా 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 కు తరలించండి.