Claude मध्ये आउटपुट टोकन्स महाग का असतात?

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

सध्याच्या कॅटलॉग मधील प्रत्येक Claude मॉडेलवर आउटपुट टोकन्सची किंमत इनपुट टोकन्सच्या पाचपट आहे. याचे कारण गणनेची (computation) पद्धत आहे. प्रॉम्प्ट वाचणे ही मॉडेलवरची एकच प्रक्रिया (pass) असते. उत्तर लिहिताना मात्र प्रत्येक टोकनसाठी एक स्वतंत्र प्रक्रिया करावी लागते आणि प्रत्येक प्रक्रियेला तिच्या आधीच्या प्रक्रियेची वाट पाहावी लागते.

किमतीच्या यादीतील प्रत्येक ओळीवर हे प्रमाण सारखेच आहे, त्यामुळे तुम्ही निवडलेले मॉडेल तुमच्या बिलातील आउटपुटचा हिस्सा बदलत नाही. तुमच्या वर्कलोडचे स्वरूप हे ठरवते. एखादी एजंट स्टेप जी 60,000 टोकन्स वाचते आणि 800 टोकन्समध्ये उत्तर देते, तिचा आउटपुट खर्च नगण्य असतो. याउलट, एखादे ड्राफ्टिंगचे काम जे 2,000 टोकन्स वाचते आणि 12,000 टोकन्स लिहिते, त्याचा इनपुट खर्च नगण्य असतो. दोन्ही उदाहरणे खाली Anthropic च्या ऑगस्ट 2026 च्या प्रसिद्ध दरांवर आधारित स्पष्ट केली आहेत.

Prefill एकदाच चालते, Decoding प्रत्येक टोकनसाठी एकदा चालते

इन्फरन्स सर्व्हर विनंतीवर दोन टप्प्यांत प्रक्रिया करतो, ज्यांचा खर्च खूप वेगळा असतो. Prefill प्रॉम्प्ट वाचते. Decoding उत्तर लिहिते.

Prefill संपूर्ण प्रॉम्प्ट एकाच वेळी घेते. प्रत्येक प्रॉम्प्ट टोकन एकाच फॉरवर्ड पासमध्ये नेटवर्कमध्ये प्रवेश करते, त्यामुळे अटेंशन आणि फीड-फॉरवर्डचे काम हे एकाच वेळी हजारो टोकन्सवर प्रक्रिया करणाऱ्या काही मोठ्या मॅट्रिक्स मल्टिप्लिकेशनमध्ये रूपांतरित होते. मेमरीमधून मॉडेल वेट्सचे (model weights) एक वाचन संपूर्ण प्रॉम्प्टसाठी पुरेसे ठरते. ॲक्सिलरेटरचे मॅट्रिक्स युनिट्स व्यस्त राहतात, याचा अर्थ असा की Prefill ही 'कम्प्युट-बाउंड' (compute-bound) प्रक्रिया आहे: चिप किती वेगाने गुणाकार करू शकते, यावर तिची मर्यादा असते.

Decoding अशा प्रकारे काम करू शकत नाही, कारण दुसरे टोकन पहिल्या टोकनवर अवलंबून असते. मॉडेलने नुकतेच तयार केलेले टोकन पुढील पायरीच्या इनपुटचा भाग बनते, त्यामुळे या पायऱ्या एकाच वेळी चालवता येत नाहीत. प्रत्येक आउटपुट टोकनसाठी स्वतंत्र फॉरवर्ड पास लागतो आणि या प्रत्येक पासमध्ये एकच टोकन तयार करण्यासाठी हाय-बँडविड्थ मेमरीमधून मॉडेल वेट्सचा संपूर्ण संच वाचावा लागतो. यामुळे Decoding ही 'मेमरी-बाउंड' (memory-bound) प्रक्रिया बनते: वेट्स किती वेगाने हलवले जाऊ शकतात, यावर तिची मर्यादा असते, गुणाकार किती वेगाने होतात यावर नाही. Prefill दरम्यान संपूर्ण प्रॉम्प्टसाठी वापरलेला वेट ट्रॅफिक Decoding मध्ये फक्त एक टोकन मिळवून देतो.

सर्व्हिंग सिस्टिम्स बॅचिंगद्वारे (batching) यावर उपाय करतात. अनेक विनंत्या एकत्र डिकोड केल्या जातात, त्यामुळे वेट्सचे एक वाचन बॅचमधील प्रत्येक विनंतीसाठी एक टोकन तयार करते. म्हणूनच Decoding परवडण्यासारखे असते. येथेही मेमरीची मर्यादा येते. चालू असलेली प्रत्येक विनंती KV cache (key/value cache, आतापर्यंतच्या प्रत्येक टोकनसाठी साठवलेली अटेंशन स्टेट) धारण करते, प्रत्येक नवीन टोकनसह हा कॅशे वाढत जातो आणि जेव्हा तो ॲक्सिलरेटर भरतो, तेव्हा बॅचची व्याप्ती वाढवता येत नाही.

यापैकी कशावरूनही तुम्हाला अचूक आकडा मिळणार नाही आणि 5x कडे मोजलेले हार्डवेअर गुणोत्तर म्हणून पाहू नका. ही एक किंमत आहे, जी Anthropic ने ठरवली आहे आणि ती या विषमतेवर आधारित आहे. तुम्ही स्वतः काय तपासू शकता, ती म्हणजे दिशा, आणि यासाठी साधारण एक मिनिट लागतो.

इनपुट आणि आउटपुटमधील तफावत स्वतः मोजा

कोणत्याही Ubuntu मशीनवर खालील टूल्स इन्स्टॉल करा:

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

आता एक छोटा प्रॉम्प्ट स्ट्रीम करा जो लांबलचक उत्तराची मागणी करतो आणि प्रत्येक ओळीवर ती मिळाल्याची वेळ नोंदवा.

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 प्रत्येक ओळीच्या सुरुवातीला कमांड सुरू झाल्यापासूनचा वेळ सेकंदात दर्शवते. या आउटपुटमधून दोन गोष्टी समजून घेणे महत्त्वाचे आहे. पहिली content_block_delta ओळ म्हणजे तुमचा 'टाइम टू फर्स्ट टोकन' (TTFT) आहे आणि सर्व प्रीफिल (prefill) याच कालावधीत पूर्ण झाले आहे. त्यानंतरची प्रत्येक ओळ डिकोडिंगची एक छोटी पायरी आहे आणि message_stop येईपर्यंत हे टाइमस्टॅम्प वाढत राहतात.

आता याची उलट स्थिती तपासा. प्रॉम्प्टमध्ये एक मोठा दस्तऐवज टाका आणि उत्तरावर काही टोकन्सची मर्यादा घाला.

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'

पहिला डेल्टा (delta) छोट्या प्रॉम्प्टच्या तुलनेत जास्त वेळ घेतो, कारण प्रीफिलला वाचण्यासाठी खूप जास्त मजकूर असतो. तो मिळाल्यानंतर प्रतिसाद लगेच संपतो, कारण डिकोड करण्यासाठी फक्त काहीच टोकन्स शिल्लक असतात. हजारो टोकन्स इनपुटमध्ये गेले तरी घड्याळाचा काटा फारसा हलला नाही. काही शे टोकन्स आउटपुटमध्ये आले आणि घड्याळ पूर्ण वेळ चालत राहिले.

प्रत्येक नॉन-स्ट्रीमिंग प्रतिसाद शेवटी त्या आकड्यांसह संपतो ज्यासाठी तुम्हाला बिल आकारले जाते.

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

प्रत्येक विनंतीसाठी चारही फील्ड्स लॉग करा. output_tokens मध्ये विस्तारित विचारांचा (extended thinking) समावेश असतो, त्यामुळे जो मॉडेल उत्तर देण्यापूर्वी विचार करतो, तो त्या विचारांसाठी आउटपुट दराने बिल आकारतो. एखादा प्रॉम्प्ट पाठवण्यापूर्वी त्याची किंमत मोजण्यासाठी, POST /v1/messages/count_tokens त्याच विनंतीचा बॉडी स्वीकारते, मॉडेल न चालवता {"input_tokens": N} परत करते आणि हे मोफत आहे. API चा हा एकमेव भाग नाही जो मोफत आहे, आणि Claude API चे कोणते भाग तुम्हाला कधीही बिल केले जात नाहीत हे तुमच्या पहिल्या प्रोजेक्टचे बजेट ठरवण्यापूर्वी तपासणे फायदेशीर ठरेल.

ऑगस्ट 2026 पर्यंत 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
  }
]

शेवटचा र कॉलम आउटपुटला इनपुटने भागून मिळतो आणि तो प्रत्येक ओळीवर 5 असा दिसतो. Haiku 4.5 साठी इनपुटचे दर $1 आणि आउटपुटचे दर $5 आहेत. Opus 5 साठी हे दर अनुक्रमे $5 आणि $25 आहेत. Fable 5, जे सर्वात महाग आहे, त्याचे दर $10 आणि $50 आहेत, आणि वरची ओळ विचारात घेण्यापूर्वी Fable 5 चे दर तुम्हाला काय देतात हे वाचणे फायदेशीर ठरेल. श्रेणीमध्ये वर जाताना दोन्ही बाजू एकाच फॅक्टरने गुणल्या जातात, त्यामुळे एकूण खर्चात बदल होतो पण इनपुट आणि आउटपुटचे गुणोत्तर मात्र स्थिर राहते.

Sonnet 5 दोनदा दिसते कारण त्याचा सुरुवातीचा दर संपणार आहे. 31 ऑगस्ट 2026 पर्यंत त्याचे दर $2 आणि $10 आहेत. 1 सप्टेंबर 2026 पासून $3 आणि $15 हे मानक दर लागू होतील, जे दोन्ही बाजूंनी 50% जास्त आहेत. खाली दिलेली प्रत्येक उदाहरणे ऑगस्टच्या दरांचा वापर करतात.

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

किमतींच्या यादीत एक गोष्ट नमूद केलेली नाही. Anthropic च्या दस्तऐवजानुसार, Claude 4.7 आणि त्यानंतरचे मॉडेल्स नवीन टोकेनायझर वापरतात, जे Sonnet 4.6 आणि त्यापूर्वीच्या टोकेनायझरच्या तुलनेत त्याच मजकुरासाठी सुमारे 30% जास्त टोकन्स तयार करतात. केवळ प्रति दशलक्ष टोकन्सच्या किमतीवर आधारित दोन मॉडेल्सची तुलना केल्यास नवीन मॉडेल स्वस्त वाटू शकते, कारण त्याच दस्तऐवजासाठी त्यात जास्त टोकन्स मोजले जातात. पूर्ण झालेल्या कार्यासाठी लागणाऱ्या खर्चावर आधारित तुलना करा आणि तुम्ही वापरणार असलेल्या मॉडेलवर तुमच्या प्रत्यक्ष प्रॉम्प्ट्सची गणना करा. हाच फरक विविध सेवा पुरवठादारांमध्येही असतो, ज्यांचे टोकेनायझर्स एकमेकांपेक्षा अधिक भिन्न असतात, म्हणून Claude आणि ChatGPT या दोन्हीवर प्रत्यक्ष कामाचा खर्च काढणे हे केवळ दोन दरपत्रके शेजारी ठेवण्यापेक्षा अधिक माहितीपूर्ण ठरते. दशलक्ष Claude टोकन्स म्हणजे प्रत्यक्ष मजकुरात किती हे प्रत्यक्षात ते प्रमाण कसे दिसते हे स्पष्ट करते.

आउटपुटचा खर्च बिलावर कधी प्रभावी ठरू लागतो?

आउटपुटची किंमत इनपुटच्या 5 पट असल्याने, ब्रेक-इव्हन पॉईंट लक्षात ठेवणे सोपे आहे. तुमच्या इनपुट टोकन्सना I आणि आउटपुट टोकन्सना O म्हणा. इनपुटचा खर्च I आहे. आउटपुटचा खर्च 5 गुणिले O आहे. जेव्हा 5 गुणिले O हे I पेक्षा जास्त असते, तेव्हा आउटपुटचा खर्च एकूण खर्चाच्या निम्म्याहून अधिक होतो; हे गुणोत्तर 5 इनपुट टोकन्समागे 1 आउटपुट टोकन असे आहे.

त्यामुळे, जर तुमचा प्रॉम्प्ट तुमच्या उत्तरापेक्षा पाच पटीने मोठा असेल, तर इनपुटचा खर्च हा बिलातील मोठा घटक ठरतो. त्यापेक्षा कमी गुणोत्तर असल्यास, आउटपुटचा खर्च मोठा ठरतो.

[
  {
    "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% असतो आणि अशा वेळी फक्त प्रॉम्प्ट कमी करणे फायदेशीर ठरते. 5 ते 1 या गुणोत्तरावर दोन्ही बाजूंचा खर्च समान असतो. 1 ते 6 या गुणोत्तरावर, आउटपुटचा खर्च 96.8% असतो आणि प्रॉम्प्टचा खर्च नगण्य असतो. बहुतेक लोक त्यांच्या स्वतःच्या गुणोत्तराचा अंदाज चुकीचा लावतात, त्यामुळे कोणत्याही गोष्टीचे ऑप्टिमायझेशन करण्यापूर्वी तुमच्या लॉग्समधून अचूक माहिती मिळवा.

एजंट वर्कलोड: मोठा संदर्भ इनपुट, संक्षिप्त उत्तर आउटपुट

एजंटच्या रिट्रीव्हल पायरीचे एक उदाहरण घेऊ: 60,000 इनपुट टोकन्स (मिळवलेली कागदपत्रे आणि संभाषणाचा इतिहास) आणि 800 टोकन्सचे उत्तर. हे प्रमाण 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
  }
]

प्रत्येक मॉडेलवर त्या कॉलचा आउटपुट हिस्सा 6.25% असतो, कारण हे प्रमाण संपूर्ण किंमत सूचीमध्ये निश्चित आहे. या कॉलची किंमत Opus 5 वर $0.32, ऑगस्टच्या दराप्रमाणे Sonnet 5 वर $0.128 आणि Haiku 4.5 वर $0.064 इतकी आहे. Opus 5 वर अशा दिवसाच्या दोनशे पायऱ्यांसाठी $64 खर्च येतो.

एकदा का तुम्ही हे विभाजन पाहिले की, मुख्य उपाय स्पष्ट होतो. उत्तराची लांबी 800 टोकन्सवरून 400 टोकन्सवर कमी केल्यास कॉलच्या खर्चात केवळ 3% बचत होते. मात्र, प्रॉम्प्टमधून 20,000 टोकन्सचा जुना संदर्भ काढून टाकल्यास खर्चात सुमारे एक तृतीयांश बचत होते. त्यामुळे, वाचनावर आधारित एजंटसाठी आउटपुटची लांबी कमी करणे हा फारसा प्रभावी प्रयत्न नाही. कोडिंग एजंटचे टोकन्स नक्की कुठे खर्च होतात हे विश्लेषण प्रॉम्प्टमध्ये नेमके काय भरले जाते, याचे सविस्तर वर्णन करते.

वर्कलोड जनरेशन: संक्षिप्त प्रॉम्प्ट, विस्तृत मसुदा

आता या रचनेची उलट बाजू पाहू. 2,000 टोकनचा संक्षिप्त आराखडा आणि 12,000 टोकनचा मसुदा, म्हणजे 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% इतके आहे. Opus 5 चा खर्च प्रति मसुदा $0.31 येतो, तर Haiku 4.5 वर तो $0.062 इतका आहे. हा पाचपट फरक प्रामुख्याने आउटपुट बाजूमुळे निर्माण होतो, आणि नेमक्या याच ठिकाणी स्वस्त मॉडेल वापरल्याने सर्वाधिक बचत होते.

शेवटचा रकाना Batch API द्वारे केलेल्या याच कामाचा आहे, ज्यामध्ये इनपुट आणि आउटपुटवर 50% सवलत मिळते. Opus 5 चा खर्च प्रति मसुदा $0.155 पर्यंत खाली येतो. Batch मध्ये निकाल त्वरित न मिळता 24 तासांच्या आत मिळतात, त्यामुळे हे रात्रीच्या वेळी तयार होणारे अहवाल किंवा मोठ्या प्रमाणावरील वर्गीकरणासाठी योग्य आहे. जिथे वापरकर्ता निकालाची वाट पाहत बसला आहे, अशा कामांसाठी हे उपयुक्त नाही.

एजंट स्टेपच्या तुलनेत मॉडेल राउटिंगचा फायदा इथे अधिक स्पष्टपणे दिसून येतो. जर कामाचा विस्तृत भाग यांत्रिक स्वरूपाचा असेल, जसे की मजकुराचे फॉरमॅटिंग करणे किंवा तुम्ही आधीच मंजूर केलेल्या आराखड्याचा विस्तार करणे, तर स्वस्त मॉडेल हे टोकन्स पाचपट कमी किमतीत तयार करते. Opus, Sonnet आणि Haiku मधील निवड या विषयावर गुणवत्तेची नेमकी पातळी कुठे आहे, हे स्पष्ट केले आहे.

केवळ इनपुटवर कॅशिंग सवलती

प्रॉम्प्ट कॅशिंग तुमच्या प्रॉम्प्टचा एक भाग सर्व्हरवर स्टोअर करते आणि तो पुन्हा वाचण्यासाठी इनपुट दराच्या काही अंश शुल्क आकारते. ऑगस्ट 2026 पर्यंत, 5 मिनिटांच्या कॅशेसाठी 1.25 पट, 1 तासाच्या कॅशेसाठी 2 पट आणि हिट वाचण्यासाठी 0.1 पट असे मल्टिप्लायर्स आहेत.

आउटपुट या कराराचा भाग नाही. कोणतेही कॅश केलेले आउटपुट नसते. मॉडेल जे काही टोकन्स लिहिते, त्या प्रत्येकासाठी पूर्ण आउटपुट दराने शुल्क आकारले जाते, मग प्रॉम्प्टचा कितीही भाग कॅश हिट म्हणून परत आला असला तरीही.

Opus 5 वर तीच एजंट स्टेप घ्या, जिथे 60,000 पैकी 55,000 इनपुट टोकन्स वॉर्म कॅशेमधून सर्व्ह केले जातात.

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

या कॉलचा खर्च $0.32 वरून कमी होऊन $0.0725 होतो. आउटपुटची ओळ बदलत नाही: आधी $0.02, नंतर $0.02. कॅशिंगमुळे बिल कमी होते आणि त्याचे स्वरूप बदलते. त्या कॉलमध्ये आउटपुटचा वाटा 6.25% होता. आता तो एक चतुर्थांशाहून अधिक झाला आहे, ज्यामुळे भविष्यात कोणता उपाय करणे फायदेशीर ठरेल हे बदलते.

पहिला कॉल राईटसाठी पैसे देतो. 5 मिनिटांच्या कॅशे राईटचा खर्च 1.25 पट बेस इनपुट असतो, त्यामुळे एका हिटनंतर तो स्वतःचा खर्च वसूल करतो. 1 तासाच्या राईटचा खर्च 2 पट असतो, त्यामुळे त्यासाठी दोन हिट्सची गरज असते. राईट आणि रीड मल्टिप्लायर्स, आणि कॅशिंग कुठे फायदेशीर ठरत नाही यामध्ये हे गणित स्पष्ट केले आहे.

नियंत्रणासाठी चार मार्ग

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

max_tokens ही एक कडक मर्यादा आहे. ती जास्त सेट केल्याने स्वतःहून कोणताही खर्च वाढत नाही, कारण तुम्हाला तयार झालेल्या टोकन्ससाठी बिल आकारले जाते, मर्यादेसाठी नाही. उदार मर्यादा ठेवल्याचा फायदा असा की, उत्तर चुकल्यास त्यावर कोणतीही मर्यादा राहत नाही. तुमच्या लॉग्समधून output_tokens चे वितरण तपासा, ही मर्यादा 95 व्या पर्सेंटाइलच्या थोडी वर सेट करा आणि stop_reason: "max_tokens" हाताळण्यासाठी कोडमध्ये रिस्पॉन्स सुरू ठेवण्याची किंवा पुन्हा प्रयत्न करण्याची सोय करा. तुम्ही शोधलेली ट्रंकेशन (truncation) ही 4,000 टोकन्सच्या निरर्थक बडबडीपेक्षा स्वस्त पडते, ज्यासाठी तुम्ही पैसे देता आणि शेवटी ती माहिती फेकून देता. विस्तारित विचार (extended thinking) देखील output_tokens मध्येच येतो, त्यामुळे त्याच पुराव्यांच्या आधारे त्याचे बजेट ठरवा.

जेव्हा एखाद्या पायरीचा खर्च हा निर्णयापेक्षा त्याच्या आकारमानावर (volume) अवलंबून असतो, तेव्हा राउटिंग प्रभावी ठरते. निर्णय घेण्याचे काम शक्तिशाली मॉडेलकडे ठेवा आणि टायपिंगचे काम स्वस्त मॉडेलकडे सोपवा. राउटिंग केलेल्या आवृत्तीचे मूल्यमापन आधी स्वतःच्या टेस्ट सेटवर करा, कारण स्वस्त मॉडेलला जर दोनदा प्रयत्न करावे लागले, तर ते एका महागड्या प्रयत्नापेक्षा जास्त खर्चिक ठरते.

बॅचिंग हा एकमेव मार्ग आहे जो आउटपुटवर सवलत देतो. यात दोन्ही बाजूंनी 50% सवलत मिळते, निकाल 24 तासांच्या आत मिळतात आणि वेळापत्रकानुसार होणारी कोणतीही कामे यासाठी पात्र ठरतात.

शेवटचा मार्ग असा आहे जो लोक सहसा दुर्लक्षित करतात. "सविस्तर माहिती द्या" किंवा "तुमचे तर्क स्पष्ट करा" यांसारखी वाक्ये तुम्ही प्रत्येक कॉलमध्ये आउटपुटची लांबी वाढवतात. त्याऐवजी तुम्हाला हवा तसा फॉरमॅट वापरा: "जास्तीत जास्त तीन वाक्यांत उत्तर द्या" किंवा "कोणतीही प्रस्तावना न देता फक्त JSON ऑब्जेक्ट परत करा". सिस्टिम प्रॉम्प्ट जो प्रत्येक उत्तरात 300 टोकन्स वाढवतो, तो प्रॉम्प्टमध्ये असलेल्या त्याच 300 टोकन्सपेक्षा पाचपट महाग पडतो. एजंटचा खर्च नियंत्रणात ठेवणे हे मॉनिटरिंगच्या बाजूने माहिती देते, आणि तुमच्या वापराच्या पद्धतीसाठी API स्वस्त आहे की फ्लॅट सबस्क्रिप्शन हे ठरवणे महत्त्वाचे आहे, जेणेकरून तुम्ही सबस्क्रिप्शनमध्ये समाविष्ट असलेल्या गोष्टींसाठी टोकन-आधारित खर्च कमी करण्यात वेळ वाया घालवणार नाही. एका डेव्हलपरसाठी हे प्रामुख्याने Claude Pro चे $20 प्रति महिना आणि त्यासोबत येणाऱ्या वापराच्या मर्यादा तुमच्या कामासाठी पुरेशा आहेत का, यावर अवलंबून असते. जर तुम्ही त्या मर्यादांपर्यंत पोहोचत असाल, तर तुम्ही कोणत्या विंडोची वाट पाहत आहात हे शोधणे प्रथम महत्त्वाचे आहे, कारण त्यावर उपाय म्हणून लहान मॉडेल, हलका संदर्भ, अतिरिक्त युसेज क्रेडिट्स किंवा ते काम metered API वर हलवणे हे पर्याय उपलब्ध असतात. जर metered API हे त्या कामासाठी स्वस्त पर्याय ठरत असेल, तर लहान प्लॅनवर जाणे किंवा सबस्क्रिप्शन रद्द करणे तुम्हाला फायदेशीर ठरते, कारण तुम्ही आधीच भरलेले पैसे वाया जात नाहीत. जर तुम्ही Pro सबस्क्रिप्शनची तुलना ChatGPT शी करत असाल, तर दोन सबस्क्रिप्शन प्लॅनची तुलना कोडिंगच्या कामासाठी कोणता स्वस्त आहे हे स्पष्ट करते. जर हा प्रश्न एका डेव्हलपरऐवजी टीमसाठी असेल, तर लक्षात घ्या की Claude Enterprise मध्ये प्रति सीट फी आणि याच API दराने टोकन मोजले जातात, त्यामुळे या पानावर दिलेले सर्व मार्ग त्या बिलाच्या metered भागासाठी लागू होतात.

FAQ

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

ते तयार करण्यासाठी प्रति टोकन अधिक ॲक्सिलरेटर वेळेची आवश्यकता असते. प्रॉम्प्ट संपूर्णपणे एकाच फॉरवर्ड पासमध्ये प्रक्रिया केला जातो, त्यामुळे मॉडेल वेट्स एकदाच वाचून हजारो टोकन्सवर प्रक्रिया होते आणि हार्डवेअरची मर्यादा मल्टिप्लाय थ्रूपुटवर असते. उत्तर देताना मात्र एका वेळी एकच टोकन तयार केले जाते, ज्यासाठी प्रत्येक वेळी पूर्ण मॉडेल वेट्स पुन्हा वाचावे लागतात. त्यामुळे हार्डवेअरची मर्यादा मेमरी बँडविड्थवर येते. Anthropic ने सध्याच्या संपूर्ण कॅटलॉगमध्ये, Haiku 4.5 पासून Fable 5 पर्यंत, आउटपुटची किंमत इनपुटच्या पाच पट ठेवली आहे.

प्रॉम्प्ट कॅशिंगमुळे आउटपुट टोकन्स स्वस्त होतात का?

नाही. प्रॉम्प्ट कॅशिंग फक्त इनपुटसाठी लागू होते. ऑगस्ट 2026 पर्यंत, कॅश रीडची किंमत मूळ इनपुट दराच्या 0.1x आहे आणि कॅश राईटची किंमत 5 मिनिटांच्या कालावधीसाठी 1.25x किंवा 1 तासाच्या कालावधीसाठी 2x आहे. कॅशने काहीही केले तरी आउटपुटसाठी प्रत्येक कॉलवर पूर्ण दर आकारला जातो. म्हणूनच कॅशिंगमुळे तुमच्या बिलाचा आकार आणि स्वरूप दोन्ही बदलतात: एकदा इनपुटचा खर्च कमी झाला की, आउटपुटचा खर्च हाच मुख्य घटक उरतो.

जर उत्तर लहान असेल, तर उच्च max_tokens मुळे माझे पैसे खर्च होतात का?

नाही. मॉडेल प्रत्यक्षात जेवढे टोकन्स तयार करते, तेवढेच बिल आकारले जाते, त्यामुळे max_tokens ही एक कमाल मर्यादा आहे, आरक्षित रक्कम नाही. तरीही हे महत्त्वाचे आहे, कारण अनियंत्रितपणे लांब होणाऱ्या उत्तरावर हेच एकमेव कडक नियंत्रण आहे. तुमच्या निरीक्षणातील output_tokens च्या 95 व्या पर्सेंटाइलपेक्षा थोडे जास्त मूल्य सेट करा आणि उत्तर अर्धवट कापले जाण्याऐवजी stop_reason: "max_tokens" ला कोडमध्ये हाताळा.

माझे स्वतःचे इनपुट ते आउटपुट टोकन गुणोत्तर मी कसे शोधू?

प्रत्येक रिस्पॉन्सच्या usage ऑब्जेक्टमधून input_tokens, output_tokens, cache_read_input_tokens आणि cache_creation_input_tokens लॉग करा, त्यानंतर एका आठवड्यातील एकूण बेरजेला भागा. जर गुणोत्तर 5 इनपुट ते 1 आउटपुटपेक्षा जास्त असेल, तर तुमचा खर्च प्रॉम्प्टवर होत आहे, त्यामुळे स्थिर भाग कॅश करा आणि उर्वरित भाग कमी करा. जर ते त्यापेक्षा कमी असेल, तर तुमचा खर्च उत्तरावर होत आहे, त्यामुळे त्याची लांबी मर्यादित करा आणि सर्वाधिक टोकन्स तयार करणारे टप्पे स्वस्त मॉडेलवर किंवा Batch API वर हलवा.