मुख्य कंटेंट तक स्किप करें

अपना टोकन उपयोग (और लागत) घटाएँ

मध्यम

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

What you'll learn
  • टोकन असल में कहाँ रिसते हैं — इनपुट बनाम आउटपुट बनाम दोबारा इस्तेमाल होने वाला कॉन्टेक्स्ट
  • संक्षिप्त / 'caveman' शैली: यह असल में क्या बचाती है, और कहाँ उल्टी पड़ती है
  • डॉलर-दर-डॉलर ढाँचागत बचत के लिए प्रॉम्प्ट कैशिंग और बैचिंग
  • मॉडल को राइट-साइज़ करना (सस्ते कामों के लिए Haiku) और गद्य के बजाय संरचित आउटपुट
  • शिप करने से पहले टोकन-काउंटिंग एंडपॉइंट से मापना

पहले, पता लगाएँ कि टोकन कहाँ जाते हैं​

ऑप्टिमाइज़ करने से पहले, अपने खर्च को तीन हिस्सों में बाँटें — हर एक का अलग समाधान है:

तीन टोकन हिस्से
कार्ड पलटने के लिए Enter या Space दबाएँ। कार्ड बदलने के लिए बाएँ और दाएँ तीर कुंजियों का उपयोग करें।शब्द दिखाया गया।
1 / 3

समाधान साफ़-साफ़ कतार में लग जाते हैं: दोबारा इस्तेमाल होने वाले कॉन्टेक्स्ट को कैश करें, इनपुट को छाँटें, आउटपुट को छोटा करें, मॉडल को राइट-साइज़ करें, और जो समय-संवेदनशील नहीं है उसे बैच करें।

संक्षिप्त / "caveman" शैली (आउटपुट बचत)​

वायरल तरकीब है Claude को भराव हटाने और टुकड़ों में जवाब देने को कहना — जिसे ओपन-सोर्स caveman Claude Code skill (MIT-लाइसेंस, Julius Brussee द्वारा) ने लोकप्रिय बनाया, जिसकी पंचलाइन है "why use many token when few token do trick." यह छोटे वाक्य, इनफ़िनिटिव क्रियाएँ और शून्य शिष्टाचार को मजबूर करती है।

स्वतंत्र परीक्षण से ईमानदार निष्कर्ष: यह शैली कंटेंट पर कुछ खर्च नहीं करती (कोड, तकनीकी शब्द, JSON सटीक रहते हैं) पर बचत पूरी तरह आपके बेसलाइन पर निर्भर है। अगर आपके प्रॉम्प्ट पहले से ही "संक्षिप्त रहो" कहते हैं, तो ज़्यादातर फ़ायदा पहले ही बँध चुका है। बड़ी कटौती (40–65%) व्याख्या-भारी जवाबों पर दिखती है; संरचित निष्कर्षण मुश्किल से हिलता है।

पतला निर्देश ब्लॉक — अपने सिस्टम प्रॉम्प्ट में पेस्ट करें

Answer terse. Cut filler, hedging, and pleasantries.
Drop articles (a/an/the) and softeners (just, really, basically, actually).
No preamble, no restating the question, no "happy to help."
Fragments are fine. Keep technical terms and code blocks exact.
Pattern per point: [thing] [action] [reason]. Next step if any.
Pro tip
  • संक्षिप्तता का नियम सिस्टम प्रॉम्प्ट में एक बार रखें, हर यूज़र टर्न में नहीं — इसे दोहराने से हर कॉल पर इनपुट लागत फिर से चुकानी पड़ती है।
  • कभी भी कोड, आइडेंटिफ़ायर, JSON या संख्याओं को संकुचित न करें। केवल गद्य को संकुचित करें।
  • 'संक्षिप्त रहो। केवल JSON लौटाओ।' अपने आप में हासिल की जा सकने वाली आउटपुट बचत का ~60% है — फ़ैंसी तरकीबों तक पहुँचने से पहले इसे लिखें।
Watch out
  • संक्षिप्त शैली केवल आउटपुट छाँटती है। यह उस 20k-टोकन सिस्टम प्रॉम्प्ट के लिए कुछ नहीं करती जिसे आप हर कॉल पर दोबारा भेजते हैं — वह एक इनपुट/कैशिंग समस्या है।
  • एक्सटेंडेड-थिंकिंग वाले कामों पर, रीज़निंग टोकन अप्रभावित रहते हैं; आप केवल अंतिम दिखने वाले जवाब को छोटा करते हैं।

दोबारा इस्तेमाल होने वाले प्रीफ़िक्स को कैश करें (इनपुट बचत)​

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

एकमात्र नियम: कैश किया गया प्रीफ़िक्स कॉल-दर-कॉल बाइट-दर-बाइट एक समान होना चाहिए। ऊपर के पास कोई इधर-उधर भटका टाइमस्टैम्प या फिर से क्रमबद्ध की गई टूल सूची चुपचाप आपके हिट रेट को शून्य पर गिरा देती है। पूरी कार्यविधि, कॉपी-पेस्ट cache_control स्निपेट, और हिट कैसे सत्यापित करें — यह सब Prompt Caching & Cost Optimization में है।

Guided walkthrough1 of 3
  1. सिस्टम प्रॉम्प्ट, टूल और दस्तावेज़ों को सामने ले जाएँ; यूज़र के बदलते टर्न को आखिर में रखें।

जो कॉन्टेक्स्ट आप भेजते हैं उसे छाँटें​

कैशिंग कॉन्टेक्स्ट को सस्ते में दोबारा इस्तेमाल करती है, पर सबसे सस्ता टोकन वही है जिसे आप कभी भेजते ही नहीं। ऑडिट करें कि विंडो में असल में क्या है:

  • सिस्टम प्रॉम्प्ट को छाँटें। लंबे निर्देश ब्लॉक कचरा जमा कर लेते हैं। उन उदाहरणों को काटें जो अब अपने टोकन नहीं कमाते; पाँच औसत उदाहरणों से बेहतर एक मज़बूत उदाहरण रखें।
  • खींचें, उड़ेलें नहीं। पूरा दस्तावेज़ चिपकाने के बजाय, केवल प्रासंगिक अंश लाएँ (RAG)। एक सवाल का जवाब देने के लिए 50-पन्नों का PDF भेजना सबसे आम बर्बादी है।
  • लंबे सेशनों को कॉम्पैक्ट करें। जब बातचीत बढ़े, तो हर संदेश को हमेशा के लिए ढोने के बजाय पुराने टर्नों को एक छोटे चलते सारांश से बदलें। इतिहास इनपुट टोकन हैं जिन्हें आप हर कॉल पर दोबारा चुकाते हैं।
  • टूल कैटलॉग को राइट-साइज़ करें। हर टूल परिभाषा हर रिक्वेस्ट पर इनपुट टोकन है। केवल वही टूल उजागर करें जिनकी मौजूदा काम को ज़रूरत है।

मॉडल को राइट-साइज़ करें​

Haiku-स्तर के काम के लिए Opus की दरें न चुकाएँ। वर्गीकरण, निष्कर्षण, साधारण फ़ॉर्मैटिंग और रूटिंग आमतौर पर सबसे छोटे मॉडल पर प्रति-टोकन कीमत के एक अंश पर बढ़िया चलते हैं। बड़े मॉडलों को सचमुच कठिन रीज़निंग के लिए सुरक्षित रखें, और रूटिंग पर विचार करें: एक सस्ता मॉडल आसान बहुसंख्यक को संभालता है, केवल कठिन मामलों को ऊपर भेजते हुए। ट्रेडऑफ़ के लिए Choosing a Model और Tokens, Context & Pricing देखें।

गद्य के बजाय संरचित आउटपुट को प्राथमिकता दें​

व्याख्यात्मक पैराग्राफ के बजाय JSON (या कोई दूसरा कसा हुआ स्कीमा) माँगने से आउटपुट टोकन घटते हैं और आगे की पाइपलाइन में पार्सिंग का अनुमान-लगाना भी हट जाता है। Claude को {"label": ..., "score": ...} जैसे केवल एक कॉम्पैक्ट ऑब्जेक्ट लौटाने को कहना, बातूनी जवाब के टोकनों का एक अंश ही जनरेट करता है — और आप "यह रहा परिणाम:" वाली प्रस्तावना पूरी तरह छोड़ देते हैं। विवरण Structured Output में।

जो समय-संवेदनशील नहीं है उसे बैच करें​

ऑफ़लाइन काम के लिए जहाँ आपको कुछ सेकंडों में जवाब नहीं चाहिए — इवैल, थोक वर्गीकरण, डेटासेट लेबलिंग, किसी आर्काइव का सारांश — Anthropic की Message Batches API रिक्वेस्ट्स को अतुल्यकालिक रूप से चलाती है, इनपुट और आउटपुट दोनों टोकनों पर 50% डिस्काउंट के साथ, और परिणाम आमतौर पर 24 घंटों के भीतर लौटते हैं।

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

मापें — अनुमान न लगाएँ​

संख्याओं के विरुद्ध ऑप्टिमाइज़ करें, अहसासों के नहीं। Anthropic का टोकन-काउंटिंग एंडपॉइंट किसी रिक्वेस्ट के लिए सटीक इनपुट-टोकन गिनती भेजने से पहले लौटाता है — Messages कॉल जैसा ही आकार, और यह मुफ़्त है (रेट-लिमिटेड)। इसका उपयोग एक फूले हुए प्रॉम्प्ट की तुलना एक छाँटे हुए से करने, मॉडल-रूटिंग के फ़ैसले लेने, और प्रॉम्प्ट को कॉन्टेक्स्ट विंडो के भीतर रखने के लिए करें।

भेजने से पहले टोकन गिनें (Python SDK)

import anthropic

client = anthropic.Anthropic()

resp = client.messages.count_tokens(
  model="claude-opus-4-8",
  system="You are a scientist",
  messages=[{"role": "user", "content": "Hello, Claude"}],
)
print(resp.input_tokens)  # exact input count, no charge for counting
Pro tip
  • किसी दूसरे मॉडल के टोकनाइज़र (जैसे tiktoken) का उपयोग न करें — गिनती प्रति मॉडल परिवार में भिन्न होती है। Anthropic के एंडपॉइंट का उपयोग करें।
  • नए टोकनाइज़र उसी पाठ के लिए पुराने मॉडलों की तुलना में ~30% अधिक टोकन उत्पन्न कर सकते हैं — माइग्रेट करते समय फिर से गिनें, पुराने अनुमान दोबारा न इस्तेमाल करें।
  • रिस्पॉन्स usage से input_tokens, cache_read_input_tokens और output_tokens पढ़कर पुष्टि करें कि बचत प्रोडक्शन में उतरी।

गिनती के नियमों और लागत-अनुमान फ़ॉर्मूले के लिए Tokens, Context & Pricing देखें।

एक पहले/बाद, अंत से अंत तक​

एक सपोर्ट-ट्राइएज असिस्टेंट हर टिकट पर वही 4,000-टोकन सिस्टम प्रॉम्प्ट + टूल कैटलॉग चलाता है और एक बातूनी 600-टोकन जवाब लिखता है।

Guided walkthrough1 of 4
  1. ~4,000 इनपुट टोकन हर कॉल पर पूरी कीमत पर दोबारा भेजे गए + ~600 लंबे-चौड़े आउटपुट टोकन, एक बड़े मॉडल पर। कुछ भी कैश नहीं, समकालिक, गद्य जवाब।

हर लीवर गुणक है: कैश किया इनपुट × छोटा मॉडल × संक्षिप्त आउटपुट × बैच डिस्काउंट मिलकर एक बड़ी कुल कमी में बदल जाते हैं — जबकि इस आसान काम पर जवाब की गुणवत्ता अपरिवर्तित रहती है। हर कदम को count_tokens से मापें ताकि आप जीत को मान लेने के बजाय साबित कर सकें।

खुद को जाँचें

0/4
  1. 'caveman' / संक्षिप्त शैली मुख्यतः किन टोकनों को घटाती है?
  2. आप हर कॉल पर वही 10k-टोकन सिस्टम प्रॉम्प्ट दोबारा भेजते हैं। सबसे अच्छा समाधान?
  3. Message Batches API के 50% डिस्काउंट के लिए कौन-सा वर्कलोड सबसे उपयुक्त है?
  4. आपको कैसे सत्यापित करना चाहिए कि किसी प्रॉम्प्ट बदलाव ने असल में टोकन बचाए?
Key takeaways
  • खर्च को इनपुट, आउटपुट और दोबारा-इस्तेमाल-कॉन्टेक्स्ट में बाँटें — हर हिस्से का अलग समाधान है।
  • संक्षिप्त/'caveman' शैली केवल आउटपुट काटती है; फ़ायदे गद्य पर बड़े, पहले से संक्षिप्त संरचित कामों पर छोटे होते हैं।
  • हर कॉल पर डॉलर-दर-डॉलर इनपुट बचत के लिए स्थिर प्रीफ़िक्स (बाइट-दर-बाइट एक समान) को कैश करें।
  • कॉन्टेक्स्ट छाँटें, मॉडल को राइट-साइज़ करें, और गद्य के बजाय JSON को प्राथमिकता दें — सस्ती, चक्रवृद्धि होती जीतें।
  • गैर-अत्यावश्यक काम को 50% डिस्काउंट के लिए बैच करें, और अनुमान लगाने के बजाय हमेशा count_tokens से मापें।

स्रोत और आगे पढ़ने के लिए​

आगे​