Claude Code में दो सेटिंग्स हैं जो दोनों ही "जवाब को बेहतर बनाने" के लिए लगती हैं: मॉडल और प्रयास स्तर। लेकिन ये वास्तव में आउटपुट पर क्या करते हैं? और आपको कैसे पता चलेगा कि कब किसी अलग मॉडल का उपयोग करना है या सिर्फ प्रयास स्तर बदलना है?
यह मान लेना आसान है कि Fable जैसे बड़े मॉडल को चुनने से Sonnet की तुलना में अधिक स्मार्ट आउटपुट मिलता है, और उच्च प्रयास स्तर का मतलब सिर्फ इतना है कि Claude जवाब देने से पहले अधिक सोचता है।
पहली धारणा सही है। उद्योग-मानक बेंचमार्क के अनुसार, हमारे सबसे बड़े मॉडल अधिक सक्षम हैं।
लेकिन प्रयास का मतलब सिर्फ "सोचने का समय" नहीं है। प्रयास यह नियंत्रित करता है कि Claude आपके अनुरोध पर कुल मिलाकर कितना काम करता है। इसमें यह भी शामिल है कि वह कितनी देर सोचता है, लेकिन यह भी:
- वह कितनी फ़ाइलें पढ़ता है;
- वह कितना सत्यापन करता है; और
- आपसे जाँच करने से पहले वह एक बहु-चरणीय कार्य में कितना आगे बढ़ता है।
उच्च प्रयास पर, Claude आपके पास वापस आने से पहले उनमें से अधिक क्रियाएँ (फ़ाइलें पढ़ना, टेस्ट चलाना, दोबारा जाँच करना) करता है। कम प्रयास पर, वह अपने आप कुछ पता लगाने के लिए टोकन खर्च करने के बजाय आपसे अधिक संदर्भ माँगना पसंद करेगा।
मॉडल चयन कैसे काम करता है
यह समझने के लिए कि मॉडल सेटिंग वास्तव में क्या नियंत्रित करती है, शुरुआत से शुरू करना मददगार होता है, जिस क्षण से आप एंटर दबाते हैं।
Claude Code आपके संदेश को सिस्टम प्रॉम्प्ट, टूल परिभाषाओं, आपकी CLAUDE.md, बातचीत के इतिहास और संदर्भ में किसी भी फ़ाइल के साथ जोड़ता है। यह सब एक अनुरोध के रूप में API को भेजा जाता है।
Claude Code के पास जो कुछ भी है वह एक API अनुरोध में पैक हो जाता है। सर्वर पर, मॉडल तक पहुँचने से पहले ही टेक्स्ट को टोकनाइज़ किया जाता है।
हालाँकि, मॉडल उनमें से किसी को भी सादे टेक्स्ट के रूप में नहीं देखता है। सर्वर पर सबसे पहले जो होता है वह है टोकनाइज़ेशन: टेक्स्ट को टुकड़ों में विभाजित किया जाता है, और प्रत्येक टुकड़े को एक निश्चित शब्दावली से एक पूर्णांक से मैप किया जाता है जिस पर मॉडल को प्रशिक्षित किया गया था। \const\ 1978 से मैप हो सकता है, \await\ 4293 से मैप हो सकता है। अब से, आपका प्रॉम्प्ट पूर्णांकों की एक सरणी है।
टोकनाइज़र आपके टेक्स्ट को टुकड़ों में विभाजित करता है और प्रत्येक टुकड़े को एक निश्चित शब्दावली में एक पूर्णांक से मैप करता है। शीर्ष पंक्ति में प्रत्येक भाग अपना टोकन ID (निचली पंक्ति) बन जाता है; दिखाए गए ID केवल उदाहरण हैं।
मॉडल का काम उस सरणी को लेना और यह अनुमान लगाना है कि आगे कौन सा टोकन आएगा। यह अपनी शब्दावली में प्रत्येक टोकन के लिए एक संभावना की गणना करके और शीर्ष से चुनकर ऐसा करता है। "const x = await" के बाद, एक अच्छी तरह से प्रशिक्षित मॉडल "fetch" पर उच्च संभावना (बहुत संभावित) और "banana" पर लगभग शून्य (बिल्कुल भी संभावित नहीं) रखता है।
मॉडल का पूर्वानुमान उसकी शब्दावली में प्रत्येक टोकन के लिए एक संभावना है। शीर्ष अनुमान और एक असंबंधित अनुमान के बीच का अंतर बहुत बड़ा है।
आपके इनपुट टोकन को उन संभावनाओं में क्या बदलता है, वह है वज़न (जिसे पैरामीटर भी कहा जाता है): बड़े मैट्रिसेस में व्यवस्थित अरबों संख्याएँ। एक टोकन की भविष्यवाणी करने के लिए, मॉडल आपके इनपुट को उन मैट्रिसेस (मैट्रिक्स गुणन की एक लंबी श्रृंखला) के माध्यम से चलाता है और अंत में संभावनाओं को पढ़ता है। वज़न वह जगह है जहाँ वह सब कुछ रहता है जो मॉडल "जानता है"।
प्रत्येक मॉडल का वज़न प्रशिक्षण के दौरान सेट किया जाता है, और जब तक आप अनुरोध भेज रहे होते हैं, वे केवल-पढ़ने योग्य होते हैं। आपके प्रॉम्प्ट, आपकी CLAUDE.md, या आपके संदर्भ में कुछ भी उन्हें नहीं बदलता है। यदि आपने इन्फ़रेंस शब्द देखा है, तो इसका यही मतलब है: प्रशिक्षण पूरा होने के बाद मॉडल का उपयोग करना, वज़न स्थिर रहने के साथ।
आपका प्रॉम्प्ट अंदर जाता है, संभावनाएँ बाहर आती हैं। बीच में वज़न नहीं बदलता है।
Claude TypeScript, लोकप्रिय फ्रेमवर्क, या किसी अन्य सामान्य प्रोग्रामिंग ज्ञान के बारे में जो कुछ भी जानता है, वह प्रशिक्षण के समय उन वज़न में एन्कोड किया गया था।
आपका प्रॉम्प्ट और संदर्भ अभी भी पूर्वानुमान को निर्देशित कर सकते हैं। Claude के सामने आपका वास्तविक कोड रखना निर्देशन है, और यह बहुत अच्छी तरह से काम करता है। हालाँकि, यह वज़न में कुछ भी नहीं जोड़ता है।
यदि मॉडल को प्रशिक्षित करते समय कोई लाइब्रेरी मौजूद नहीं थी, तो वह वज़न में नहीं है। आप संदर्भ में दस्तावेज़ डाल सकते हैं और Claude उनका उपयोग करेगा, लेकिन यह निर्देशन है, सिखाना नहीं। Claude की प्रतिक्रिया केवल उस एक अनुरोध के लिए प्रभावित होती है, लेकिन अंतर्निहित मॉडल ने कुछ भी बरकरार नहीं रखा है।
जब Claude आत्मविश्वास से एक ऐसे API को कॉल करता है जो मौजूद नहीं है (एक मतिभ्रम), तो यह वज़न है जो एक टोकन अनुक्रम उत्पन्न कर रहा है जो प्रशिक्षण पैटर्न से प्रशंसनीय दिखता है, न कि कोई असफल लुकअप।
तो मॉडल बदलने से वास्तव में क्या होता है? यह बदल देता है कि फ्रोज़न वज़न का कौन सा सेट आपके अनुरोध को संभालता है।
मॉडल एक बार में पूरा उत्तर उत्पन्न नहीं करता है। यह एक टोकन की भविष्यवाणी करता है, इसे अनुक्रम में जोड़ता है, और अगला प्राप्त करने के लिए पूरी गणना फिर से चलाता है। 200-टोकन प्रतिक्रिया वज़न के माध्यम से 200 अलग-अलग पास हैं। यह लूप वह जगह है जहाँ आपके प्रतीक्षा समय (और आपकी आउटपुट लागत) का अधिकांश भाग आता है।
अनुक्रम प्रति चरण ठीक एक टोकन बढ़ता है। मॉडल हर बार यह अनुमान लगाने के लिए पूरी सरणी को फिर से पढ़ता है कि आगे क्या आता है।
मॉडल सेटिंग तय करती है कि कौन से वज़न आपके अनुरोध को संभालते हैं, और यह भी तय करती है कि प्रत्येक आउटपुट टोकन की लागत कितनी है।
यह जो तय नहीं करता है वह है कितने टोकन उत्पन्न होते हैं। यह संख्या एक ही प्रॉम्प्ट के लिए बहुत भिन्न हो सकती है, यह इस बात पर निर्भर करता है कि Claude कितना काम करने का फैसला करता है।
जो वास्तव में प्रयास नियंत्रित करता है।
प्रयास कैसे काम करता है
जब Claude Code किसी कार्य पर काम कर रहा होता है, तो वह जो टोकन उत्पन्न करता है, वे कुछ श्रेणियों में आते हैं:
- सोच: वह तर्क जिसे आप कार्यों से पहले और बीच में स्ट्रीमिंग करते हुए देखते हैं।
- टूल कॉल: संरचित ब्लॉक जो Read या Edit जैसे टूल और उसके तर्कों का नाम देते हैं, जिसे Claude Code फिर पार्स और निष्पादित करता है।
- आपके लिए टेक्स्ट: योजना, प्रगति अपडेट, अंत में सारांश।
ये सभी एक ही लूप से सामान्य आउटपुट टोकन हैं, जिन पर समान दर से शुल्क लगाया जाता है। उदाहरण के लिए, सोचने वाले टोकन, अन्य आउटपुट टोकन की तरह ही उत्पन्न होते हैं और उस मोड़ के बाकी हिस्से के लिए संदर्भ में रहते हैं।
जब तक Claude कोड लिखने के लिए आगे बढ़ता है, उसका पिछला तर्क इनपुट का हिस्सा होता है, ठीक उसी तरह जैसे उसके द्वारा पढ़ी गई कोई फ़ाइल।
Claude का सारा आउटपुट टोकन है। सोच, टूल कॉल और आपके लिए टेक्स्ट सभी एक ही लूप से उत्पन्न होते हैं।
तो प्रयास इसमें से कुछ भी कैसे बदलता है? प्रयास स्तर को अनुरोध के हिस्से के रूप में मॉडल को भेजा जाता है, आपके प्रॉम्प्ट के साथ ही। मॉडल को यह समझने के लिए प्रशिक्षित किया गया था कि प्रत्येक प्रयास स्तर पर कैसे व्यवहार करना है, और वह सीखा हुआ व्यवहार फ्रोज़न वज़न में बेक किया हुआ है।
जब आपका अनुरोध आता है, तो प्रयास सिर्फ एक और इनपुट है जिस पर मॉडल प्रतिक्रिया करता है, उसी तरह जैसे वह आपके प्रॉम्प्ट टेक्स्ट पर प्रतिक्रिया करता है। यह निर्धारित करता है कि कार्य को पूर्ण मानने से पहले Claude को कितना गहन और कितना निश्चित होना चाहिए। यह हर मोड़ पर तौला जाता है, और उच्च आत्मविश्वास तक पहुँचने में अधिक टोकन लगते हैं।
एक ही प्रॉम्प्ट, दो प्रयास स्तर। उच्च प्रयास पथ उच्च आत्मविश्वास वाले उत्तर तक पहुँचने के लिए लगभग 7 गुना अधिक टोकन उत्पन्न करता है।
उच्च प्रयास स्तरों पर, Claude अक्सर एक योजना बनाकर शुरू करता है, और प्रयास स्तर उस योजना की गहराई और चौड़ाई को प्रभावित करता है। लेकिन योजना स्थिर नहीं है। जैसे-जैसे Claude को अपने कार्यों से परिणाम वापस मिलते हैं, वह अपनी प्रगति और संचित परिणाम के बारे में अपनी निश्चितता की तस्वीर को अपडेट करता है।
जब तीन-परिकल्पना डिबगिंग योजना का चरण 1 बग ढूँढ लेता है, तो "परिकल्पना 2 और 3 की जाँच करें" अब आवश्यक नहीं रह सकता है। Claude आमतौर पर यह स्पष्ट रूप से कहेगा (जैसे "पहली जाँच ने इसे ढूँढ लिया, इसलिए शेष जाँचों की आवश्यकता नहीं है") और आगे बढ़ जाएगा। आप इसे Claude Code में तब होते हुए देखते हैं जब कार्य सूचियाँ बीच में ही संशोधित हो जाती हैं।
उच्च प्रयास वास्तव में Claude के दोबारा जाँच करने की अधिक संभावना बनाता है, जैसे उसके द्वारा पाए गए उत्तर को सत्यापित करना, या फिर भी उन परिकल्पनाओं को देखना जिन्हें वह छोड़ सकता था। हालाँकि, यह आम तौर पर केवल इसलिए किसी सरल कार्य पर उपयोग को कृत्रिम रूप से नहीं बढ़ाएगा क्योंकि प्रयास स्तर बढ़ा दिया गया है। "ओवरथिंकिंग" एक ऐसी चीज़ है जिस पर हमारी टीम मॉडल प्रशिक्षण के दौरान विशेष रूप से नज़र रखती है क्योंकि यह प्रभावशीलता को कम करता है।
प्रयास स्तर चुनना
अधिकांश कार्यों के लिए, मॉडल के डिफ़ॉल्ट प्रयास स्तर का उपयोग करें। डिफ़ॉल्ट वह स्तर है जहाँ Claude अपने टोकन उपयोग को उस पैमाने पर लाता है जो अधिकांश लोग किसी कार्य पर खर्च करना चाहेंगे।
प्रयास को एक मैनुअल ओवरराइड के रूप में सोचें कि Claude कितनी मेहनत और कितनी देर काम करता है। जानबूझकर इसका उपयोग करें जब आपके पास अपने डोमेन या आपके द्वारा किए जाने वाले कार्य के प्रकार के आधार पर गहनता या गति के लिए एक मजबूत प्राथमिकता हो, और इसे एक सामान्य प्राथमिकता के रूप में मानें, न कि कार्य-दर-कार्य निर्णय के रूप में।
Opus 4.8 के लॉन्च के बाद एक व्यावहारिक नोट: हमारे परीक्षण में, Opus 4.8 पर डिफ़ॉल्ट प्रयास सेटिंग, उसी कार्य पर Opus 4.7 पर डिफ़ॉल्ट प्रयास सेटिंग के समान टोकन की मात्रा के लिए बेहतर परिणाम उत्पन्न करती है।
जब Claude गलती करे तो क्या बदलें
जब Claude कुछ गलत करता है, तो आपकी पहली प्रवृत्ति कोई सेटिंग बदलने की नहीं होनी चाहिए। यह आपके द्वारा दिए गए संदर्भ को देखने की होनी चाहिए। क्या आपका प्रॉम्प्ट बहुत अस्पष्ट है? क्या Claude सही टूल से जुड़ा है? क्या उसके पास सही कौशल हैं?
यदि आप किसी ऐसे कार्य पर प्रयास बढ़ा रहे हैं जिसे इसकी आवश्यकता नहीं होनी चाहिए, तो सुधार आमतौर पर ऊपर की ओर होता है: आपके संदर्भ में, आपकी CLAUDE.md में, या कार्य के दायरे में।
लेकिन मान लीजिए कि आपने स्पष्ट संदर्भ दिया है और फिर भी Claude गलती करता है। अपने आप से पूछने वाला प्रश्न यह है: क्या उसने पर्याप्त प्रयास नहीं किया, या वह पर्याप्त नहीं जानता था?
मॉडल: समस्या बहुत कठिन थी
एक बड़ा मॉडल चुनें जब समस्या वास्तव में कठिन हो, जैसे सूक्ष्म बग, अपरिचित डोमेन, आर्किटेक्चर निर्णय। एक बड़ा मॉडल वह है जो आप चाहते हैं जब छोटा मॉडल आपके द्वारा दिए गए कितने भी संदर्भ के बावजूद आत्मविश्वास से गलत हो।
बड़े मॉडल अस्पष्टता को संभालने में भी बेहतर होते हैं। छोटे मॉडलों पर, विशिष्ट निर्देश जो निष्पादन को निर्देशित करते हैं, सफलता के लिए एक बेहतर नुस्खा हैं।
एक छोटा मॉडल चुनें जब काम नियमित हो: ऐसे संपादन जिन्हें आप सटीक रूप से वर्णित कर सकते हैं, यांत्रिक परिवर्तन, पहले से संदर्भ में मौजूद कोड के बारे में प्रश्न। उस क्षमता के लिए भुगतान करने का कोई कारण नहीं है जिसकी कार्य को आवश्यकता नहीं है।
यदि Claude के पास सभी प्रासंगिक संदर्भ थे, उसने स्पष्ट रूप से प्रयास किया, और फिर भी गलती की; यह एक बड़ा मॉडल चुनने का संकेत है। और यदि आप बड़े मॉडल पर हैं और काम कुछ समय से नियमित रहा है, तो नीचे आने से गति बढ़ेगी और आमतौर पर आउटपुट की गुणवत्ता को प्रभावित किए बिना लागत कम होगी।
प्रयास: Claude ने पर्याप्त प्रयास नहीं किया
उच्च प्रयास स्तर चुनें यदि Claude ने पर्याप्त प्रयास न करके गलती की: एक फ़ाइल को छोड़ना, टेस्ट नहीं चलाना, या अपने काम की दोबारा जाँच नहीं करना। यह सबसे अधिक प्रासंगिक है यदि आपने मॉडल के डिफ़ॉल्ट से नीचे का प्रयास स्तर चुना था।
विशेषज्ञ, विशेषज्ञ और सामान्यज्ञ
एक तरीका जो मुझे दो सेटिंग्स के बारे में सोचना पसंद है, वह यह है कि Fable एक विशेषज्ञ है जो लगभग किसी और के सामने न आने वाली समस्याओं को संभाल सकता है, Opus विशेषज्ञ है, और Sonnet एक बहुत अच्छा सामान्यज्ञ है। प्रयास स्तर तय करता है कि उनमें से कोई भी आपके कार्य पर कितना समय बिताता है।
कम प्रयास पर Opus आपकी जैसी समस्याओं के साथ गहरे अनुभव वाले किसी विशेषज्ञ के साथ पाँच मिनट पाने जैसा है। वे अपने साथ ऐसा ज्ञान लाते हैं जो आपके कोडबेस में कहीं नहीं है; वे पैटर्न जो उन्होंने पहले देखे हैं, वे नुकसान जिनकी वे जाँच करना जानते हैं, उस तरह का अनुभव जो आपको केवल बहुत सारी समान समस्याओं को हल करने से मिलता है। लेकिन पाँच मिनट का मतलब है आपके कोड का एक त्वरित पठन, हर फ़ाइल के माध्यम से सावधानीपूर्वक जाना नहीं।
उच्च प्रयास पर Sonnet पूरी दोपहर वाला सामान्यज्ञ है। वे कोडिंग में महान हैं, और वे सब कुछ पढ़ेंगे, चीज़ें चलाएँगे, अपने काम की दोबारा जाँच करेंगे, और अंत में आपके विशिष्ट कोड को अच्छी तरह से समझेंगे।
Fable वह विशेषज्ञ है जिसे आप तब बुलाते हैं जब बाकी सब अटक जाते हैं। कम प्रयास पर भी, वे उस चीज़ को देख लेंगे जो कोई और नहीं देखेगा। वह पहचान ही वह चीज़ है जिसके लिए आप सबसे अधिक भुगतान कर रहे हैं, इसलिए इसे उन कार्यों के लिए बचाना उचित है जिन्हें इसकी आवश्यकता है।
इनमें से कोई भी सार्वभौमिक रूप से "बेहतर" नहीं है। मॉडल सेटिंग मोटे तौर पर कितना सक्षम है; प्रयास सेटिंग मोटे तौर पर कितना गहन है। अधिकांश वास्तविक कार्यों में दोनों में से कुछ न कुछ चाहिए होता है।
प्रयास, मॉडल और टोकन खपत
तो मॉडल चयन, प्रयास और टोकन खपत सभी कैसे परस्पर क्रिया करते हैं? यह कार्य पर निर्भर करता है।
एक ही प्रयास स्तर पर नियमित कार्य पर, बड़े और छोटे दोनों मॉडल आम तौर पर इसे सही करते हैं। बड़ा मॉडल अतिरिक्त सत्यापन चरणों के साथ अधिक टोकन की खपत करता है, उच्च प्रति-टोकन मूल्य पर। यही कारण है कि नियमित अवधियों के लिए छोटे मॉडल पर आने से गुणवत्ता की कोई कीमत चुकाए बिना वास्तविक धन की बचत होती है।
वक्र केवल उदाहरण के लिए हैं, जो एक ही कार्य के लिए दिखाए गए हैं जो दोनों मॉडलों द्वारा जल्दी से पूरा करने के लिए पर्याप्त सरल है। वे वास्तविक बेंचमार्क डेटा का प्रतिनिधित्व नहीं करते हैं।
कठिन, बहु-चरणीय कार्य पर, समीकरण उलट जाता है। छोटे मॉडल को अपनी क्षमता की सीमा तक पहुँचने के लिए संघर्ष करना पड़ता है, पुनरावृत्तियों को जलाना पड़ता है, जबकि बड़ा मॉडल कम चरणों में समान गुणवत्ता स्तर तक पहुँचता है।
आप बड़े मॉडल के लिए प्रति टोकन अधिक भुगतान कर रहे हैं, लेकिन उन कार्यों पर जो वास्तव में छोटे मॉडल को फैलाते हैं, प्रति कार्य कुल लागत कम आ सकती है। और इससे भी महत्वपूर्ण बात: बड़ा मॉडल उन कार्यों को पूरा कर सकता है जो छोटा मॉडल नहीं कर सकता, उच्चतम प्रयास सेटिंग्स पर भी।
यह Fable के साथ सबसे अधिक स्पष्ट है। लंबे, बहु-चरणीय कार्य पर यह सबसे आगे निकल जाता है। हमारे परीक्षण में, इसने ऐसे काम पूरे किए जिन तक Opus और Sonnet किसी भी प्रयास स्तर पर नहीं पहुँच सकते। इसकी प्रति टोकन लागत भी सबसे अधिक है, जो इसे उस काम के लिए बचाने का दूसरा कारण है जिसे वास्तव में इसकी आवश्यकता है।
वक्र केवल उदाहरण के लिए हैं, जो एक ही कार्य के लिए दिखाए गए हैं जो दोनों मॉडलों को फैलाने के लिए पर्याप्त कठिन है। वे वास्तविक बेंचमार्क डेटा का प्रतिनिधित्व नहीं करते हैं।
उपरोक्त ग्राफ़ में मुख्य बिंदु: प्रयास यह चुनता है कि Claude वक्र के साथ कितनी दूर तक यात्रा करने को तैयार है। इसका मतलब यह नहीं है कि कार्य को पूरा करने के लिए Claude को उतनी दूर जाने की आवश्यकता होगी।
अंत में, प्रयास टोकन खपत को आकार देता है, लेकिन यह इसे सीमित नहीं करता है। सिस्टम में एकमात्र हार्ड कैप max_tokens है, जो हिट होने पर प्रतिक्रिया को बीच में ही काट देता है, लेकिन यह एक कुंद उपकरण है और ज्यादातर API डेवलपर्स के लिए प्रासंगिक है। टास्क बजट या अपने प्रॉम्प्ट में Claude को संक्षिप्त रहने के लिए कहने जैसे नरम नियंत्रण अधिक सहायक होते हैं। वे मार्गदर्शन हैं जिनका पालन करने के लिए मॉडल को प्रशिक्षित किया जाता है (यह सीमा के पास आने पर समाप्त करने का प्रयास करेगा) न कि एक दीवार जिससे वह टकराता है।
प्रयास बदलता है कि Claude कितना काम करता है। मॉडल बदलता है कि Claude क्या जानता है।
जब आप किसी परिणाम से नाखुश हों, तो कोई भी सेटिंग बदलने से पहले संदर्भ की जाँच करें: Claude को एक स्पष्ट प्रॉम्प्ट, सही टूल और कौशल, और अपने काम को सत्यापित करने का एक तरीका दें।
यदि Claude फिर भी गलती करता है, तो अपने आप से पूछें: क्या वह पर्याप्त नहीं जानता था, या क्या उसने पर्याप्त प्रयास नहीं किया? पर्याप्त न जानना एक मॉडल समस्या है, पर्याप्त प्रयास न करना एक प्रयास समस्या है।
यह लेख @lydiahallie द्वारा लिखा गया था, जो Claude Code टीम में तकनीकी कर्मचारी सदस्य हैं।
