Claude मध्ये आउटपुट टोकनची किंमत पाचपट का?

इनपुट टोकनपेक्षा आउटपुट टोकनची किंमत जास्त का असते

सध्याच्या catalogue मधील प्रत्येक Claude model मध्ये आउटपुट टोकनची किंमत इनपुट टोकनच्या किंमतीच्या पाचपट आहे. याचे कारण computation ची रचना आहे. Prompt वाचताना model वर एक pass होतो. उत्तर लिहिताना प्रत्येक token साठी एक pass होतो आणि प्रत्येक pass ला त्यापूर्वीचा pass पूर्ण होईपर्यंत प्रतीक्षा करावी लागते.

Price list मधील प्रत्येक row मध्ये हेच प्रमाण आहे. त्यामुळे तुम्ही निवडलेले model तुमच्या bill मधील आउटपुटचा वाटा बदलत नाही. हे तुमच्या workload च्या रचनेवर अवलंबून असते. 60,000 tokens वाचून 800 tokens मध्ये उत्तर देणाऱ्या agent step मध्ये आउटपुटचा खर्च जवळजवळ नगण्य असतो. 2,000 tokens वाचून 12,000 tokens लिहिणाऱ्या drafting job मध्ये इनपुटचा खर्च जवळजवळ नगण्य असतो. Anthropic ने प्रकाशित केलेल्या August 2026 च्या rates नुसार खाली दोन्ही प्रकरणांची गणना केली आहे.

Prefill एकदाच चालते, तर decoding प्रत्येक token साठी एकदाच चालते

Inference server विनंती दोन टप्प्यांत हाताळतो. या दोन्ही टप्प्यांचा खर्च वेगवेगळा असतो. Prefill prompt वाचते. Decoding उत्तर लिहिते.

Prefill संपूर्ण prompt एकाच वेळी हाताळते. प्रत्येक prompt token एकाच forward pass मध्ये network मध्ये प्रवेश करतो. त्यामुळे attention आणि feed-forward प्रक्रिया एका वेळी हजारो tokens वर होणाऱ्या काही मोठ्या matrix multiplications मध्ये रूपांतरित होते. Model weights memory मधून एकदा वाचले की संपूर्ण prompt हाताळता येतो. Accelerator चे matrix units व्यस्त राहतात. त्यामुळे 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 किती वेगाने हलवता येतात यावर ठरते, multiplication किती वेगाने करता येते यावर नाही. 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 ने ठरवलेला price आहे आणि prefill व decoding मधील या विषमतेचा त्यावर प्रभाव आहे. तुम्ही स्वतः तपासू शकता ती या फरकाची दिशा. त्यासाठी सुमारे एक मिनिट पुरेसे आहे.

स्वतः input आणि output gap मोजा

कोणत्याही Ubuntu बॉक्सवर ही साधने install करा:

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

आता दीर्घ उत्तर मागणारा छोटा prompt stream करा आणि प्रत्येक ओळ आल्याची वेळ नोंदवा.

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 प्रत्येक ओळीच्या सुरुवातीला command सुरू झाल्यापासून गेलेले seconds दाखवते. त्या output मधून दोन गोष्टी समजतात. पहिली content_block_delta ओळ म्हणजे first token मिळेपर्यंतचा तुमचा वेळ आहे आणि संपूर्ण prefill त्याच वेळेत झालेले असते. त्यानंतरची प्रत्येक ओळ decoding मधील एक लहान पायरी असते आणि message_stop येईपर्यंत वेळेच्या नोंदी वाढत जातात.

आता ही रचना उलटी करा. 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 tokens आत गेले, तरी clock barely moved. काही 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 मधील कोणत्या भागांसाठी तुमच्याकडून कधीही शुल्क आकारले जात नाही हे तपासणे उपयुक्त ठरेल.

Claude प्रति दशलक्ष tokens साठी ऑगस्ट 2026 मध्ये आकारत असलेले शुल्क

[
  {
    "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 साठी input चे $10 आणि output चे $50 आकारले जातात. त्यामुळे Fable 5 चे हे दर तुम्हाला प्रत्यक्षात काय देतात हे वाचल्याशिवाय वरच्या ओळीला नाकारू नका. या श्रेणीत वर जाताना दोन्ही बाजू समान गुणकाने वाढतात. त्यामुळे एकूण खर्च बदलतो; परंतु input आणि output यांचे विभाजन जसेच्या तसे राहते.

Sonnet 5 दोनदा दिसतो, कारण त्याचा introductory rate कालबाह्य होतो. 31 August 2026 पर्यंत input चे $2 आणि output चे $10 आकारले जातात. 1 September 2026 पासून $3 input आणि $15 output हा standard rate लागू होतो. दोन्ही बाजूंवरील हा दर 50% अधिक आहे. खालील प्रत्येक उदाहरणात August rate वापरला आहे.

दर बदलतात. त्यामुळे ते तपासण्यासाठी हे पृष्ठ वापरू नका. claude.com/pricing हा अधिकृत स्रोत आहे. दर बदलल्यानंतरही पद्धत तीच राहते.

Price list मध्ये दिसत नसलेली एक महत्त्वाची बाब आहे. Anthropic च्या documentation नुसार Claude 4.7 आणि त्यानंतरचे models नवीन tokenizer वापरतात. त्यामुळे Sonnet 4.6 आणि त्यापूर्वीच्या tokenizer च्या तुलनेत समान मजकुरासाठी अंदाजे 30% अधिक tokens तयार होतात. प्रति दशलक्ष tokens या किमतीवरच दोन models ची तुलना केल्यास नवीन model अधिक फायदेशीर वाटेल. कारण त्यावर तोच document अधिक tokens मध्ये मोजला जातो. प्रत्येक पूर्ण task साठी होणाऱ्या खर्चावर तुलना करा. तसेच प्रत्यक्ष वापरणार असलेल्या model विरुद्ध तुमचे वास्तविक prompts मोजा. प्रत्यक्ष मजकुरात Claude चे दशलक्ष tokens किती मूल्याचे आहेत यात ही मात्रा व्यवहारात कशी दिसते हे स्पष्ट केले आहे.

आउटपुटचा खर्च तुमच्या एकूण बिलावर कधी प्रमुख ठरतो?

इनपुटच्या 5 पट दराने आउटपुटची किंमत ठरत असल्यास, break-even गुणोत्तर सहज लक्षात ठेवता येते. तुमचे input tokens I आणि output tokens O असे मानू. इनपुटची किंमत I इतकी आहे. आउटपुटची किंमत O च्या 5 पट आहे. 5 पट O हे I पेक्षा मोठे झाल्यावर तुमच्या एकूण खर्चापैकी निम्म्यापेक्षा जास्त खर्च आउटपुटचा असतो. यासाठी token ratio 5 input ते 1 output असे आहे.

म्हणून तुमचा prompt उत्तरापेक्षा पाच पटांहून अधिक मोठा असल्यास, खर्चातील मोठा घटक इनपुट असतो. त्यापेक्षा कमी गुणोत्तर असल्यास आउटपुट असतो.

[
  {
    "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 या गुणोत्तरात, एकूण खर्चापैकी आउटपुटचा वाटा 4.8% असतो. त्यामुळे prompt लहान करणे हेच करण्यासारखे महत्त्वाचे काम असते. 5 ते 1 या गुणोत्तरात दोन्ही बाजू समान असतात. 1 ते 6 या गुणोत्तरात आउटपुटचा वाटा 96.8% असतो आणि prompt चा परिणाम rounding error इतकाच राहतो. बहुतेक लोक स्वतःचे गुणोत्तर चुकीचे गृहीत धरतात. त्यामुळे कोणतेही optimization करण्यापूर्वी ते logs मधून काढा.

एजंट workload: मोठा context आत, लहान उत्तर बाहेर

एक retrieval agent step घ्या: retrieved documents आणि conversation history चे 60,000 input 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 वर output हा त्या call च्या 6.25% इतका आहे, कारण संपूर्ण price list मध्ये हे ratio निश्चित आहे. August rate नुसार Opus 5 वर या call ची किंमत $0.32, Sonnet 5 वर $0.128, आणि Haiku 4.5 वर $0.064 आहे. Opus 5 वर दररोज असे 200 steps घेतल्यास दररोज $64 खर्च येतो.

हा विभाजन पाहिल्यावर कोणता बदल करायचा ते स्पष्ट होते. उत्तर 800 tokens वरून 400 tokens केल्यास call च्या खर्चात सुमारे 3% बचत होते. Prompt मधून stale context चे 20,000 tokens काढल्यास खर्चात सुमारे एक-तृतीयांश बचत होते. 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
  }
]

या बिलाच्या 96.8% इतका खर्च output चा आहे. Opus 5 च्या प्रत्येक draft साठी $0.31 खर्च येतो, तर Haiku 4.5 साठी $0.062 खर्च येतो. हा पाचपट फरक जवळजवळ पूर्णपणे output मुळे आहे. त्यामुळे स्वस्त model वापरल्यास सर्वाधिक बचत याच ठिकाणी होते.

शेवटचा column Batch API द्वारे याच कामाचा खर्च दाखवतो. Batch API input आणि output या दोन्हींवर 50% सवलत देते. त्यामुळे Opus 5 चा खर्च प्रति draft $0.155 इतका होतो. Batch API निकाल त्वरित न देता 24 तासांच्या आत देते. त्यामुळे रात्री report generation आणि मोठ्या प्रमाणातील classification साठी ते योग्य आहे. एखादी व्यक्ती निकालाची वाट पाहत बसलेली असेल, अशा कामासाठी ते योग्य नाही.

Model routing चा फायदा येथे होतो; agent step मध्ये तो कधीच होत नाही. कामाचा verbose भाग यांत्रिक असेल, उदाहरणार्थ आधीच मंजूर केलेला मजकूर reformat करणे किंवा outline विस्तृत करणे, तर स्वस्त model त्या tokens चा खर्च पाचपट कमी ठेवते. Opus, Sonnet आणि Haiku यांपैकी निवड यामध्ये प्रत्यक्ष quality threshold कुठे आहे हे स्पष्ट केले आहे.

कॅशिंगमुळे फक्त 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 ने billed होतो. Prompt चा कितीही भाग cache hit म्हणून परत आला तरी हे बदलत नाही.

Opus 5 वर तोच agent step घ्या. त्यातील 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
  }
]

हा call $0.32 वरून $0.0725 पर्यंत कमी होतो. Output ची रक्कम बदलत नाही: आधी $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 फायदेशीर राहात नाही ते ठिकाण या गणनेचे स्पष्टीकरण देते.

तुमच्या नियंत्रणातील चार उपाय

1. max_tokens मॉडेलच्या कमाल मर्यादेवर नव्हे, तर तुमच्या p95 आउटपुट लांबीवर सेट करा.
2. जास्त मजकूर निर्माण करणारी पावले स्वस्त मॉडेलकडे पाठवा.
3. ज्याची कोणी वाट पाहत नाही ते सर्व batch मध्ये चालवा.
4. प्रतिसादाची लांबी वाढवणाऱ्या सूचना काढून टाका.

max_tokens ही कठोर कमाल मर्यादा आहे. ती जास्त ठेवली म्हणून स्वतःहून कोणताही खर्च होत नाही, कारण बिल तयार झालेल्या tokens साठी आकारले जाते; या मर्यादेसाठी कधीही आकारले जात नाही. उदार cap मुळे चुकीच्या दिशेने गेलेल्या प्रतिसादावरील मर्यादा काढली जाते. तुमच्या logs मधून output_tokens distribution काढा, cap 95th percentile पेक्षा थोडी जास्त ठेवा आणि stop_reason: "max_tokens" कोडमध्ये हाताळा: प्रतिसाद पुढे सुरू ठेवा किंवा पुन्हा प्रयत्न करा. तुम्ही ओळखलेले truncation, पैसे देऊन फेकून द्याव्या लागणाऱ्या 4,000 tokenच्या अनावश्यक लांबलचक प्रतिसादापेक्षा स्वस्त असते. Extended thinking देखील output_tokens मध्ये समाविष्ट होते. त्यामुळे तो budget त्याच पुराव्यावरून सेट करा.

एखाद्या step चा महागडा भाग निर्णयक्षमता नसून volume असेल, तेव्हा routing उपयोगी ठरते. निर्णयासाठी सक्षम मॉडेल ठेवा आणि मजकूर टाइप करण्याचे काम स्वस्त मॉडेलकडे द्या. Routed version आधी तुमच्या स्वतःच्या evaluation set वर मोजा, कारण दोन प्रयत्नांची गरज असलेल्या स्वस्त मॉडेलचा खर्च एका महागड्या प्रयत्नापेक्षा जास्त होऊ शकतो.

Output वर discount देणारा एकमेव उपाय batching आहे. दोन्ही बाजूंवर 50% सूट, 24 तासांच्या आत results आणि schedule वर चालणारे कोणतेही काम यासाठी पात्र ठरते.

शेवटचा उपाय लोक अनेकदा टाळतात. "be thorough" आणि "explain your reasoning" यांसारखी वाक्ये तुम्ही पुढे करणार असलेल्या प्रत्येक call ची output length वाढवतात. त्याऐवजी अपेक्षित स्वरूप स्पष्ट सांगा: "Answer in at most three sentences" किंवा "Return only the JSON object, with no preamble". प्रत्येक प्रतिसादात 300 tokens वाढवणाऱ्या system prompt चा खर्च, prompt मध्ये त्याच 300 tokens च्या खर्चाच्या पाचपट असतो. चालू agent चा खर्च नियंत्रणात ठेवणे या विषयात monitoring बाजूचा समावेश आहे. तसेच तुमच्या वापराच्या पद्धतीसाठी API स्वस्त आहे की flat subscription हा प्रश्नही ठरवा. Subscription मुळे शोषला जाणारा per-token खर्च सुधारण्यासाठी एक आठवडा घालवण्यापूर्वी हा निर्णय घेणे योग्य ठरते. एका developer साठी हा प्रश्न मुख्यतः Claude Pro चे दरमहा $20 शुल्क आणि त्यासोबतच्या usage limits तुमच्या अन्यथा metering कराव्या लागणाऱ्या कामासाठी पुरेसे आहेत का, यावर येतो. तुम्ही sessionच्या मध्यातच त्या limits गाठत असाल, तर तुम्ही कोणत्या window ची वाट पाहत आहात हे ठरवणे आधी करा. त्यानंतरचा उपाय smaller model, lighter context, extra usage credits किंवा ते काम metered API वर हलवणे असा असू शकतो. Metered API त्या कामासाठी स्वस्त पर्याय ठरल्यास, smaller plan वर जाणे किंवा तो cancel करणे यामुळे तुम्ही आधीच भरलेला महिना अबाधित राहतो. त्यामुळे बाहेर पडताना switch करण्यासाठी कोणताही अतिरिक्त खर्च होत नाही. तुम्ही metered API ऐवजी ChatGPT च्या plan ची Pro सोबत तुलना करत असाल, तर दोन्ही subscription ladders ची शेजारी शेजारी दिलेली किंमत 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 मध्ये संपूर्ण मजकुरावर प्रक्रिया होते. त्यामुळे model weights चे एकदाच वाचन हजारो tokens साठी पुरते आणि hardware ची मर्यादा multiply throughput वर येते. Reply मात्र एका वेळी एक token तयार केली जाते. प्रत्येक token साठी संपूर्ण model weights पुन्हा वाचणारा स्वतंत्र forward pass आवश्यक असतो. त्यामुळे hardware ची मर्यादा memory bandwidth वर येते. Anthropic च्या सध्याच्या संपूर्ण catalogue मध्ये, Haiku 4.5 पासून Fable 5 पर्यंत, output ची किंमत input च्या पाचपट आहे.

Prompt caching मुळे output tokens स्वस्त होतात का?

नाही. Prompt caching फक्त input ला लागू होते. August 2026 पर्यंत cache read साठी base input rate च्या 0.1x इतका खर्च येतो. 5 minute duration साठी cache writes ची किंमत 1.25x आणि 1 hour duration साठी 2x असते. Cache ने काहीही केले तरी प्रत्येक call मध्ये output साठी पूर्ण दर आकारला जातो. म्हणून caching मुळे तुमच्या bill चा आकारच नव्हे, तर त्यातील खर्चाचे प्रमाणही बदलते. Input चा खर्च कमी झाल्यावर output हा कमी करण्यास सर्वाधिक महत्त्वाचा भाग ठरतो.

Reply लहान आली तर उच्च max_tokens मुळे माझ्याकडून पैसे आकारले जातात का?

नाही. Model प्रत्यक्षात निर्माण करतो त्या tokens साठीच तुमच्याकडून शुल्क आकारले जाते. त्यामुळे max_tokens ही कमाल मर्यादा आहे; ती आगाऊ राखीव संख्या नाही. तरीही ती महत्त्वाची आहे, कारण अनियंत्रितपणे वाढणाऱ्या reply वर असलेली ती एकमेव कठोर मर्यादा आहे. निरीक्षणातून मिळालेल्या output_tokens च्या 95th percentile पेक्षा ती थोडी जास्त ठेवा. त्यानंतर code मध्ये stop_reason: "max_tokens" हाताळा. अशा प्रकारे उत्तर शांतपणे अपूर्ण राहून deploy होणार नाही.

माझे input ते output token ratio कसे शोधू?

प्रत्येक response च्या usage object मधून input_tokens, output_tokens, cache_read_input_tokens आणि cache_creation_input_tokens log करा. त्यानंतर एका आठवड्यातील एकूण संख्यांचा भागाकार करा. Input ते output प्रमाण 5 ते 1 पेक्षा जास्त असल्यास तुमचा खर्च prompt मध्ये आहे. त्यामुळे स्थिर भाग cache करा आणि उर्वरित भाग कमी करा. हे प्रमाण त्यापेक्षा कमी असल्यास तुमचा खर्च reply मध्ये आहे. त्यामुळे त्याची लांबी मर्यादित करा आणि सर्वाधिक output निर्माण करणाऱ्या पायऱ्या स्वस्त model किंवा Batch API कडे हलवा.