Claude के इनपुट और आउटपुट टोकन की लागत में अंतर क्यों है

आउटपुट टोकन की लागत इनपुट टोकन से अधिक क्यों होती है

वर्तमान कैटलॉग के प्रत्येक Claude मॉडल पर आउटपुट टोकन की लागत इनपुट टोकन की तुलना में पांच गुना अधिक है। इसका कारण गणना (computation) का स्वरूप है। प्रॉम्प्ट को पढ़ना मॉडल पर एक बार की प्रक्रिया है। उत्तर लिखना प्रति टोकन एक बार की प्रक्रिया है, और प्रत्येक प्रक्रिया को अपने से पहले वाली प्रक्रिया के पूरा होने का इंतजार करना पड़ता है।

यह अनुपात मूल्य सूची की प्रत्येक पंक्ति पर समान है, इसलिए आपके द्वारा चुना गया मॉडल आपके बिल में आउटपुट के हिस्से को नहीं बदलता है। यह आपके वर्कलोड के स्वरूप पर निर्भर करता है। एक एजेंट स्टेप जो 60,000 टोकन पढ़ता है और 800 में उत्तर देता है, वह आउटपुट पर लगभग कुछ भी खर्च नहीं करता है। एक ड्राफ्टिंग कार्य जो 2,000 टोकन पढ़ता है और 12,000 लिखता है, वह इनपुट पर लगभग कुछ भी खर्च नहीं करता है। दोनों मामलों का विश्लेषण नीचे Anthropic की अगस्त 2026 की प्रकाशित दरों के आधार पर किया गया है।

Prefill एक बार चलता है, decoding हर token के लिए एक बार चलती है

एक inference server किसी request को दो चरणों में संभालता है, जिनकी लागत बहुत अलग होती है। Prefill prompt को पढ़ता है। Decoding उत्तर लिखता है।

Prefill पूरे prompt को एक साथ लेता है। हर prompt token एक ही forward pass में network में प्रवेश करता है, इसलिए attention और feed-forward का काम एक साथ हजारों tokens को कवर करने वाले कुछ बड़े matrix multiplications बन जाते हैं। memory से model weights को एक बार पढ़ना पूरे prompt के लिए पर्याप्त होता है। accelerator की matrix units व्यस्त रहती हैं, जिसका अर्थ है कि prefill compute-bound है: सीमा यह है कि chip कितनी तेजी से गुणा कर सकती है।

Decoding इस तरह काम नहीं कर सकती, क्योंकि token 2, token 1 पर निर्भर करता है। model द्वारा अभी-अभी बनाया गया token अगले चरण के input का हिस्सा बन जाता है, इसलिए ये चरण एक साथ नहीं चल सकते। प्रत्येक output token का अपना forward pass होता है, और इनमें से प्रत्येक pass एक single token बनाने के लिए high-bandwidth memory से model weights के पूरे सेट को पढ़ता है। यह decoding को memory-bound बनाता है: सीमा यह है कि weights को कितनी तेजी से स्थानांतरित किया जा सकता है, न कि उन्हें कितनी तेजी से गुणा किया जा सकता है। वही weight traffic जो prefill के दौरान पूरे prompt को प्रोसेस करता है, decoding के दौरान आपको केवल एक token देता है।

Serving systems batching के जरिए इसका मुकाबला करते हैं। कई requests एक साथ decode होती हैं, इसलिए weights को एक बार पढ़ने से batch में मौजूद प्रत्येक request के लिए एक token प्राप्त होता है। यही कारण है कि decoding किफायती है। इसकी सीमा फिर से memory है। हर active request एक KV cache (key/value cache, अब तक के प्रत्येक token के लिए संग्रहीत attention state) रखती है, वह cache हर उत्पन्न token के साथ बढ़ती है, और जब यह accelerator को भर देती है, तो batch और अधिक नहीं बढ़ सकता।

इनमें से कोई भी आपको सटीक संख्या नहीं देता है, और आपको 5x को मापा गया hardware ratio नहीं मानना चाहिए। यह एक कीमत है, जिसे Anthropic द्वारा निर्धारित किया गया है, जो इसी विषमता (asymmetry) पर आधारित है। आप स्वयं जिस दिशा की जाँच कर सकते हैं, उसमें लगभग एक मिनट का समय लगता है।

इनपुट और आउटपुट गैप को स्वयं मापें

किसी भी 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) है, और सारा प्रीफिल इसी के भीतर हुआ। उसके बाद की हर लाइन डिकोडिंग का एक छोटा चरण है, और स्टैम्प तब तक बढ़ते रहते हैं जब तक 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'

पहला डेल्टा छोटे प्रॉम्प्ट की तुलना में अधिक समय लेता है, क्योंकि प्रीफिल के पास पढ़ने के लिए बहुत अधिक टेक्स्ट होता है। उसके आने के बाद रिस्पॉन्स लगभग तुरंत समाप्त हो जाता है, क्योंकि डिकोड करने के लिए केवल कुछ ही टोकन बचे होते हैं। हज़ारों टोकन इनपुट में गए और क्लॉक मुश्किल से ही हिली। कुछ सौ टोकन आउटपुट में आए और क्लॉक पूरे समय चलती रही।

प्रत्येक नॉन-स्ट्रीमिंग रिस्पॉन्स उन नंबरों के साथ समाप्त होता है जिनके लिए आपसे शुल्क लिया जाता है।

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

प्रति अनुरोध चारों फील्ड्स को लॉग करें। output_tokens में विस्तृत थिंकिंग शामिल है, इसलिए जो मॉडल उत्तर देने से पहले सोचता है, वह उस थिंकिंग के लिए आउटपुट दर पर बिल करता है। किसी प्रॉम्प्ट को भेजने से पहले उसकी कीमत जानने के लिए, POST /v1/messages/count_tokens उसी रिक्वेस्ट बॉडी को स्वीकार करता है, मॉडल को चलाए बिना {"input_tokens": N} लौटाता है, और यह निःशुल्क है।

अगस्त 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 का documentation बताता है कि Claude 4.7 और बाद के models एक नए tokenizer का उपयोग करते हैं जो Sonnet 4.6 और उससे पहले के tokenizer की तुलना में समान text के लिए लगभग 30% अधिक टोकन उत्पन्न करता है। केवल प्रति मिलियन टोकन मूल्य पर तुलना करने पर नए model बेहतर दिखेंगे, क्योंकि वही document उन पर अधिक टोकन का होता है। पूर्ण कार्य की लागत पर तुलना करें, और जिस model का आप वास्तव में उपयोग करने की योजना बना रहे हैं, उसके विरुद्ध अपने वास्तविक prompts की गणना करें। वास्तविक text में एक मिलियन 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 पुराने संदर्भ टोकन हटाने से लागत का लगभग एक तिहाई हिस्सा बच जाता है। रीड-हेवी एजेंट पर आउटपुट की लंबाई कम करना लगभग व्यर्थ प्रयास है। कोडिंग एजेंट के टोकन वास्तव में कहाँ जाते हैं इस बात का विवरण देता है कि प्रॉम्प्ट में क्या भरा होता है।

जेनरेशन वर्कलोड: छोटा प्रॉम्प्ट, लंबा ड्राफ्ट

[
  {
    "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 के बीच चयन इस बात पर चर्चा करता है कि गुणवत्ता की सीमा वास्तव में कहाँ स्थित है।

Caching डिस्काउंट केवल इनपुट पर लागू होते हैं

Prompt caching आपके प्रॉम्प्ट के एक हिस्से को सर्वर पर स्टोर करता है और इसे दोबारा पढ़ने के लिए इनपुट दर का एक छोटा हिस्सा चार्ज करता है। अगस्त 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। Caching बिल को कम करती है और उसके स्वरूप को बदल देती है। उस कॉल में आउटपुट 6.25% था। अब यह उसका एक चौथाई से अधिक है, जो यह बदल देता है कि आगे किस विकल्प पर ध्यान देना फायदेमंद है।

पहली कॉल राइट (write) का भुगतान करती है। 5 मिनट के कैश राइट की लागत बेस इनपुट का 1.25 गुना है, इसलिए यह एक ही हिट के बाद अपनी लागत वसूल कर लेता है। 1 घंटे के राइट की लागत 2 गुना है, इसलिए इसे दो हिट की आवश्यकता होती है। राइट और रीड मल्टीप्लायर, और जहाँ Caching का लाभ मिलना बंद हो जाता है उस गणित को विस्तार से समझाता है।

आपके नियंत्रण में चार लीवर

1. max_tokens को मॉडल की अधिकतम सीमा पर नहीं, बल्कि अपने p95 आउटपुट लेंथ पर सेट करें।
2. विस्तृत चरणों (verbose steps) को एक सस्ते मॉडल पर रूट करें।
3. ऐसी किसी भी चीज़ को बैच (batch) करें जिसका इंतज़ार कोई नहीं कर रहा है।
4. उन निर्देशों को हटा दें जो उत्तरों को अनावश्यक रूप से लंबा बनाते हैं।

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

राउटिंग तब काम करती है जब किसी चरण का महंगा हिस्सा निर्णय लेने के बजाय वॉल्यूम (मात्रा) होता है। निर्णय लेने के लिए मजबूत मॉडल का उपयोग करें, और टाइपिंग का काम किसी सस्ते मॉडल को सौंप दें। रूट किए गए संस्करण को पहले अपने स्वयं के मूल्यांकन सेट पर मापें, क्योंकि एक सस्ता मॉडल जिसे दो प्रयासों की आवश्यकता होती है, वह एक महंगे प्रयास से अधिक महंगा पड़ता है।

बैचिंग एकमात्र ऐसा लीवर है जो आउटपुट पर छूट देता है। दोनों तरफ 50% की छूट, 24 घंटे के भीतर परिणाम, और शेड्यूल पर चलने वाली कोई भी चीज़ इसके लिए योग्य है।

अंतिम लीवर वह है जिसे लोग छोड़ देते हैं। "विस्तृत रहें" और "अपने तर्क की व्याख्या करें" जैसे वाक्यांश आपके द्वारा किए जाने वाले हर कॉल पर आउटपुट की लंबाई निर्धारित करते हैं। उन्हें उस प्रारूप से बदलें जो आप चाहते हैं: "अधिकतम तीन वाक्यों में उत्तर दें", या "बिना किसी प्रस्तावना के केवल JSON ऑब्जेक्ट लौटाएं"। एक सिस्टम प्रॉम्प्ट जो हर उत्तर में 300 टोकन जोड़ता है, उसकी लागत प्रॉम्प्ट में उन्हीं 300 टोकन की लागत से पांच गुना अधिक होती है। एक रनिंग एजेंट की लागत को नियंत्रण में रखना मॉनिटरिंग पक्ष को कवर करता है, और क्या आपके पैटर्न के लिए API या फ्लैट सब्सक्रिप्शन सस्ता है इस पर निर्णय लेना तब उचित है जब आप प्रति-टोकन खर्च को ट्यून करने में एक सप्ताह बिताने से पहले इसे समझ लें, जिसे एक सब्सक्रिप्शन ने कवर कर लिया होता।

FAQ

Output tokens की कीमत input tokens से अधिक क्यों होती है?

उन्हें generate करने में प्रति token कहीं अधिक accelerator time लगता है। एक prompt को पूरे तौर पर एक ही forward pass में process किया जाता है, इसलिए model weights को एक बार पढ़ने से हजारों tokens cover हो जाते हैं और hardware की सीमा multiply throughput द्वारा तय होती है। एक reply को एक-एक करके token दर token तैयार किया जाता है, जहाँ हर token के लिए एक अलग forward pass की आवश्यकता होती है जो फिर से पूरे model weights को पढ़ता है, इसलिए hardware की सीमा memory bandwidth द्वारा तय होती है। Anthropic अपने पूरे वर्तमान catalogue में output की कीमत input से पांच गुना रखता है, Haiku 4.5 से लेकर Fable 5 तक।

क्या prompt caching से output tokens सस्ते हो जाते हैं?

नहीं। Prompt caching केवल input पर लागू होता है। अगस्त 2026 तक, cache read की कीमत base input rate का 0.1x है, और cache write की कीमत 5 मिनट की अवधि के लिए 1.25x या 1 घंटे की अवधि के लिए 2x है। Output का बिल हर call पर पूरी दर से ही बनता है, चाहे cache ने कुछ भी किया हो। यही कारण है कि caching आपके बिल के आकार के साथ-साथ उसके स्वरूप को भी बदल देता है: एक बार जब input का हिस्सा कम हो जाता है, तो output ही वह मुख्य हिस्सा बन जाता है जिस पर खर्च कम करने का ध्यान देना चाहिए।

क्या एक उच्च max_tokens मुझे महंगा पड़ता है यदि reply छोटा हो?

नहीं। आपसे केवल उन tokens के लिए शुल्क लिया जाता है जिन्हें model वास्तव में produce करता है, इसलिए max_tokens एक अधिकतम सीमा (ceiling) है, न कि कोई reservation। यह फिर भी महत्वपूर्ण है, क्योंकि यह एक ऐसी reply पर एकमात्र कठोर सीमा है जो बहुत लंबी हो सकती है। इसे अपने देखे गए output_tokens के 95th percentile से थोड़ा ऊपर सेट करें, और फिर चुपचाप कटे हुए (truncated) उत्तर भेजने के बजाय code में stop_reason: "max_tokens" को handle करें।

मैं अपना input से output token ratio कैसे पता करूँ?

हर response के usage object से input_tokens, output_tokens, cache_read_input_tokens और cache_creation_input_tokens को log करें, और फिर एक सप्ताह के कुल योग को विभाजित करें। यदि ratio 5 input से 1 output से अधिक है, तो आपका पैसा prompt में खर्च हो रहा है, इसलिए स्थिर हिस्से को cache करें और बाकी को trim करें। यदि यह उससे कम है, तो आपका पैसा reply में खर्च हो रहा है, इसलिए इसकी लंबाई को सीमित करें और उन steps को, जो सबसे अधिक output generate करते हैं, किसी सस्ते model या Batch API पर ले जाएँ।