Claude Code का /goal एक ऐसा कमांड है जिसमें आप एक शर्त लिख देते हैं कि "काम कब पूरा माना जाए", और उस बिंदु तक पहुँचने तक Claude खुद काम जारी रखता है। हर बार जब एक टर्न (Claude का एक जवाब) खत्म होता है, तो एक अलग छोटा मॉडल जाँचता है कि शर्त पूरी हुई या नहीं। अगर नहीं हुई, तो Claude को अगला काम करने के लिए भेजा जाता है। इस लेख में आधिकारिक दस्तावेज़ (24 अक्टूबर 2026 को जाँचे गए) के आधार पर इसका इस्तेमाल और रुकने की शर्तें समझाई गई हैं। साथ ही इस साइट पर असली काम में इसे आज़माने के नतीजे भी दिए गए हैं, जिनमें टोकन की मात्रा और तैयार काम की गुणवत्ता की जाँच शामिल है।
यह क्या करता है
अंतिम शर्त पूरी होने तक जारी रहता है
/goal सभी टेस्ट पास हों जैसा लिखते ही काम शुरू हो जाता है। यह तब तक चलता है जब तक शर्त पूरी न हो जाए, जाँचकर्ता इसे असंभव न बता दे, या कोई ऐसी त्रुटि न आ जाए जिसे ठीक करना ज़रूरी हो।
यह कैसे जाँचता है
एक अलग मॉडल हर बार जाँच करता है
जाँचकर्ता केवल वही नतीजे पढ़ता है जो बातचीत में दिखाई दिए हों। वह खुद फ़ाइलें नहीं देखता और न ही कमांड चलाता है, इसलिए शर्त ऐसी होनी चाहिए जिसे Claude के आउटपुट से साबित किया जा सके।
परीक्षण में क्या पता चला
एक टर्न वाले काम में अतिरिक्त खर्च बस एक जाँच का है
मशीनी तरीके से हो जाने वाला काम 321 आइटम होने पर भी एक टर्न में खत्म हो गया, इसलिए अतिरिक्त खर्च एक जाँच जितना ही रहा। जाँचकर्ता तैयार लेखन की छोटी-छोटी अस्वाभाविक बातें नहीं पकड़ पाया।
विषय-सूची
- 1. /goal क्या है: सामान्य अनुरोध, /loop और Stop हुक से अंतर
- 2. इस्तेमाल कैसे करें: सेट करना, स्थिति देखना, हटाना
- 3. जाँच कैसे होती है और कब रुकता है
- 4. शर्त कैसे लिखें
- 5. /goal के दो परीक्षणों के नतीजे (एक सामान्य अनुरोध की तुलना में)
- 6. क्या सीखा: किस तरह के काम में फ़ायदा और किसमें नहीं
- 7. Codex के /goal से अंतर
- सारांश
- FAQ
1. /goal क्या है: सामान्य अनुरोध, /loop और Stop हुक से अंतर
सामान्य तरीके से कोई काम माँगने पर Claude उसे पूरा मानकर रुक जाता है और अगले निर्देश का इंतज़ार करता है। /goal सेट करने पर हर टर्न (Claude के एक जवाब) के अंत में जाँच होती है। अगर शर्त अभी पूरी नहीं हुई है, तो आपके कुछ भेजे बिना भी अगला टर्न शुरू हो जाता है। आधिकारिक दस्तावेज़ में इस तरह के बड़े काम के अच्छे उदाहरण दिए गए हैं, जहाँ अंतिम स्थिति की जाँच हो सके:
- किसी मॉड्यूल को नए API पर ले जाना, जब तक हर कॉल की जगह कम्पाइल न हो जाए और टेस्ट पास न हों
- डिज़ाइन दस्तावेज़ लागू करना, जब तक सभी स्वीकृति शर्तें पूरी न हो जाएँ
- बड़ी फ़ाइलों को बाँटना, जब तक हर फ़ाइल तय आकार या उससे छोटी न हो जाए
- लेबल वाली समस्याओं की सूची को तब तक निपटाना, जब तक सूची खाली न हो जाए
इससे मिलती-जुलती तीन व्यवस्थाएँ हैं। आधिकारिक दस्तावेज़ समझाता है कि इन्हें "अगला टर्न कौन शुरू करता है" के आधार पर चुनना चाहिए।
| व्यवस्था | अगला टर्न कब शुरू होता है | कब रुकती है |
|---|---|---|
/goal | पिछला टर्न खत्म होने पर (बातचीत के दौरान, तय अंतराल की जाँच या अपने-आप दोबारा कोशिश में भी) | जब जाँचकर्ता शर्त पूरी होने या पूरी न हो सकने का फ़ैसला करे, जब कोई त्रुटि ठीक करनी हो, या जब आप /goal clear चलाएँ |
/loop | तय समय बीत जाने पर | जब आप उसे रोकें, या जब Claude काम खत्म माने |
| Stop हुक | पिछला टर्न खत्म होने पर | जब आपकी लिखी स्क्रिप्ट या प्रॉम्प्ट फ़ैसला करे |
असल में /goal एक "प्रॉम्प्ट से जाँचने वाला Stop हुक" है, और वह केवल उसी बातचीत में काम करता है। Stop हुक सेटिंग फ़ाइल में लिखा जाता है और सभी बातचीत पर लागू होता है। /goal उसी समय लिखा जाता है और केवल उसी बातचीत पर लागू होता है।
अनुमति मोड नहीं बदलता। अगर आप बिना पुष्टि के टर्न चलते रहना चाहते हैं, तो अनुमति मोड को ऑटो मोड पर सेट करें और फिर /goal इस्तेमाल करें। मैन्युअल मोड में रहने पर हर उस ऑपरेशन पर रुकना पड़ेगा जिसकी आपने अनुमति नहीं दी है। आधिकारिक दस्तावेज़ के अनुसार ऑटो मोड एक टर्न के भीतर की पुष्टियाँ कम करता है, जबकि /goal हर टर्न के निर्देश कम करता है, और दोनों को साथ इस्तेमाल किया जा सकता है।
स्रोत: Keep Claude working toward a goal (Claude Code आधिकारिक दस्तावेज़, 24 अक्टूबर 2026 को जाँचा गया)।
2. इस्तेमाल कैसे करें: सेट करना, स्थिति देखना, हटाना
एक बातचीत में एक ही लक्ष्य रखा जा सकता है। वही /goal कमांड इस बात के आधार पर सेट करने, जाँचने और हटाने, तीनों काम करता है कि उसके बाद क्या लिखा गया है।
- लक्ष्य सेट करें:
/goalके बाद शर्त लिखें उदाहरण:/goal test/auth के टेस्ट सभी पास हों और lint भी साफ़ हो। सेट करते ही टर्न शुरू हो जाता है, और शर्त खुद निर्देश का काम करती है, इसलिए अलग से कोई अनुरोध भेजने की ज़रूरत नहीं है। पहले से कोई लक्ष्य हो, तो नई शर्त उसकी जगह ले लेती है। शर्त 4,000 अक्षरों तक लिखी जा सकती है। - स्थिति देखें: केवल
/goalलिखें इससे शर्त, बीता समय, जाँच की गिनती, इस्तेमाल हुए टोकन और सबसे हाल की जाँच का कारण दिखता है। गिनती और कारण पहली जाँच के बाद दिखने लगते हैं। - रोकें:
/goal clearयह जाँच होने से पहले लक्ष्य हटा देता है।stop,off,reset,noneऔरcancelका भी यही मतलब है।/clearसे बातचीत नई करने पर भी लक्ष्य मिट जाता है।
बातचीत दोबारा शुरू करने पर जो लक्ष्य अभी पूरा नहीं हुआ था, वह वापस आ जाता है। शर्त वैसी ही रहती है, लेकिन टर्न, समय और टोकन की गिनती नए सिरे से शुरू होती है। यह डेस्कटॉप ऐप, रिमोट सत्र और claude -p से अपने-आप चलने वाले काम में भी काम करता है। claude -p "/goal …" एक ही चलाने में तब तक चलता रहता है जब तक लक्ष्य पूरा न हो। अगर आप बीच की प्रगति देखना चाहते हैं, तो --output-format stream-json --verbose जोड़ें।
डेस्कटॉप ऐप में शर्त चिपकाते समय सावधानी। अगर "/goal और कई पंक्तियों की शर्त" एक साथ चिपकाई जाए, तो पूरा पाठ साधारण चिपकाया गया पाठ बनकर जा सकता है और /goal कमांड की तरह काम नहीं करता (24 अक्टूबर 2026 को, Windows डेस्कटॉप ऐप और Claude Code 2.1.308 पर पुष्टि की गई)। इनपुट फ़ील्ड में /goal रंगीन दिखता है, इसलिए केवल देखकर फ़र्क नहीं पहचाना जा सकता। पक्का तरीका यह है कि /goal हाथ से टाइप करें, सुझावों में से चुनें, और उसके बाद शर्त चिपकाएँ। असर हुआ या नहीं, यह इससे जाँचें कि ठीक नीचे "Goal set:" से शुरू होने वाली पंक्ति आती है या नहीं।
3. जाँच कैसे होती है और कब रुकता है
हर टर्न खत्म होने पर Claude Code शर्त और अब तक की बातचीत को एक "छोटे और तेज़ मॉडल" को भेजता है। फ़ैसले तीन होते हैं, और हर एक के साथ एक छोटा कारण भी आता है। इस साइट के माहौल में जाँचकर्ता Claude Haiku 5.5 था (बातचीत के रिकॉर्ड से पुष्टि की गई)।
जाँचकर्ता कोई टूल इस्तेमाल नहीं करता, और वह केवल बातचीत में आई चीज़ों के आधार पर फ़ैसला करता है। वह फ़ाइलें दोबारा नहीं पढ़ता और न ही खुद टेस्ट चलाता है। अगर Claude लगातार कई टर्न तक बिना टूल इस्तेमाल किए केवल जाँचकर्ता को जवाब देता रहे, तो Claude Code लूप रोक देता है, चेतावनी दिखाता है और लक्ष्य बरकरार रखते हुए नियंत्रण आपको लौटा देता है।
त्रुटि से रुकने पर
| क्या हुआ | लक्ष्य | आगे क्या होता है |
|---|---|---|
| कोई त्रुटि जिसे आपको ठीक करना है (लॉगिन विफल, क्रेडिट शेष न होना, ऐसा संदर्भ-overflow जिसे अपने-आप का सारांश भी न सुलझा सके, कोई अनुपलब्ध मॉडल) | हट जाता है | कारण ठीक करके /goal फिर से सेट करें |
| डेस्कटॉप ऐप या क्लाउड सत्र में लॉगिन विफल होना | बना रहता है | लॉगिन ऐप खुद वापस संभालता है |
| ऐसी विफलता जो थोड़ी देर बाद ठीक हो जाती है (सर्वर पर भीड़, कनेक्शन टूटना) | बना रहता है | कुछ देर रुककर अपने-आप दोबारा कोशिश होती है, और तीन बार दोबारा कोशिश के बाद रुक जाती है (संस्करण 2.1.269 और बाद में, बातचीत के दौरान) |
| ऐसी विफलता जो दोबारा कोशिश करने पर भी वैसी ही रहेगी (API उपयोग सीमा, claude.ai उपयोग की सीमा, किसी हुक का टर्न रोक देना) | बना रहता है | रुक जाती है। अगर सेटिंग उपयोग सीमा के रीसेट होने का इंतज़ार करती है, तो सीमा रीसेट होने पर वहीं से फिर शुरू हो जाती है |
सबएजेंट या पृष्ठभूमि के काम चल रहे हों तो
अगर टर्न के अंत में कोई सबएजेंट या पृष्ठभूमि कमांड चल रहा हो, तो उस टर्न की जाँच टल जाती है। नतीजे आने पर वे Claude तक नए टर्न के रूप में पहुँचते हैं। इंतज़ार करते-करते 30 मिनट बीत जाएँ, तो "बीच की जाँच" होती है। यह चल रहे काम का आउटपुट पढ़ती है, और अगर प्रगति हो रही हो तो इंतज़ार करती है। अगर काम अटका हो, तो Claude को उसे ठीक करने या रोकने के लिए कहती है। डिफ़ॉल्ट रूप से अंतराल 30 मिनट, 1 घंटे और 2 घंटे पर दोगुना होता है, और उसके बाद हर 2 घंटे पर होता है। पहला अंतराल पर्यावरण चर CLAUDE_CODE_GOAL_CHECKIN_MINUTES से बदला जा सकता है, और इसे 0 करने पर बीच की जाँच और अपने-आप दोबारा कोशिश, दोनों रुक जाते हैं।
कब इस्तेमाल नहीं हो सकता और खर्च
जाँचकर्ता हुक व्यवस्था का हिस्सा है, इसलिए हुक की तरह यह उन फ़ोल्डरों में इस्तेमाल नहीं हो सकता जिन्हें आपने भरोसेमंद नहीं माना है। सेटिंग में disableAllHooks के true होने पर, या प्रशासक की सेटिंग में allowManagedHooksOnly चालू होने पर भी यह इस्तेमाल नहीं हो सकता, और तब कारण दिखाया जाता है। जाँच में लगे टोकन की गिनती छोटे और तेज़ मॉडल की दर से होती है। आधिकारिक दस्तावेज़ कहता है कि यह आम तौर पर मुख्य काम की तुलना में "बहुत ही कम" होता है। जाँचकर्ता मॉडल ANTHROPIC_DEFAULT_HAIKU_MODEL से बदला जा सकता है, लेकिन यह सेटिंग छोटे मॉडल का इस्तेमाल करने वाले दूसरे कामों पर भी असर डालती है, जैसे बातचीत का सारांश बनाना।
स्रोत: Keep Claude working toward a goal (24 अक्टूबर 2026 को जाँचा गया)।
4. शर्त कैसे लिखें
जाँचकर्ता केवल बातचीत पढ़ता है, इसलिए शर्त ऐसी लिखें जिसे Claude का अपना आउटपुट साबित कर सके। आधिकारिक दस्तावेज़ में लंबे समय तक ठीक से चलने वाली शर्त के तीन तत्व गिनाए गए हैं।
npm test सफलता के साथ खत्म हो" या "git status साफ़ हो" जैसा, यानी उसे कैसे साबित किया जाएगा।अगर आप चलने की लंबाई पर सीमा रखना चाहते हैं, तो उसे शर्त के भीतर लिखें, जैसे "या 20 टर्न पर रोक दें"। Codex के /goal में जैसी टोकन बजट वाली अलग सेटिंग है, वैसी सेटिंग आधिकारिक दस्तावेज़ में नहीं मिली।
| ऐसे लिखा गया | जाँचकर्ता के हिसाब से |
|---|---|
| गुणवत्ता सुधारो और पूरा होने तक जारी रखो | यह तय नहीं हो सकता कि "पूरा" का मतलब क्या है |
| जब तक सभी टेस्ट पास न हों, ठीक करते रहो | नतीजे बातचीत में आएँ तो जाँच हो सकती है, लेकिन कौन-से टेस्ट, यह साफ़ नहीं है |
npm test सफलता के साथ खत्म हो, और उसका आउटपुट बातचीत में दिखाया जाए (src/legacy न बदला जाए, 30 टर्न पर रोक दिया जाए) | अंतिम स्थिति, जाँचने का तरीका, क्या बनाए रखना है और सीमा, सब तय हैं |
इस साइट पर परीक्षण से मिली एक सावधानी यह है: जो बातें बनाए रखनी हों, उन्हें अलग निर्देश फ़ाइल में नहीं, शर्त के वाक्य में ही लिखें। जाँचकर्ता शर्त के शब्दों के अनुसार ही फ़ैसला करता है, इसलिए किसी और फ़ाइल में लिखा निर्देश अगर न माना गया हो, तब भी "पूरा" माना जा सकता है। इस साइट के प्रयोग में यह सच में हुआ (अध्याय 5 देखें)।
5. /goal के दो परीक्षणों के नतीजे (एक सामान्य अनुरोध की तुलना में)
इस साइट के लेखों में हमने वाक्य के अंत के विराम चिह्न एक जैसे करने का काम /goal से किया। जापानी लेखों में, मौजूदा लेखों में 1,035 जगहें थीं जहाँ वाक्य के अंत का "。" कहीं था और कहीं नहीं (यह इस साइट की उस जाँच स्क्रिप्ट से गिना गया जो वाक्य के अंत के विराम चिह्न देखती है)। सुधार का नियम तय था और अंतिम स्थिति साफ़ थी कि जाँच में "0 आइटम" हों, इसलिए इसे /goal के लिए उपयुक्त काम माना गया। हमने दायरा बदलकर /goal दो बार चलाया, और संदर्भ के लिए एक सामान्य अनुरोध का नतीजा भी साथ में रखा।
संदर्भ वाला चलना वह था, जब हमने /goal आज़माने के इरादे से शर्त एक साथ चिपकाई और अध्याय 2 की सावधानी के अनुसार वह कमांड नहीं बना, बल्कि सामान्य अनुरोध की तरह चला। इसी तरह के काम को सामान्य तरीके से माँगने के संदर्भ मूल्य के रूप में तालिका में रखा गया है (दायरा और गिनती अलग हैं, इसलिए यह सख्त तुलना नहीं है)। दोनों /goal चलाने के लिए हमने /goal हाथ से टाइप करके चुना और "Goal set:" की पंक्ति की पुष्टि की। ये चलाने 24 अक्टूबर 2026 को Windows डेस्कटॉप ऐप पर Claude Code 2.1.308 से हुए, जिसमें काम करने वाला मॉडल Claude Opus 5.5 था और अनुमति मोड ऑटो था।
| तुलना का बिंदु | संदर्भ: सामान्य अनुरोध | /goal (छोटा) | /goal (बड़ा) |
|---|---|---|---|
| दायरा और गिनती | 10 लेख, 166 आइटम | 9 लेख, 119 आइटम | 48 लेख, 321 आइटम |
| लगा समय | 6 मिनट 9 सेकंड | 5 मिनट 54 सेकंड | 10 मिनट 7 सेकंड |
| टर्न | 1 टर्न में खत्म | 1 टर्न में पूरा | 1 टर्न में पूरा |
| जाँच की गिनती, समय | कोई नहीं | 1, 5.6 सेकंड | 1, 9.0 सेकंड |
| काम करने वाले का आउटपुट टोकन | 15,254 | 14,750 | 27,835 |
| जाँचकर्ता के टोकन | कोई नहीं | आउटपुट 899, कैश लेखन 64,299 | आउटपुट 1,569, कैश लेखन 114,410 |
| Claude Code द्वारा दर्ज अनुमानित राशि | $1.33 | $1.26 | $2.74 |
| जाँच के बाद इंसान द्वारा ठीक की गई चीज़ें | कोई नहीं | कोई नहीं | अस्वाभाविक 2 वाक्य |
आँकड़े हर बातचीत के रिकॉर्ड (Claude Code द्वारा सहेजी गई JSONL फ़ाइलों) से जोड़े गए हैं। अनुमानित राशि वह है जिसे Claude Code ने API की दरों से गणना करके दर्ज किया। सदस्यता के इस्तेमाल पर इसका बिल नहीं बनता। हर नतीजा केवल एक-एक बार का है, और दायरा व गिनती हर बार अलग थे। अलग तरह के काम या मॉडल पर आँकड़े बदल सकते हैं। जाँचकर्ता का कैश लेखन उतनी बातचीत के बराबर है जितनी जाँच के लिए लोड की गई। अनुमानित राशि काम करने वाले और जाँचकर्ता, दोनों का कुल जोड़ है।
असल में लिखी गई शर्तें
ये वे शर्तें हैं जो दोनों /goal चलानों में /goal के बाद लिखी गईं। इस साइट के अपने नाम (जाँच स्क्रिप्ट, काम के नोट वाली फ़ाइल और रिकॉर्ड अपडेट करने वाले टूल के नाम) को ऐसे शब्दों से बदला गया जो बताएँ कि वे क्या करते हैं। काम के विस्तृत चरण (सुधार के पुराने उदाहरण और न छूने वाली फ़ाइलें) काम के नोट (Markdown फ़ाइल) में लिखे गए, और शर्त उस फ़ाइल की ओर इशारा करती है।
# छोटा रन
लेख 200 से 209 (9 लेख) के जापानी पाठ में, वाक्य के अंत की जाँच स्क्रिप्ट 0 आइटम दिखाए (9 लेखों में से हर एक का जाँच परिणाम बातचीत में दिखाएँ), और काम के नोट के चरणों के अनुसार commit और push भी पूरे हो जाएँ। 30 टर्न पर रोक दें।# बड़ा रन
लेख 100 से 199 के जापानी पाठ में, वाक्य के अंत की जाँच स्क्रिप्ट 0 आइटम दिखाए। ध्यान रखें: काम के नोट के चरणों का पालन करें (तय उदाहरणों के अनुसार केवल विराम चिह्न ठीक करें; शब्द, अर्थ, अनुवाद, मेटाडेटा और टूल न बदलें)। हर टर्न के अंत में "शेष ○ आइटम (○ लेख)" वाली एक पंक्ति लिखें। अंत में दायरे के सभी 48 लेखों के जाँच परिणाम, बदली गई फ़ाइलों की सूची (केवल पाठ और मिलान रिकॉर्ड), टैग जाँच का सफल होना, और मिलान रिकॉर्ड के अपडेट का परिणाम बातचीत में दिखाएँ, और फिर पथ देकर commit और push पूरे करें। Deploy न करें। 40 टर्न पर रोक दें।git diff --stat), टैग जाँच और रिकॉर्ड अपडेट, सब बातचीत में दिखाने की शर्त जोड़ी गई।छोटे रन में "हर टर्न शेष गिनती लिखें" केवल काम के नोट में लिखा था। Claude ने उसे लिखे बिना काम पूरा कर दिया, और जाँचकर्ता ने "प्रक्रिया का निर्देश नहीं माना गया, लेकिन शर्त उसकी माँग नहीं करती" लिखते हुए लक्ष्य को "पूरा" माना। इस सबक (अध्याय 4) को हमने बड़े रन की शर्त में शामिल किया।
तैयार काम की जाँच
हमने जाँचकर्ता के "पूरा" को सीधे सच नहीं माना। हर बार एक अलग बातचीत में अंतर (diff) को एक-एक पंक्ति करके देखा और जाँच दोबारा चलाई।
/goal रन ने ठीक किए गए टूल से 0 आइटम की पुष्टि की। जाँचकर्ता का "पूरा" इस पर निर्भर है कि जाँच टूल सही हो।6. क्या सीखा: किस तरह के काम में फ़ायदा और किसमें नहीं
मशीनी काम एक टर्न में खत्म हो जाते हैं
हर रन का काम एक ही टर्न में खत्म हो गया। एक टर्न के भीतर Claude कई दर्जन बार टूल इस्तेमाल कर सकता है (बड़े रन में Bash 32 बार इस्तेमाल हुआ), इसलिए जो काम स्क्रिप्ट से हो सकता है, वह 321 आइटम होने पर भी एक बार में हो जाता है। इसी वजह से /goal की मुख्य खूबी, "अगर और चाहिए तो अगले टर्न में जारी रखो", इस तरह के काम में कभी काम नहीं आई। ये नतीजे अलग-अलग दायरे के एक-एक रन से हैं, फिर भी संदर्भ वाले सामान्य अनुरोध और दो /goal रनों के बीच समय या तैयार काम की गुणवत्ता में बड़ा अंतर नहीं दिखा। अतिरिक्त खर्च हर रन में एक जाँच का था, और हर जाँच में 5.6 सेकंड और 9.0 सेकंड लगे (पूरा काम लगभग 6 मिनट और लगभग 10 मिनट में हुआ)।
जाँचकर्ता पूरी बातचीत पढ़ता है
बड़े रन में जाँचकर्ता ने 114,410 टोकन पढ़े, जो काम की पूरी बातचीत थी, जैसी की तैसी उसे दी गई। बातचीत जितनी लंबी होगी, हर जाँच उतनी भारी होगी। ऐसे काम में जो कई टर्न चलते हैं, या जो पहले से लंबी बातचीत के बीच में /goal शुरू करते हैं, वहाँ जाँच का खर्च इस रन से ज़्यादा होने की संभावना है।
जाँचकर्ता यह देखता है कि शर्त पूरी हुई या नहीं
जाँचकर्ता ने शर्त की चीज़ों को सटीक रूप से जाँचा, जैसे जाँच के परिणाम और commit मौजूद है या नहीं। दूसरी ओर, वह उन गुणों को नहीं देखता जो आँकड़ों में नहीं आते, जैसे कोई वाक्य स्वाभाविक लगता है या नहीं। "पूरा" का मतलब है कि शर्त में लिखी बात बातचीत में आ गई। यह तैयार काम की जाँच की जगह नहीं ले सकता।
इस प्रयोग में केवल "एक टर्न में खत्म होने वाले काम" को परखा गया। नीचे हमने आधिकारिक दस्तावेज़ के उदाहरण और लेखक की अपनी राय को अलग-अलग रखा है।
7. Codex के /goal से अंतर
OpenAI के Codex में भी इसी नाम का /goal है। इसकी अवधारणा (अंतिम शर्त को बनाए रखते हुए काम जारी रखना) एक जैसी है, लेकिन संचालन और सीमा तय करने का तरीका अलग है। Codex की विस्तृत जानकारी के लिए Codex के /goal का इस्तेमाल देखें।
| तुलना का बिंदु | Claude Code | Codex |
|---|---|---|
| संचालन | सेट करना, स्थिति देखना और हटाना (/goal clear)। बदलने के लिए नई शर्त से फिर सेट करें | देखना, संपादित करना, रोकना, फिर शुरू करना और हटाना (/goal edit, pause, resume, clear) |
| कौन जाँचता है | हर टर्न के अंत में एक अलग छोटा और तेज़ मॉडल बातचीत पढ़ता है | Codex काम और जाँच को बार-बार दोहराता है (यह उल्लेख नहीं है कि कोई अलग मॉडल जाँच करता है) |
| सीमा | कोई अलग सेटिंग नहीं है। "20 टर्न पर रोक दो" जैसा शर्त में लिखें | हर लक्ष्य के लिए टोकन बजट होता है |
| अपने-आप कब रुकता है | शर्त पूरी हुई या असंभव बताई गई, या कोई ठीक करने वाली त्रुटि आई (उपयोग सीमा या उपयोग की सीमा पर रुकता है) | शर्त पूरी हुई, बजट पूरा हुआ, या आपका निर्णय ज़रूरी है (खाते की उपयोग सीमा पर आगे नहीं चल सकता) |
स्रोत: Claude Code के लिए Keep Claude working toward a goal; Codex के लिए Using Goals in Codex (OpenAI Cookbook) और इस साइट का "Codex के /goal का इस्तेमाल"। दोनों 24 अक्टूबर 2026 तक की स्थिति के अनुसार।
सारांश
/goalएक ऐसा कमांड है जिसमें आप अंत की एक शर्त लिखते हैं, और एक अलग मॉडल हर टर्न के अंत में जाँचता है, जिससे Claude शर्त पूरी होने तक काम करता रहता है। सेट करना, स्थिति देखना और हटाना, तीनों एक ही कमांड से होते हैं।- जाँचकर्ता केवल बातचीत पढ़ता है। शर्त ऐसी लिखें कि उसकी अंतिम स्थिति, उसे जाँचने का तरीका और क्या बनाए रखना है, Claude के आउटपुट से साबित हो सके, और सीमा भी उसी में लिखें।
- अनुमति मोड नहीं बदलता, इसलिए अगर आप काम पूरी तरह सौंपना चाहते हैं तो
/goalको ऑटो के साथ मिलाएँ। - इस साइट के प्रयोग में मशीनी काम 321 आइटम होने पर भी एक टर्न में खत्म हुआ। इस एक-टर्न वाले काम में अतिरिक्त खर्च एक जाँच का था। लेखक की राय में फ़ायदा उस काम में दिखता है जो एक टर्न में पूरा न हो।
- "पूरा" का मतलब है कि शर्त में लिखी बात बातचीत में आ गई। वाक्यों की स्वाभाविकता जैसे तैयार काम की गुणवत्ता अलग से जाँचें।
- डेस्कटॉप ऐप में पूरी शर्त चिपकाने पर वह कमांड नहीं बन सकती। "Goal set:" की पंक्ति से पुष्टि करें।
शुरू करने के चरण: अनुमति मोड को ऑटो पर करें → अध्याय 4 के रूप में शर्त लिखें (अंतिम स्थिति, जाँचने का तरीका, क्या बनाए रखना है, सीमा) → /goal हाथ से टाइप करें, शर्त चिपकाएँ और "Goal set:" की पुष्टि करें → "पूरा" आने के बाद अंतर (diff) खुद पढ़ें।
FAQ
Q. क्या /goal इस्तेमाल करने से खर्च बढ़ता है?
हाँ, जाँचों के हिसाब से थोड़ा बढ़ता है। जाँच छोटा और तेज़ मॉडल करता है, और आधिकारिक दस्तावेज़ के अनुसार खर्च "आम तौर पर बहुत ही कम" होता है। इस साइट के प्रयोग में एक टर्न में खत्म हुए काम की एक ही जाँच थी, और उसमें कुछ सेकंड लगे। लेकिन जाँचकर्ता पूरी बातचीत पढ़ता है, इसलिए बातचीत जितनी लंबी होगी, हर जाँच उतनी ही भारी होगी।
Q. बीच में रोकना हो तो?
/goal clear से लक्ष्य हटाएँ। stop या cancel से भी यही होता है। claude -p से चलाते समय Ctrl+C से रोकें। लक्ष्य हटाने से अब तक हुए बदलाव वापस नहीं होते।
Q. Claude "खत्म" कहे फिर भी क्या जाँचकर्ता "अभी नहीं" कह सकता है?
हाँ। इसी के लिए एक अलग मॉडल जाँच करता है। अगर जाँचकर्ता "अभी नहीं" कहे, तो उसके कारण को संकेत मानकर अगला टर्न शुरू होता है। इसके उलट, शर्त के अनुरूप नतीजे बातचीत में आने पर लक्ष्य "पूरा" माना जाता है, इसलिए जो गुणवत्ता शर्त में नहीं लिखी गई, उसकी गारंटी नहीं होती।
Q. कितने टर्न पर रुकता है?
कोई तय सीमा नहीं है। शर्त पूरी होने, असंभव बताए जाने, ठीक करने लायक त्रुटि आने, या आपके हटाने पर यह रुकता है। सीमा चाहिए तो उसे शर्त में लिखें, जैसे "या 20 टर्न पर रोक दो"। जाँचकर्ता केवल बातचीत पढ़ता है, इसलिए "हर टर्न के अंत में बीते टर्नों की संख्या लिखो" जैसी बात भी शर्त में रखने से फ़ैसला आसान होता है। (इस प्रयोग का कोई रन एक टर्न से ज़्यादा नहीं चला, इसलिए सीमा पर रुकने का व्यवहार हमने नहीं परखा।)
Q. /loop और /goal में से किसे चुनूँ?
अगर अंतिम स्थिति तय है तो /goal, और अगर तय अंतराल पर एक ही चीज़ जाँचनी है तो /loop। उदाहरण के लिए "डिप्लॉय पूरा होने तक हर 5 मिनट में देखो" /loop के लिए ठीक है, और "सभी टेस्ट पास होने तक ठीक करते रहो" /goal के लिए।
संदर्भ: Keep Claude working toward a goal, Run prompts on a schedule, और Hooks guide (Claude Code आधिकारिक दस्तावेज़); Using Goals in Codex (OpenAI Cookbook)। 24 अक्टूबर 2026 को जाँचा गया।
