Codex /goal कैसे इस्तेमाल करें: जारी काम, नियंत्रण, पूर्णता की शर्तें और टोकन बजट

अगर आप Codex को बार-बार “जारी रखो” भेजते हैं, तो एक विकल्प है /goal से काम पूरा होने की शर्तें बनाए रखना। यह बग को दोबारा पैदा करने, उसे सुधारने और परीक्षण के नतीजों के अनुसार अगला कदम चुनने जैसे कामों के लिए उपयोगी है। यह केवल लंबे समय तक काम करने का निर्देश नहीं है: यह उसी चैट में काम समाप्त करने की शर्तें सुरक्षित रखता है।

इस गाइड में बताया गया है कि इसे कब इस्तेमाल करें, डेस्कटॉप और CLI के नियंत्रण कैसे अलग हैं और काम रुकने पर क्या जाँचें। साथ ही, लक्ष्य के टोकन बजट को अपने प्लान की बची हुई उपयोग सीमा या बिल की अधिकतम राशि समझने से क्यों बचना चाहिए, यह भी समझाया गया है।

विशेषताओं की जाँच: 7 अक्टूबर 2026। यह व्याख्या OpenAI के आधिकारिक दस्तावेज़ों पर आधारित है। हमने इस लेख के लिए Goal mode चलाया नहीं है और न ही उसकी अवधि, उपयोग या परिणामों पर असर मापा है।

1. /goal क्या करता है: सामान्य अनुरोध, /plan और dot

/goal किसी Codex चैट में लगातार काम करने का लक्ष्य तय करता है। बीच में कोई परीक्षण विफल हो जाए, तो Codex मूल पूर्णता शर्तों को ध्यान में रखकर अगली कार्रवाई चुन सकता है। OpenAI बग की जाँच, प्रदर्शन सुधार, माइग्रेशन और शोध को ऐसे कामों के उदाहरण बताता है जिनमें अगला कदम जाँच से मिली जानकारी पर निर्भर करता है।

आधिकारिक व्याख्या के अनुसार लक्ष्य मौजूदा चैट में सहेजी गई स्थिति है। यह ऐसी वैश्विक याददाश्त नहीं है जो दूसरी चैटों पर अपने-आप लागू हो जाए, और न ही पूरे रिपॉज़िटरी के लिए नियम है। ज़रूरी कोड, परीक्षण और दस्तावेज़ उस चैट से उपलब्ध होने चाहिए। स्रोत: OpenAI Cookbook: Codex में Goals का उपयोग।

सिर्फ योजना बनाने से Goal mode का अपने-आप जारी रहना शुरू नहीं होता। /goal किसी दूसरे मॉडल से स्वतंत्र समीक्षा की गारंटी भी नहीं देता। dot से अंतर के लिए dot का उपयोग, कीमत और Codex को काम सौंपने की गाइड देखें। जानकारी उपलब्ध कराने के तरीके के लिए कॉन्टेक्स्ट इंजीनियरिंग देखें।

2. डेस्कटॉप, CLI और IDE में शुरुआत

इनमें /goal समान है, लेकिन शुरू करने के बाद नियंत्रण इंटरफ़ेस के अनुसार अलग होते हैं। लंबे काम की आधिकारिक गाइड डेस्कटॉप, CLI और IDE एक्सटेंशन में शुरुआत बताती है। उसका वेब वाला भाग ChatGPT Work को परिणाम, पाबंदियाँ और मूल्यांकन की शर्तें देने का तरीका बताता है; इससे यह साबित नहीं होता कि वेब इंटरफ़ेस में भी वही कमांड और नियंत्रण हैं।

CLI के लिए OpenAI Cookbook Codex 0.128.0 या उसके बाद के संस्करण को समर्थित बताता है। मौजूदा कॉन्फ़िगरेशन संदर्भ में features.goals को स्थिर और डिफ़ॉल्ट रूप से चालू बताया गया है। यह न मानें कि प्रायोगिक सुविधा चालू करने के पुराने निर्देश अब भी कॉन्फ़िगरेशन में जोड़ने ज़रूरी हैं। सुविधा न दिखे तो अपना इंटरफ़ेस, संस्करण और मौजूदा आधिकारिक निर्देश जाँचें।

स्रोत: लंबे समय तक चलने वाला काम, डेस्कटॉप स्लैश कमांड और कॉन्फ़िगरेशन संदर्भ। लेख के निर्देश नियंत्रणों का काम समझाते हैं; ये ऐप के हर संस्करण में जाँचे गए बटन नामों की सूची नहीं हैं।

3. पूरा होने की परिभाषा: अस्पष्ट लक्ष्य को जाँचने योग्य बनाना

“इसे अच्छी गुणवत्ता का बनाओ” या “पूरा होने तक जारी रखो” जैसे निर्देशों से तय करना मुश्किल होता है कि काम कब पूरा माना जाए। पूर्णता की शर्तें ऐसे परिणाम बतानी चाहिए जिन्हें आप जाँच सकते हों। स्क्रीन की चौड़ाई, सहेजने के बाद का व्यवहार, परीक्षण के नतीजे या तुलना के दस्तावेज़ स्पष्ट करें।

CLI में लक्ष्य का पाठ खाली नहीं होना चाहिए और अधिकतम 4,000 अक्षरों का होना चाहिए। पूरी लंबी स्पेसिफ़िकेशन भरने के बजाय उसके फ़ाइल पथ का संदर्भ दें और लक्ष्य में परिणाम, महत्वपूर्ण पाबंदियाँ और सत्यापन की शर्तें रखें। फ़ाइल देने से दूसरी चैट का इतिहास अपने-आप नहीं आ जाता। स्रोत: Codex CLI स्लैश कमांड।

अगर स्पेसिफ़िकेशन तय नहीं है, तो पहले कह सकते हैं: “अभी लागू मत करो। आवश्यकताएँ स्पष्ट करो और /goal का मसौदा बनाओ।” /plan के साथ विचार करने के बाद प्रस्तावित लक्ष्य खुद पढ़ें, पाबंदियाँ और दायरा जाँचें, फिर शुरू करें।

4. बग, इंटरफ़ेस और शोध के लिए अनुरोध के उदाहरण

निम्न अनुरोध इस लेख के लिए लिखे गए हैं। ये हमारे चलाए हुए सफल प्रयोगों के उदाहरण नहीं हैं। पहले जाँचें कि परीक्षण और ब्राउज़र उपलब्ध हैं या नहीं, और जो जाँच संभव न हो उसे “नहीं की गई” बताने की शर्त जोड़ें।

बग सुधार: दोबारा पैदा की गई समस्या और रिग्रेशन जाँच अलग रखें

/goal इस टू-डू ऐप में “हटाना पूर्ववत करें” ठीक करें, ताकि सबसे हाल में हटाया गया एक आइटम अपनी मूल जगह और पूर्णता स्थिति में वापस आ सके।
जोड़ने, पूर्णता बदलने, हटाने और सहेजने का मौजूदा व्यवहार बनाए रखें।
पहले समस्या दोबारा पैदा करें। सुधार के बाद वापसी की जगह, पूर्णता स्थिति, दोहरी वापसी की रोकथाम, लगातार हटाना और वापसी के बाद सहेजना जाँचें।
सिर्फ संबंधित फ़ाइलें और परीक्षण बदलें। नई डिपेंडेंसी न जोड़ें, बाहर प्रकाशित न करें, push न करें और कोई खरीदारी न करें।
कोई जाँच न चला सकें तो कारण और ज़रूरी वातावरण बताएँ। पूर्णता रिपोर्ट में बदली हुई फ़ाइलें, चलाए गए कमांड और उनके नतीजे तथा नहीं की गई जाँच शामिल करें।

केवल “परीक्षण पास करो” कहने पर सुविधाएँ हटाने वाला बदलाव भी लक्ष्य पूरा करता दिख सकता है। बनाए रखने वाले व्यवहार और बदलाव के अनुमत दायरे को जोड़ने से सुधार का तरीका चुनने के मानदंड मिलते हैं।

इंटरफ़ेस सुधार: दिखावट और उपयोग की शर्तें तय करें

/goal इस स्क्रीन को 390px और 1280px चौड़ाई पर बिना क्षैतिज ओवरफ़्लो के फिट करें। लंबे कार्य नामों पर भी पूर्णता और हटाने के बटन इस्तेमाल करने योग्य रहें।
मौजूदा डेटा संरचना या स्टोरेज फ़ॉर्मेट न बदलें।
उपलब्ध वास्तविक ब्राउज़र में दोनों चौड़ाइयाँ जाँचें। आइटम जोड़ना, पूर्णता बदलना, हटाना, फिर लोड करने के बाद डेटा सहेजा रहना और कीबोर्ड से उपयोग जाँचें।
ब्राउज़र परीक्षण उपलब्ध न हो तो चित्र या कोड की जाँच को वास्तविक उपयोग की जाँच पास होने के बराबर न मानें। उन जाँचों को नहीं की गई बताएँ।
प्रकाशित न करें, push न करें, खरीदारी न करें और उपकरण की सेटिंग न बदलें।

चौड़ाई के ये आँकड़े इस अनुरोध की परीक्षण शर्तें हैं, उत्पाद द्वारा समर्थित स्क्रीन चौड़ाइयों की गारंटी नहीं। वास्तविक ब्राउज़र में उपयोग के नतीजों को केवल कोड या चित्र देखकर मिले नतीजों से भी अलग रखें।

शोध: अज्ञात खाने भरने के बजाय प्रमाण रखें

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

“हर उत्तर मिलने तक अनिश्चित समय तक जारी रखो” तय करने से शोध की समाप्ति का बिंदु खो जाता है। जानकारी सार्वजनिक न हो तब भी खोजे गए स्रोतों और बचे सवालों की रिपोर्ट को अपेक्षित परिणाम बनाया जा सकता है।

5. लक्ष्य रोकना, फिर शुरू करना, बदलना और हटाना

डेस्कटॉप में इनपुट बॉक्स के ऊपर लक्ष्य की प्रगति वाली पंक्ति इस्तेमाल करें। CLI दस्तावेज़ों में निम्न कमांड दिए गए हैं। CLI की इस तालिका को डेस्कटॉप के बटन कार्यों की सूची न समझें।

काम के दौरान उसी चैट में अतिरिक्त जानकारी या पाबंदियाँ दे सकते हैं। “अभी प्रकाशित मत करो” या “इस सुविधा के बदलाव रद्द करो” जैसे बदले हुए निर्णय स्पष्ट कहें। लक्ष्य बदलने के बाद देखें कि पुराने परीक्षण के नतीजे अकेले नई पूर्णता शर्तों को साबित करते हैं या नहीं।

नियंत्रणों के स्रोत: CLI लक्ष्य कमांड और डेस्कटॉप लक्ष्य नियंत्रण।

6. टोकन बजट, उपयोग सीमा और कीमत

लगातार काम में लक्ष्य का काम कहाँ रोकना है और वह प्लान की उपयोग सीमा में से कितना खर्च करता है, इन दोनों को अलग समझें। लक्ष्य का बजट बचा हो तब भी खाते की उपयोग सीमा या कार्य वातावरण की समस्या आगे बढ़ने से रोक सकती है।

क्या /goal का अतिरिक्त शुल्क लगता है?

जाँची गई आधिकारिक कीमत संबंधी सामग्री में हमें /goal की हर शुरुआत के लिए अलग शुल्क नहीं मिला। फिर भी, बार-बार की मॉडल प्रोसेसिंग सामान्य Codex उपयोग में खर्च होती है। Goal mode चालू करने से परीक्षण, सुधार और जाँच के चक्र मुफ़्त और असीमित नहीं हो जाते।

OpenAI के अनुसार Work और Codex की उपयोग सीमा साझा है, और खपत मॉडल, काम और अन्य बातों के अनुसार बदलती है। प्लान की सीमा खर्च होने के बाद अतिरिक्त क्रेडिट से जारी रखने और API कुंजी से अलग बिल बनने में भी अंतर है। स्रोत: Work और Codex की कीमत तथा उपयोग सीमाएँ। प्लान चुनने और सीमा रीसेट होने के लिए ChatGPT Pro की कीमत और उपयोग सीमा की तुलना देखें।

बजट के आँकड़े क्या साबित करते हैं?

App Server के आधिकारिक डेवलपर दस्तावेज़ों में लक्ष्य का tokenBudget, उपयोग का फ़ील्ड tokensUsed और समय मापने का फ़ील्ड timeUsedSeconds दिया गया है। इससे लक्ष्य की आंतरिक स्थिति में बजट और प्रगति दर्ज करने की व्यवस्था की पुष्टि होती है। यह इन RPC फ़ील्ड नामों को उपयोगकर्ता के CLI फ़्लैग के रूप में लिखने का निर्देश नहीं है।

उन्हीं दस्तावेज़ों में बताया गया है कि लक्ष्य को नए लक्ष्य से बदलने पर लक्ष्य के उपयोग माप रीसेट हो जाते हैं। इसका अर्थ प्लान की बची उपयोग सीमा वापस मिलना नहीं है। समय मापने का फ़ील्ड होना भी ठीक दो घंटे बाद रुकने की गारंटी का प्रमाण नहीं है। स्रोत: App Server में लक्ष्य प्रबंधन।

7. काम रुकने पर क्या जाँचें

सक्रिय लक्ष्य हर रुकावट को अपने-आप पार नहीं करता। पहले मौजूदा लक्ष्य और आखिरी नतीजा देखें, फिर इस क्रम में जाँच करें।

Cookbook के अनुसार अपने-आप जारी रहना तब होता है जब चैट निष्क्रिय हो, लक्ष्य सक्रिय और बजट के भीतर हो तथा कोई दूसरी प्रोसेसिंग या उपयोगकर्ता का इनपुट लंबित न हो। केवल योजना वाला काम जारी रहने को शुरू नहीं करता और रुकावट लक्ष्य रोक देती है। किसी निरंतरता वाले टर्न में एक भी टूल न चलाया जाए, तो बेकार दोहराव रोकने के लिए अगली अपने-आप जारी रहने वाली कार्रवाई दबा दी जाती है।

बजट पूरा खर्च होने पर आधिकारिक डिज़ाइन मुख्य काम रोकता है और प्रगति, बाधाएँ तथा अगले कदम बताता है। बजट समाप्त होना और लक्ष्य हासिल होना अलग बातें हैं। फिर शुरू करने से पहले बाकी काम और अनुमानित खर्च देखें।

/goal शुरू करने से अनुमतियाँ या जुड़े संसाधन नहीं बढ़ते। आधिकारिक दस्तावेज़ों के अनुसार यह मौजूदा sandbox और मंज़ूरी नीति का पालन करता है। यह स्थानीय काम अपने-आप क्लाउड में नहीं ले जाता। कनेक्शन टूटने की संभावना हो तो रोकने और वातावरण उपलब्ध होने पर फिर शुरू करने की सलाह दी गई है। स्रोत: लंबे काम की अनुमतियाँ और जारी रहने की शर्तें।

“Selected model is at capacity” जैसी मॉडल की ओर से त्रुटि दिखे, तो उस संदेश के अनुसार जाँच करें। Codex के at capacity त्रुटि की जाँच और समाधान में इसे उपयोग सीमा से अलग समझाया गया है।

8. पूर्णता रिपोर्ट में कौन-से प्रमाण देखें

“पूरा हो गया” जैसा जवाब यह साबित नहीं करता कि माँगे गए परिणाम का सत्यापन हुआ है। मूल लक्ष्य से मेल खाते प्रमाण देखें। परीक्षण पास हों तब भी नहीं की गई उपयोग जाँच को पास हुआ न मानें।

प्रमाण कम हो तो उसी चैट में स्पष्ट अगला निर्देश दें: “फिर लोड करने के बाद सहेजा रहना जाँचो” या “इस दावे का मूल पाठ और शर्तें दिखाओ।” पूर्णता शर्तें बढ़ाएँ तो लक्ष्य भी बदलें। दूसरे एजेंट से जाँच करवानी हो तो उसका अलग, स्पष्ट अनुरोध करें। केवल एजेंट की रिपोर्ट पढ़ने वाली समीक्षा और काम दोबारा चलाकर करने वाली जाँच में अंतर रखें।

सामान्य Codex विकास में भी आवश्यकताएँ तय करने, लागू करने और सत्यापन का अनुरोध कर सकते हैं। Goal mode का लाभ कई चरणों में पूर्णता शर्तें बनाए रखना और उनसे अगला कदम चुनना है। उत्पादों और काम चलाने के तरीकों के अंतर के लिए Claude Code और Codex की तुलना देखें।

9. शुरू करने से पहले

एक बदलाव या व्याख्या पर्याप्त हो तो सामान्य अनुरोध उपयुक्त है। जब जाँच के नतीजों से अगला कदम बदलता हो और समान पूर्णता शर्तों के लिए काम दोहराना हो, तो /goal पर विचार कर सकते हैं। कितनी देर चला, इसके बजाय जाँचने योग्य परिणाम के आधार पर चुनें।

10. अक्सर पूछे जाने वाले सवाल

क्या हर बार “जारी रखो” भेजना बंद कर सकता हूँ?

लक्ष्य सक्रिय हो और अपने-आप जारी रहने की शर्तें पूरी हों, तो टर्न के बाद अगला काम शुरू हो सकता है। मंज़ूरी, बजट सीमा या बाधा के कारण फिर भी रुक सकता है। यह सुविधा मानवीय निर्णय की ज़रूरत पूरी तरह खत्म नहीं करती।

क्या /goal केवल क्लाउड के लिए है? PC बंद करने पर चलता रहेगा?

यह केवल क्लाउड के लिए नहीं है। डेस्कटॉप, Codex CLI और IDE एक्सटेंशन के लिए इसका उल्लेख है। जारी रहने के लिए ज़रूरी वातावरण काम चलने की जगह पर निर्भर है। सिर्फ लक्ष्य तय करने से यह साबित नहीं होता कि बंद स्थानीय PC पर काम चलता रहेगा।

क्या टोकन बजट बिल की सीमा की गारंटी देता है?

इसे बिल की सख्त अधिकतम राशि की गारंटी नहीं माना जा सकता। लक्ष्य का बजट प्लान की सीमा, अतिरिक्त क्रेडिट और API बिलिंग से अलग है। जाँची गई आधिकारिक सामग्री में लक्ष्य काउंटर और बिल राशि के सटीक संबंध की व्याख्या नहीं मिली।

क्या यह dot इस्तेमाल करने जैसा है?

/goal उसी Codex चैट में लक्ष्य और जारी काम का प्रबंधन करता है। dot लगातार सहायता, दूसरे कामों को सौंपना और समन्वय भी संभालता है। छोटे विकास कार्य के लिए Codex को सीधा अनुरोध पर्याप्त हो सकता है। अपने उद्देश्य और प्रगति का प्रबंधन किसे सौंपना है, उसके अनुसार चुनें।