Track
यदि आपने कुछ ही अनुरोधों के बाद अपने AI कोडिंग प्लान की टोकन सीमा छू ली है, तो आपके मन में यह सवाल आ सकता है कि इतने टोकन गए कहाँ?
आप एजेंट से कोई बग ठीक करने, किसी फ़ीचर को रिफ़ैक्टर करने, या किसी रिपॉज़िटरी की जाँच करने को कहते हैं—और देखते ही देखते आपके कोडिंग अलाउंस का बड़ा हिस्सा खत्म हो जाता है।
यह अनिवार्य रूप से आपके प्रदाता या सब्सक्रिप्शन की समस्या नहीं है।
AI कोडिंग एजेंट सामान्य चैटबॉट्स की तुलना में कहीं अधिक टोकन-इंटेंसिव होते हैं। वे केवल आपका प्रॉम्प्ट नहीं पढ़ते—वे कई फ़ाइलें पढ़ सकते हैं, कोडबेस खोज सकते हैं, लॉग्स देख सकते हैं, टेस्ट चला सकते हैं, टूल्स कॉल कर सकते हैं, कोड जनरेट कर सकते हैं, अपने ही बदलावों की समीक्षा कर सकते हैं, और कार्य पूरा करने से पहले यह प्रक्रिया कई बार दोहरा सकते हैं।
अच्छी खबर यह है कि इस अनावश्यक टोकन उपयोग का बड़ा हिस्सा आप घटा सकते हैं।
ऐसे टूल मौजूद हैं जो कोडिंग एजेंट्स को कम लच्छेदार बनाते हैं, सरल कार्यों को ओवर-इंजीनियर करने से रोकते हैं, शोर-भरे टर्मिनल आउटपुट को कंप्रेस करते हैं, और बड़े टूल रिस्पॉन्सेज़ को संदर्भ विंडो भरने से बचाते हैं।
इस गाइड में, हम AI कोडिंग एजेंट्स में टोकन उपयोग घटाने के चार टूल्स देखेंगे: Caveman, Ponytail, RTK और Context Mode.
हम देखेंगे कि हर एक क्या करता है, कैसे सेटअप होता है, और उन्हें मिलाकर आप Claude Code और Codex जैसी सदस्यताओं से उपयोग-सीमा तक पहुँचने से पहले कितना अधिक काम करवा सकते हैं।
एजेंटिक वर्कफ़्लो इतने अधिक टोकन क्यों इस्तेमाल करते हैं?
एक सामान्य चैटबॉट एक प्रॉम्प्ट लेता है और एक उत्तर देता है। एक एजेंट आमतौर पर इससे कहीं अधिक करता है।
वह फ़ाइलें पढ़ सकता है, टूल कॉल कर सकता है, लॉग्स जाँच सकता है, दस्तावेज़ प्राप्त कर सकता है, कोड लिख सकता है—और यह प्रक्रिया पूरा होने से पहले कई बार दोहरा सकता है।
हर चरण संदर्भ में और जानकारी जोड़ता है, और उस संदर्भ का बड़ा हिस्सा अगले कॉल्स में फिर से मॉडल को भेजा जा सकता है।
एक सरलीकृत एजेंट लूप कुछ ऐसा दिखता है:

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

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

बाएँ, एजेंट अपना कोड किसी प्रीऐम्बल में लपेटता है और फिर बाद में उसी कोड को दोबारा समझाता है। दाएँ, आपको उपयोगी उत्तर और कोड मिलता है—और कुछ नहीं। वही काम, पर उसे बखान करने में बहुत कम टोकन खर्च।
Caveman के साथ शुरुआत
स्किल इंस्टॉल करने का सबसे आसान तरीका है:
npx skills add JuliusBrussee/caveman
फिर अपने कोडिंग एजेंट में इसे सक्रिय करें:
/caveman

आप सामान्य प्रतिक्रियाओं पर वापस स्विच कर सकते हैं:
/caveman off
Caveman, Claude Code, Codex, Gemini CLI, Cursor, और OpenCode जैसे टूल्स के लिए नेटिव इंस्टॉलेशन विकल्प भी देता है।
यदि आप मॉडल को भेजे जाने वाले संदर्भ को भी घटाना चाहते हैं, तो CLI इंस्टॉल करें:
npm install -g @caveman-ai/cli
caveman setup --install
फिर किसी समर्थित एजेंट को इसके ज़रिये लॉन्च करें, उदाहरण के लिए:
caveman claude
यह Caveman का लोकल प्रॉक्सी शुरू करता है और एजेंट को उसके संदर्भ-कंप्रेशन लेयर से रूट करता है।
अधिकांश उपयोगकर्ताओं के लिए, मैं पहले स्किल से शुरू करने की सलाह दूँगा।
इसे जोड़ना आसान है, यह आपके सामान्य कोडिंग वर्कफ़्लो को नहीं बदलता, और टोकन की बर्बादी के सबसे सरल स्रोत—एजेंट का ज़रूरत से ज़्यादा बोलना—को सीधे संबोधित करता है।
2. Ponytail: अपने एजेंट को ओवर-इंजीनियरिंग से रोकें
Ponytail टोकन बर्बादी के एक अलग प्रकार के लिए बनी है: कोडिंग एजेंट्स का कार्य से अधिक कोड लिख देना।

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

हर पायदान एजेंट को कुछ नया लिखने से पहले रुकने का मौका देता है। वह केवल आख़िरी पायदान तक पहुँचकर—काम चलाने लायक न्यूनतम कोड—लिखता है, जब स्टैंडर्ड लाइब्रेरी, नेटिव प्लेटफ़ॉर्म फ़ीचर्स और मौजूदा डिपेंडेंसी सभी को खारिज कर दिया गया हो।
उदाहरण के लिए, किसी डेट-पिकर लाइब्रेरी को इंस्टॉल करने और रैपर कंपोनेंट बनाने के बजाय, Ponytail यह तय कर सकता है कि ब्राउज़र में पहले से मौजूद है:
<input type="date">
उद्देश्य अंधाधुंध सब कुछ छोटा करना नहीं है।
Ponytail स्पष्ट रूप से वैलिडेशन, सुरक्षा, एक्सेसिबिलिटी और डेटा-लॉस सुरक्षा जैसी चीज़ों को कटौती से बाहर रखता है।
यह इम्प्लीमेंटेशन में आलस को बढ़ावा देता है, सहीपन में लापरवाही नहीं।
Ponytail के अपने एजेंटिक बेंचमार्क में, इसने लगभग 54% कम कोड और 22% कम टोकन 12 कोडिंग कार्यों में उत्पन्न किए, उसी एजेंट की तुलना में जिसमें यह स्किल न थी।
एक स्वतंत्र बेंचमार्क ने भी काफी छोटे इम्प्लीमेंटेशन पाए, हालाँकि उसने नोट किया कि बहुत आक्रामक सेटिंग्स कभी-कभी अनकहे एज-केसों पर स्थायित्व घटा सकती हैं।
Ponytail के साथ शुरुआत
Claude Code के लिए, मार्केटप्लेस जोड़ें:
/plugin marketplace add DietrichGebert/ponytail
फिर Ponytail इंस्टॉल करें:
/plugin install ponytail@ponytail
इन्हें दो अलग कमांड के रूप में भेजें।
इंस्टॉल होने के बाद, आप तय कर सकते हैं कि Ponytail कितनी आक्रामकता से सरल बनाए:
/ponytail lite
/ponytail full
/ponytail ultra
/ponytail off
full डिफ़ॉल्ट है और शायद शुरू करने की सबसे अच्छी जगह। lite वह सब बनाता है जो आप कहते हैं, पर सरल विकल्पों की ओर इशारा करता है, जबकि ultra YAGNI को कहीं अधिक आक्रामक रूप से लागू करता है।
आप मौजूदा बदलाव की अनावश्यक जटिलता भी रिव्यू कर सकते हैं:
/ponytail-review
या बड़े कोडबेस को स्कैन करें:
/ponytail-audit

Ponytail खासतौर पर कोडिंग एजेंट्स के लिए बढ़िया काम करता है क्योंकि अनावश्यक कोड घटाने का आगे असर पड़ता है: एजेंट अभी कम टोकन लिखता है, छोटे डिफ्स बनते हैं, और आगे खुद के लिए पढ़ने को भी कम कोड बचता है।
3. RTK: शोर-भरे टूल आउटपुट को घटाएँ
RTK, यानी Rust Token Killer, टोकन बर्बादी के एक और स्रोत पर ध्यान देता है: सब कुछ जो आपका कोडिंग एजेंट टर्मिनल से वापस पाता है।

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

सामान्य फ्लो में, एजेंट pytest चलाता है और जो भी लाइनें छपीं—जिनमें से अधिकांश पासिंग टेस्ट हैं—सब पढ़ता है। बीच में RTK होने पर, वही रन फेल्यर्स और एक सारांश के रूप में लौटता है, तो एजेंट सैकड़ों की जगह कुछ दर्जन पंक्तियाँ पढ़ता है।
समर्थित कोडिंग एजेंट्स के साथ, RTK शेल कॉल्स में अपने-आप हुक कर सकता है। एक कमांड जैसे:
git status
को बैकग्राउंड में फिर से लिखा जा सकता है:
rtk git status
एजेंट फिर छोटा आउटपुट प्राप्त करता है, बिना हर बार स्पष्ट रूप से RTK माँगे।
RTK सामान्य डेवलपमेंट कमांड्स के लिए लगभग 60–90% कम कमांड-आउटपुट टोकन उपयोग रिपोर्ट करता है। इसका यह मतलब नहीं कि आपका कुल LLM बिल 60–90% घटेगा; यह केवल उस टर्मिनल आउटपुट पर लागू होता है जिसे RTK कंप्रेस करता है।
RTK के साथ शुरुआत
macOS या Linux पर, आप इसे Homebrew से इंस्टॉल कर सकते हैं:
brew install rtk-ai/tap/rtk
या इंस्टॉलेशन स्क्रिप्ट का उपयोग करें:
curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/master/install.sh | sh
फिर यह जाँचें कि आपने सही RTK इंस्टॉल किया है:
rtk --versionrtk gain
कमांड rtk gain टोकन-बचत डैशबोर्ड दिखाता है। यह जाँच उपयोगी है क्योंकि एक असंबंधित प्रोजेक्ट भी rtk नाम का उपयोग करता है।
Claude Code के लिए, RTK को ग्लोबली इनिशियलाइज़ करें:
rtk init -g
Codex के लिए:
rtk init -g --codex
और Gemini CLI के लिए:
rtk init -g --gemini
RTK Cursor, OpenCode, Copilot, Cline, Windsurf और कई अन्य कोडिंग एजेंट्स को भी सपोर्ट करता है।

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

कोई ब्राउज़र स्नैपशॉट, GitHub इश्यू सूची, फ़ाइल सर्च, या बड़ा कमांड आउटपुट सीधे संदर्भ विंडो में बहुत सारा डेटा उंडेल सकता है।
और भी बुरा यह कि वह जानकारी बाद की टर्न्स में भी साथ चल सकती है।
Context Mode इसे टालने की कोशिश करता है—भारी कच्चे डेटा को सक्रिय LLM संदर्भ के बाहर रखकर, और केवल वही हिस्से वापस लाकर जिनकी एजेंट को सच में ज़रूरत है।
Context Mode कैसे काम करता है
Context Mode एक MCP सर्वर के रूप में चलता है और उन ऑपरेशन्स के लिए सैंडबॉक्स्ड टूल उपलब्ध कराता है जो सामान्यतः बड़े आउटपुट जनरेट करेंगे।

कच्ची जानकारी को लोकल रूप से FTS5-समर्थित सर्च इंडेक्स में स्टोर किया जा सकता है, ताकि एजेंट बाद में फिर से उसे खोज सके—बिना पूरी रिज़ल्ट को बातचीत में वापस उंडेले।
प्रोजेक्ट के एक उदाहरण में, 315 KB के कच्चे टूल आउटपुट को 5.4 KB संदर्भ तक घटा दिया गया, जिसे इसने 98% कमी के रूप में रिपोर्ट किया।
यह प्रोजेक्ट के अपने वर्कलोड का उदाहरण है—हर टूल कॉल के लिए गारंटी नहीं।
Context Mode के साथ शुरुआत
Claude Code के लिए, सबसे आसान सेटअप प्लगइन मार्केटप्लेस के ज़रिये है:
/plugin marketplace add mksglu/context-mode
/plugin install context-mode@context-mode
Claude Code रीस्टार्ट करें, फिर सेटअप जाँचें:
/context-mode:ctx-doctor

डॉक्टर जाँचता है कि प्लगइन, हुक्स, रनटाइम्स और लोकल सर्च कंपोनेंट्स सही काम कर रहे हैं या नहीं।
आप Context Mode को ग्लोबली भी इंस्टॉल कर सकते हैं:
npm install -g context-mode
और इसे Cursor, Gemini CLI, GitHub Copilot CLI, JetBrains और अन्य समर्थित क्लाइंट्स में MCP सर्वर के रूप में रजिस्टर करें।
एक बार चलने के बाद, इसके स्टैट्स टूल्स से आप देख सकते हैं कि यह कितना संदर्भ बचा रहा है।
Context Mode सबसे उपयोगी होता है लंबे, टूल-भारी एजेंट्स के लिए, जहाँ ब्राउज़र परिणाम, लॉग्स, फ़ाइल-रीड्स, MCP रिस्पॉन्सेज़ और अन्य मध्यवर्ती डेटा अन्यथा संदर्भ विंडो भरते रहते हैं।
चारों टोकन-बचत टूल्स की तुलना
ये चारों टूल्स कोडिंग-एजेंट वर्कफ़्लो के अलग हिस्सों को निशाना बनाते हैं—एजेंट क्या लिखता है से लेकर वह संदर्भ में कितना टूल आउटपुट उठाए रखता है तक।
|
टूल |
मुख्य समस्या |
क्या घटाता है |
किसके लिए उपयुक्त |
प्रोजेक्ट-रिपोर्टेड नतीजा |
|
Caveman |
लच्छेदार एजेंट प्रतिक्रियाएँ |
एजेंट आउटपुट और, वैकल्पिक प्रॉक्सी के साथ, दोहराया इनपुट संदर्भ |
ज़रूरत से ज़्यादा बात करने वाले कोडिंग एजेंट्स |
इसके स्किल बेंचमार्क में आउटपुट टोकन 65% तक कम |
|
Ponytail |
ओवर-इंजीनियर समाधान |
अनावश्यक कोड, एब्स्ट्रैक्शंस, और उससे उपजा एजेंट कार्य |
ज़रूरत से ज़्यादा कोड जनरेट करने वाले कोडिंग एजेंट्स |
इसके बेंचमार्क में 54% कम कोड और 22% कम टोकन |
|
RTK |
शोर-भरा टर्मिनल आउटपुट |
शेल कमांड्स, Git आउटपुट, टेस्ट्स, लॉग्स और सर्चेज़ |
CLI-भारी कोडिंग-एजेंट वर्कफ़्लो |
समर्थित कमांड्स पर 60–90% कम कमांड-आउटपुट टोकन |
|
Context Mode |
संदर्भ प्रदूषण |
बड़े MCP और टूल आउटपुट का सक्रिय संदर्भ में प्रवेश |
लंबे और टूल-भारी कोडिंग एजेंट्स |
315 KB → 5.4 KB, या 98% कम संदर्भ—एक प्रलेखित उदाहरण में |
अंतर समझने का सबसे आसान तरीका यह है:
- Caveman एजेंट जो कहता है उसे घटाता है
- Ponytail वह घटाता है जो वह बनाता है
- RTK वह घटाता है जो टर्मिनल वापस भेजता है
- Context Mode वह घटाता है जो टूल परिणाम संदर्भ में टिके रहते हैं।
क्या आप इन टूल्स को साथ में इस्तेमाल कर सकते हैं?
हाँ, लेकिन मैं शुरुआत से सब कुछ स्टैक करने की सलाह नहीं दूँगा।
बेहतर तरीका है कि Ponytail से शुरू करें।
इसे कोडिंग एजेंट्स में जोड़ना सरल है और कई वर्कफ़्लोज़ के लिए अनावश्यक कोड घटाना ही काफ़ी है। मैं इसे Zcode, Claude Code और Codex जैसे टूल्स के साथ उपयोग करता/करती हूँ और इससे मिलने वाली कमी से संतुष्ट हूँ।
यदि आप और आगे जाना चाहते हैं, तो Ponytail + Caveman आज़माएँ। Ponytail अनावश्यक कोड घटाता है, जबकि Caveman अनावश्यक व्याख्या—दोनों एक-दूसरे के पूरक हैं।

यदि आपके वर्कफ़्लो में अब भी टेस्ट्स, लॉग्स, Git या टर्मिनल कमांड्स से बहुत टोकन-भरा आउटपुट बनता है, तो Ponytail + Caveman + RTK आज़माएँ।
यदि RTK आपके वर्कफ़्लो में फिट नहीं बैठता—खासकर जब आप बहुत से MCP टूल्स, ब्राउज़र टूल्स, APIs, या अन्य बड़े टूल आउटपुट का उपयोग करते हों—तो Ponytail + Caveman + Context Mode आज़माएँ।
हर किसी के लिए कोई परफ़ेक्ट संयोजन नहीं है।
उद्देश्य है प्रयोग करना और वह सेटअप ढूँढना जो आपको कम टोकन उपयोग दे—बिना आपके कोडिंग एजेंट के प्रदर्शन को नुकसान पहुँचाए। कुछ लोगों के लिए Ponytail अकेला ही काफी होगा। दूसरों के लिए दो या तीन टूल्स का संयोजन बेहतर काम करेगा।
टोकन उपयोग और लागत घटाने के अन्य तरीके
हर बार आपको नया टूल नहीं चाहिए।
Claude Code में पहले से कई फ़ीचर्स हैं जो संदर्भ छोटा रखने और अनावश्यक खर्च घटाने में मदद कर सकते हैं।
जब ज़रूरत न हो तो मेमोरी निष्क्रिय करें
Claude Code पिछले सेशन्स से मेमोरी अपने-आप स्टोर और रीलोड कर सकता है। छोटे या अलग-थलग कार्यों के लिए, यह ऐसे संदर्भ जोड़ सकता है जिनकी आपको ज़रूरत नहीं।
कमांड चलाएँ:
/memory
वहाँ से, आप ऑटो-मेमोरी निष्क्रिय कर सकते हैं या अब उपयोगी न रही जानकारी हटा सकते हैं।
लंबे सेशन्स को कॉम्पैक्ट करें
सेशन बढ़ने पर Claude बातचीत का इतिहास, फ़ाइल सामग्री और टूल आउटपुट साथ रखता है। Claude Code स्वतः कॉम्पैक्ट करता है, लेकिन आप इसे पहले ट्रिगर कर सकते हैं:
/compact
आप यह भी बता सकते हैं कि क्या ज़रूरी है:
/compact keep the implementation plan and latest test results
यह तब खास उपयोगी है जब आपने किसी कार्य का एक भाग पूरा कर लिया है लेकिन उसी सेशन में आगे बढ़ना चाहते हैं।
कार्य बदलने पर नया सेशन शुरू करें
कभी-कभी कॉम्पैक्शन करना उचित नहीं होता। यदि आप पूरी तरह अलग कार्य पर जा रहे हैं, तो चलाएँ:
/clear
यह खाली बातचीत संदर्भ से शुरू करता है, असंबंधित काम को आगे ढोने के बजाय। Anthropic यह भी बताता है कि कई बार लंबे सेशन को बार-बार कॉम्पैक्ट करने से बेहतर नया शुरू करना होता है।
जिन MCP सर्वर्स का उपयोग नहीं हो रहा, उन्हें निष्क्रिय करें
MCP टूल्स भी संदर्भ का उपभोग करते हैं। Claude Code अब डिफ़ॉल्ट रूप से MCP टूल स्कीमाज़ को पूरी तरह डिफर कर देता है, लेकिन अनयूज़्ड सर्वर्स फिर भी ओवरहेड जोड़ सकते हैं।
उपयोग करें: /mcp अपने कनेक्टेड सर्वर्स की समीक्षा करने और जो अभी ज़रूरी नहीं उन्हें निष्क्रिय करने के लिए।
आप /context भी चला सकते हैं यह देखने के लिए कि सेशन के अलग हिस्से कितना स्पेस ले रहे हैं।
CLAUDE.md छोटा रखें
CLAUDE.md Claude के संदर्भ में लोड होता है, इसलिए इसे कोई विशाल प्रोजेक्ट मैनुअल न बनायें।
केवल वही निर्देश रखें जिनकी Claude को कार्यों के बीच सच में ज़रूरत है—जैसे अहम कन्वेंशंस, कमांड्स और प्रोजेक्ट नियम।
यह देखने के लिए कि आपकी मेमोरी और इंस्ट्रक्शन फ़ाइलें कितना स्पेस ले रही हैं, /context का उपयोग करें। केवल कुछ फ़ोल्डर्स से संबंधित निर्देशों के लिए, Claude Code मुख्य CLAUDE.md में सब डालने के बजाय अधिक लक्षित नियमों को सपोर्ट करता है।
सरल कार्यों के लिए सस्ते मॉडल का उपयोग करें
हर एडिट के लिए सबसे महँगा मॉडल शायद ज़रूरी नहीं।
Claude Code का दस्तावेज़ Sonnet को अधिकांश कोडिंग कार्यों के लिए और Opus को कठिन आर्किटेक्चरल या रीजनिंग-हेवी काम के लिए सुरक्षित रखने की सिफ़ारिश करता है।
आप यह कमांड चला कर स्विच कर सकते हैं:
/model
सरल सब-एजेंट कार्यों के लिए, आप उन्हें Haiku उपयोग करने के लिए भी कन्फ़िगर कर सकते हैं।
अंतिम विचार
इन टूल्स की सबसे अच्छी बातों में से एक यह है कि सेटअप होने के बाद इन्हें बहुत कम प्रयास चाहिए होता है।
टूल पर निर्भर करते हुए, आपको कोई स्लैश कमांड याद रखने या हर कार्य के लिए मैन्युअली सक्रिय करने की भी ज़रूरत नहीं पड़ सकती।
Ponytail एजेंट को सरल इम्प्लीमेंटेशंस की ओर मार्गदर्शन कर सकता है, Caveman प्रतिक्रियाओं को संक्षिप्त रख सकता है, RTK टर्मिनल आउटपुट कंप्रेस कर सकता है, और Context Mode बड़े टूल परिणामों को सक्रिय संदर्भ में बाढ़ लाने से रोक सकता है।
कन्फ़िगरेशन के बाद, इनमें से अधिकांश ऑप्टिमाइज़ेशन आपके सामान्य कोडिंग वर्कफ़्लो का ही हिस्सा बनकर होते हैं।
आप अक्सर इसके असर को एजेंट के रन समरी, जनरेटेड कोड, टर्मिनल आउटपुट, या संदर्भ आँकड़ों में देख सकते हैं।
एजेंट वही काम कर रहा होता है—पर कम अनावश्यक कोड, कम नैरेशन, छोटे टूल रिस्पॉन्सेज़, या एक चरण से अगले तक कम जानकारी ढोकर।
सबसे अच्छी बात यह है कि आप इन टूल्स को मिलाकर भी उपयोग कर सकते हैं।
हालाँकि, चारों को स्टैक कर देना अपने-आप सबसे कम टोकन उपयोग की गारंटी नहीं देता। ये एजेंटिक कोडिंग वर्कफ़्लो के अलग-अलग हिस्सों को टार्गेट करते हैं, और लाभ आपके कोडिंग एजेंट, मॉडल, रिपॉज़िटरी और कार्यों के प्रकार पर काफी निर्भर करता है।
मैं सलाह दूँगा/दूँगी कि आप इन्हें अपने कोडिंग हार्नेस पर आज़माएँ। एक टूल से शुरू करें, फर्क नापें, और यदि अब भी टोकन बर्बादी के स्पष्ट स्रोत दिखें, तो दूसरा जोड़ें।
आप पाएँगे कि किसी एक टूल से आपका वर्कफ़्लो चल जाता है, जबकि किसी अन्य सेटअप को दो या तीन टूल्स साथ मिलकर फ़ायदा पहुँचाते हैं।
व्यक्तिगत रूप से, मैं अपने अधिकांश कोडिंग वर्कफ़्लोज़ में Ponytail का उपयोग करता/करती हूँ क्योंकि इसे सेटअप करना सरल है और कोडिंग एजेंट जल्दी समझ जाता है कि इसके साथ कैसे काम करना है।
मैं इसे ज़्यादातर Z.ai के Zcode के साथ उपयोग करता/करती हूँ, जहाँ यह इम्प्लीमेंटेशन को केंद्रित रखने में मदद करता है—बिना मुझे एजेंट को प्रॉम्प्ट करने का तरीका बदलने की ज़रूरत के।
आखिरकार, टोकन उपयोग घटाना एजेंट से कम उपयोगी काम करवाने के बारे में नहीं है—बल्कि उस काम के आसपास की बर्बादी हटाने के बारे में है।
Caveman, Ponytail, RTK और Context Mode को अलग-अलग और अलग संयोजनों में आज़माएँ, अपने वर्कफ़्लो में क्या बदलता है मापें, और वही सेटअप रखें जो टोकन उपयोग, कोड गुणवत्ता और एजेंट प्रदर्शन के बीच आपको सबसे बेहतर संतुलन देता है।
AI एजेंट्स कैसे काम करते हैं, इस बारे में और जानने के लिए, मैं AI Agent Fundamentals स्किल ट्रैक देखने की सिफ़ारिश करता/करती हूँ।
FAQs
Prompt Caching क्या है, और क्या यह कोडिंग एजेंट्स के लिए टोकन लागत घटाता है?
Prompt caching एक नैटिव API फ़ीचर है (Claude, Sonnet और Gemini Pro जैसे मॉडलों में उपलब्ध) जो सिस्टम निर्देश, API दस्तावेज़, और रिपॉज़िटरी स्ट्रक्चर जैसी अक्सर उपयोग होने वाली संदर्भ सामग्री को अस्थायी रूप से स्टोर करता है। एजेंटिक लूप के हर टर्न पर पूरी कोडबेस को दोबारा प्रोसेस करने के बजाय, मॉडल कैश्ड संदर्भ का पुन: उपयोग करता है। इससे इनपुट टोकन लागत 90% तक कम हो सकती है और लंबे डेवलपमेंट सेशन्स में प्रतिक्रिया समय तेज़ हो सकता है।
आउटपुट टोकन इनपुट टोकन की तुलना में काफ़ी महंगे क्यों होते हैं?
जब आप LLMs की API प्राइसिंग देखते हैं, तो आउटपुट टोकन आमतौर पर इनपुट टोकन से 3 से 5 गुना महंगे होते हैं। इनपुट संदर्भ पढ़ना मॉडल के लिए अत्यधिक पैरेललाइज़्ड और कम्प्यूटेशनली सस्ता होता है। लेकिन आउटपुट जनरेशन सीक्वेंशियल है; मॉडल को हर एक टोकन की भविष्यवाणी और जनरेशन के लिए पूरा फॉरवर्ड पास चलाना पड़ता है। जो टूल एजेंट्स को अनावश्यक कोड या लच्छेदार व्याख्या लिखने से रोकते हैं, वे सीधे इसी महँगे आउटपुट जनरेशन को घटाते हैं।
फ़िक्स्ड सब्सक्रिप्शन की टोकन सीमाएँ API उपयोग से कैसे भिन्न होती हैं?
फ़िक्स्ड-प्राइस AI कोडिंग सब्सक्रिप्शंस (जैसे Cursor Pro या GitHub Copilot) आमतौर पर प्रति माह "फ़ास्ट" या प्रीमियम मॉडल रिक्वेस्ट्स का अलाउंस देती हैं। क्योंकि एजेंटिक वर्कफ़्लो फ़ाइलें पढ़ने और टेस्ट चलाने के लिए प्रति यूज़र प्रॉम्प्ट कई बार लूप करता है, आपके एक अनुरोध के पीछे बैकग्राउंड में 10 से 20 एजेंट रिक्वेस्ट्स खर्च हो सकते हैं, जिससे मासिक सीमा जल्दी थक जाती है। API-आधारित बिलिंग (Bring Your Own Key) इस रिक्वेस्ट कैप को हटा देती है और सख़्ती से प्रति टोकन चार्ज करती है, इसलिए टोकन-घटाने वाले टूल्स अप्रत्याशित बढ़ती लागत से बचने के लिए अहम हो जाते हैं।
क्या टर्मिनल लॉग्स और टूल संदर्भ फ़िल्टर करने से AI से बग छिप सकते हैं?
अगर बहुत आक्रामक रूप से लागू किया जाए तो हाँ, हो सकता है। जो टूल्स टर्मिनल शोर को ट्रंकट करते हैं या टूल संदर्भ को सीमित करते हैं वे लॉसी कंप्रेशन पर निर्भर रहते हैं। अगर कोई एजेंट गहरे नेस्टेड बग की जाँच कर रहा है, तो भारी फ़िल्टरिंग उस विशिष्ट स्टैक-ट्रेस लाइन, छिपी डिपेंडेंसी चेतावनी, या साइलेंट फेल्योर कोड को हटा सकती है जिसकी जड़ कारण पता करने के लिए ज़रूरत है। इसे कम करने के लिए, संदर्भ कंप्रेशन ज्ञात शोर-भरे आउटपुट (जैसे पैकेज मैनेजर इंस्टॉल्स) पर भारी लागू करें, जबकि डायरेक्ट एरर डिबगिंग के लिए कच्चा आउटपुट आने दें।