मॉडल कैसे चुनें: एक ही निर्देश के लिए, आखिरकार किस मॉडल का उपयोग करें

📚 सीरीज नेविगेशन: पिछला अध्याय〔29 Slack / Linear और SDK इंटीग्रेशन〕"अन्य स्थानों पर Codex को कॉल करने और इसे अपने उत्पाद में एम्बेड करने" के उन्नत तरीके के बारे में था। यह अध्याय कैमरे को वापस स्थानीय स्तर पर सबसे रोजमर्रा के फैसले पर ले जाता है—जिस क्षण आप एंटर दबाते हैं, उसके पीछे वास्तव में कौन सा मॉडल और कितनी शक्ति के साथ आपके लिए काम कर रहा है। अगला अध्याय〔31 उन्नत तकनीकें और गति बढ़ाना〕बताएगा कि पूरी प्रक्रिया को कैसे तेज और अधिक किफायती बनाया जाए।

सब कहते हैं कि "सबसे मजबूत मॉडल चुनना हमेशा सही होता है", मैंने भी काफी समय तक इस पर विश्वास किया।

कुछ समय के लिए मैंने डिफ़ॉल्ट मॉडल को gpt-5.5 पर लॉक कर दिया और रीजनिंग शक्ति (reasoning effort) को सीधे xhigh पर सेट कर दिया, ताकि "एक ही बार में सब ठीक हो जाए, दोबारा परेशान न होना पड़े"। जब तक कि एक दिन मैंने इसे एक वेरिएबल का नाम data से बदलकर payload करने के लिए नहीं कहा—यह तीस सेकंड का एक आसान काम था। इसने काम शुरू करने से पहले लगभग एक मिनट तक "गहन विचार" किया। मैं उस घूमते हुए रीजनिंग एनिमेशन को देखता रहा और मुझे पहली बार लगा कि "सबसे मजबूत" होना थोड़ा मूर्खतापूर्ण है।

सीधे शब्दों में कहें तो, मॉडल जितना मजबूत होगा उतना ही बेहतर होगा, ऐसा नहीं है; जो सबसे उपयुक्त हो, वह सबसे अच्छा है। एक साधारण टाइपो (typo) ठीक करने के काम के लिए फ्लैगशिप मॉडल + अधिकतम रीजनिंग का उपयोग करना वैसा ही है जैसे घास उखाड़ने के लिए खुदाई करने वाली मशीन (excavator) ले जाना—यह धीमा, खर्चीला और यह दर्शाता है कि आपको इसका उपयोग करना नहीं आता। इसके विपरीत, यदि आपके सामने किसी पूरे मॉड्यूल को रीफैक्टर करने जैसा कोई कठिन काम हो और आप जल्दी के चक्कर में हल्के मॉडल का उपयोग करते हैं, तो वह आपको एक ऐसा समाधान दे सकता है जो दिखने में तो ठीक लगे लेकिन वास्तव में उसमें तीन छिपी हुई गलतियाँ हों। इसे सुधारने में लगने वाला समय आपके अच्छे मॉडल को पांच बार चलाने के बराबर हो सकता है।

यह अध्याय विस्तार से समझाएगा कि "किसे काम पर लगाना है": Codex में अभी कौन से मॉडल उपलब्ध हैं, एक ऐसा घुमावदार नॉब (reasoning effort या रीजनिंग शक्ति) जो मॉडल बदलने से भी अधिक तुरंत प्रभाव दिखाता है, और एक "परिदृश्य → मॉडल + रीजनिंग शक्ति" तुलना तालिका जिसे मैं खुद हर दिन उपयोग करता हूँ। इसे पढ़ने के बाद, अगली बार जब आप /model पैनल खोलेंगे, तो आप असमंजस में नहीं पड़ेंगे।

इस अध्याय को पढ़ने के बाद, आपको मिलेगा:

• मापदंडों (parameters) को रटने के बिना एक निर्णय ढांचा: मॉडल चुनना मूल रूप से "काम कितना कठिन है" को "कितनी कंप्यूटिंग पावर लगानी चाहिए" से मिलाने के बारे में है
• Codex में वर्तमान में चुने जा सकने वाले मॉडल और उनकी भूमिकाएं, कौन सा डिफ़ॉल्ट है, और कौन से दो हटा दिए गए हैं
• एक ऐसा नॉब जिसे शुरुआती लोग सबसे अधिक अनदेखा करते हैं, लेकिन यह मॉडल बदलने से भी अधिक तुरंत प्रभाव दिखाता है—रीज़निंग शक्ति (reasoning effort)
• एक रेडी-टू-यूज़ तुलना तालिका: "किस काम के लिए कौन सा मॉडल + कितनी रीजनिंग शक्ति"
• बदलने के चार तरीके: डिफ़ॉल्ट बदलना, स्टार्ट करते समय निर्दिष्ट करना, बातचीत के दौरान अस्थायी रूप से बदलना, और सब-एजेंट के लिए अलग से कॉन्फ़िगर करना
• एक व्यावहारिक प्रक्रिया जिसका आप अनुसरण कर सकते हैं, ताकि आप खुद महसूस कर सकें कि "एक ही प्रॉम्प्ट, अलग सेटिंग्स" में क्या अंतर है

⚠️ मॉडल के नाम और उपलब्ध सीमा संस्करण और पैकेज के अनुसार बदल सकते हैं (जैसे कि नवीनतम फ्लैगशिप कौन सा है, आपका खाता कौन से चुन सकता है)। यह अध्याय "कैसे निर्णय लें, कैसे बदलें" की विधि के बारे में है। वास्तव में कौन से मॉडल उपलब्ध हैं, यह पूरी तरह से आपके स्थानीय /model पैनल में सूचीबद्ध मॉडलों पर निर्भर करता है, नामों को रटें नहीं। शामिल कमांड और कॉन्फ़िगरेशन आइटम Codex आधिकारिक दस्तावेज़ पर आधारित होने चाहिए।

---

01 पहले स्पष्ट करें: मॉडल चुनना "सबसे महंगा चुनने" के बारे में नहीं है

पहले निष्कर्ष: मॉडल चुनने का सार यह है कि "यह काम कितना कठिन है" को "कितनी कंप्यूटिंग पावर लगानी चाहिए" से मिलाया जाए—एक प्रतिशत भी अधिक देना बर्बादी है, और कम देना विफलता का कारण बन सकता है।

कई लोग (मुझ सहित) यह मान लेते हैं कि "वैसे भी सबसे मजबूत चुनना चाहिए, क्षमता की कोई सीमा नहीं होगी तो कोई गलती नहीं होगी"। इस सोच में कमी यह है कि यह केवल "क्या यह सही ढंग से किया जा सकता है" की गणना करता है, यह नहीं कि "कितना इंतजार करना होगा" और "कितना खर्च होगा"। वास्तविक विकास में, ये दोनों बातें आपको हर दिन प्रभावित करती हैं—

• आप एक दिन में Codex के साथ दर्जनों बार बातचीत करते हैं, यदि हर बार तीस सेकंड अतिरिक्त प्रतीक्षा करनी पड़े, तो दिन का एक बड़ा हिस्सा सिर्फ लोडिंग देखने में बीत जाएगा।
• सब्सक्रिप्शन पैकेज का उपयोग करने पर कोटा (quota) होता है, और API key का उपयोग करने पर सीधे पैसे खर्च होते हैं। फ्लैगशिप मॉडल की token कीमत हल्के मॉडल की तुलना में कई गुना अधिक होती है।

इसलिए मॉडल चुनने से पहले, अपने दिमाग में तीन वेरिएबल्स पर विचार करें:

यह काम कितना जटिल है? मैं कब तक इंतजार कर सकता हूँ? क्या मुझे इस लागत की परवाह है? इन तीनों का संतुलन आपको बता देगा कि किसे काम पर लगाना है।

आपकी स्थिति	किस दिशा में चुनना चाहिए
कठिन काम (आर्किटेक्चर, क्रॉस-मॉड्यूल रीफैक्टरिंग, मुश्किल bug)	फ्लैगशिप चुनें, पर्याप्त रीजनिंग शक्ति दें, सटीकता पहली प्राथमिकता है
सरल काम (नाम बदलना, टिप्पणियाँ जोड़ना, छोटा फ़ंक्शन लिखना)	हल्के मॉडल, कम रीजनिंग शक्ति का उपयोग करें, गति और बचत के लिए
तुरंत उत्तर चाहिए (रियल-टाइम पेयरिंग, तेजी से सवाल-जवाब)	तत्काल प्रतिक्रिया के लिए अनुकूलित मॉडल का उपयोग करें, इसे "बहुत अधिक सोचने" न दें

💡 एक वाक्य में सारांश: मॉडल चुनना सबसे मजबूत चुनना नहीं है, बल्कि "कंप्यूटिंग पावर" को "काम की कठिनाई" के साथ मिलाना है।

---

02 Codex में वर्तमान में कौन से मॉडल चुने जा सकते हैं

जब आप /model पैनल खोलेंगे, तो आपको नामों की एक सूची दिखाई देगी। शुरुआती लोगों की पहली प्रतिक्रिया अक्सर होती है कि "यह सब क्या है"। घबराएं नहीं, भूमिका याद रखें, मापदंडों को नहीं।

समानता: मॉडल चुनना किसी काम के लिए सही व्यक्ति को नियुक्त करने जैसा है। कठिन आर्किटेक्चर काम के लिए, आप सबसे अनुभवी और सबसे गहराई से सोचने वाले व्यक्ति को भेजते हैं (फ्लैगशिप); छोटे बदलावों के लिए, एक फुर्तीला इंटर्न ही काफी है (हल्का); लाइव पेयरिंग के लिए जहां आपको तुरंत जवाब चाहिए, सबसे तेज़ प्रतिक्रिया देने वाले व्यक्ति को भेजें (रियल-टाइम)। सही व्यक्ति को चुनने से काम आसान हो जाता है; गलत चुनने से या तो संसाधन बर्बाद होते हैं या काम ठीक से नहीं हो पाता।

वर्तमान में Codex के कुछ मॉडल और उनकी भूमिकाएं इस प्रकार हैं:

मॉडल	भूमिका	इसके लिए सबसे उपयुक्त	गति / लागत
gpt-5.5	फ्लैगशिप, डिफ़ॉल्ट अनुशंसित	जटिल प्रोग्रामिंग, कंप्यूटर संचालन, ज्ञान कार्य, अनुसंधान कार्यप्रवाह	धीमा / उच्चतम
gpt-5.4-mini	हल्का, तेज़ और किफायती	हल्के प्रोग्रामिंग कार्य, सब-एजेंट के लिए	तेज़ / कम
gpt-5.3-codex-spark	तत्काल प्रकार (अनुसंधान पूर्वावलोकन)	लगभग वास्तविक समय के उच्च-आवृत्ति प्रोग्रामिंग पुनरावृत्ति (मुख्य रूप से सादा पाठ, थोड़ी कम क्षमता)	बहुत तेज़ / कम

कुछ मुख्य बिंदु, जिन्हें याद रखकर आप गलतियों से बच सकते हैं:

• यदि निर्दिष्ट नहीं किया गया है, तो डिफ़ॉल्ट का उपयोग किया जाएगा。 यदि आपने इसे कभी सेट नहीं किया है, तो Codex (App / CLI / IDE एक्सटेंशन) स्वचालित रूप से अनुशंसित फ्लैगशिप मॉडल का उपयोग करेगा, जो अधिकांश स्थितियों के लिए पर्याप्त है।
• gpt-5.3-codex-spark एक अनुसंधान पूर्वावलोकन (research preview) है, जो वर्तमान में केवल ChatGPT Pro ग्राहकों के लिए उपलब्ध है。 यदि यह दिखाई नहीं देता है तो यह सामान्य है, ऐसा नहीं है कि आपने गलत इंस्टॉल किया है।
• दो नाम ऐसे हैं जो आपने पुराने ट्यूटोरियल में देखे होंगे, अब उनका उपयोग न करें: gpt-5.2 और gpt-5.3-codex को ChatGPT लॉगिन विधि के तहत आधिकारिक रूप से अप्रचलित (deprecated) चिह्नित किया गया है। यदि आपकी स्क्रिप्ट, config.toml या codex exec --model में अभी भी ये लिखे हैं, तो उन्हें जल्द से जल्द नवीनतम में बदलें। कुछ अप्रचलित मॉडल अभी भी API साइड पर कॉल किए जा सकते हैं, लेकिन उसके लिए API key के साथ लॉगिन करना होगा, और यह आधिकारिक API मॉडल पेज के अधीन है।

मेरा अपना सबसे पसंदीदा संयोजन यह है: मुख्य बातचीत के लिए फ्लैगशिप, और बैच में होने वाले आसान कामों के लिए सब-एजेंट + gpt-5.4-mini。 पिछले महीने एक प्रोजेक्ट में 20 से अधिक फ़ाइलों में अप्रचलित (expired) imports को साफ़ करने के लिए, मैंने मुख्य एजेंट से काम को विभाजित करने के लिए कहा, और एक दर्जन से अधिक सब-एजेंटों ने समानांतर (parallel) रूप से mini का उपयोग करके इसे बदल दिया। कुछ ही मिनटों में काम पूरा हो गया—इस तरह के "अधिक संख्या में और सरल" काम के लिए, mini की गति और लागत का लाभ स्पष्ट रूप से दिखाई देता है, फ्लैगशिप का उपयोग करना पैसे और समय की बर्बादी होगी।

💡 एक वाक्य में सारांश: भूमिकाओं को याद रखें, मापदंडों को नहीं—फ्लैगशिप कठिन काम के लिए, mini तेज़ और किफायती काम के लिए, spark तुरंत उत्तर के लिए, और दो अप्रचलित नामों को कभी भी कॉन्फ़िगरेशन में न लिखें।

तीनों मॉडलों को "कार्य कठिनाई × गति-लागत" चार्ट पर रखकर यह स्पष्ट हो जाता है: जितना अधिक आप नीचे दाईं ओर जाते हैं, काम उतना ही कठिन होता जाता है, मॉडल उतना ही मजबूत लेकिन धीमा और महंगा होता जाता है (फ्लैगशिप gpt-5.5), और जितना अधिक आप ऊपर बाईं ओर जाते हैं, यह उतना ही तेज़ और किफायती होता जाता है (mini, spark)—मॉडल चुनना आपके काम के स्थान को चार्ट के अनुसार सेट करना है।

---

03 मॉडल बदलने से भी अधिक तुरंत प्रभाव दिखाने वाला नॉब: रीजनिंग शक्ति

शुरुआती लोग "कौन सा मॉडल बदलना है" इस पर ध्यान देते हैं, जबकि अनुभवी लोग एक और नॉब का उपयोग करते हैं—रीज़निंग शक्ति (reasoning effort)। कई लोग इस पर बिल्कुल ध्यान नहीं देते हैं, लेकिन अनुभव पर इसका प्रभाव अक्सर मॉडल बदलने से भी अधिक सीधा होता है।

समानता: रीजनिंग शक्ति उत्तर देने से पहले सोचने के लिए दिए गए समय की तरह है。 एक ही मेधावी छात्र (एक ही मॉडल) से यदि आप तुरंत उत्तर देने को कहें, या उसे पहले रफ काम करने और बार-बार जांच करने के बाद उत्तर देने को कहें, तो दोनों के उत्तर की गुणवत्ता में बहुत बड़ा अंतर होगा—लेकिन बाद वाला स्पष्ट रूप से धीमा होगा। रीजनिंग शक्ति को समायोजित करना यह तय करता है कि "इसे काम शुरू करने से पहले कितनी देर तक सोचने देना है"।

Codex की रीजनिंग शक्ति पांच स्तरों में विभाजित है (केवल समर्थित मॉडलों और Responses API के लिए प्रभावी):

स्तर	अर्थ	इसके लिए उपयुक्त
minimal	लगभग कोई अतिरिक्त सोच नहीं, तुरंत उत्तर	अत्यंत सरल कार्य, उच्च-आवृत्ति प्रश्नोत्तर
low	थोड़ा विश्लेषण	सरल परिवर्तन, त्वरित पुनरावृत्ति
medium	गति और गहराई का संतुलन (सामान्य डिफ़ॉल्ट स्तर)	दैनिक अधिकांश प्रोग्रामिंग कार्य
high	गहन रीजनिंग	जटिल रीफैक्टरिंग, मुश्किल bug
xhigh	अधिकतम रीजनिंग (मॉडल के समर्थन पर निर्भर करता है)	सबसे कठिन आर्किटेक्चर और डिबगिंग

दो बातें ध्यान में रखें: medium आमतौर पर डिफ़ॉल्ट शुरुआती बिंदु होता है (विशिष्ट डिफ़ॉल्ट मान आपके स्थानीय संस्करण पर निर्भर करता है); xhigh सभी मॉडलों द्वारा समर्थित नहीं है—यह जांचने के लिए कि इसका उपयोग किया जा सकता है या नहीं, सीधे /model पैनल में इसे चुनकर देखें। यदि यह अमान्य है या त्रुटि देता है, तो पैनल में आमतौर पर एक संकेत दिखाई देगा; आप पुष्टि करने के लिए वर्तमान मॉडल के आधिकारिक विवरण पृष्ठ को भी देख सकते हैं।

यही शुरुआत में बताई गई "वेरिएबल नाम बदलने के लिए एक मिनट प्रतीक्षा करने" की घटना की सच्चाई है—मॉडल बेवकूफ नहीं था, बल्कि मैंने रीजनिंग शक्ति को xhigh पर सेट कर दिया था, और यह एक ऐसे काम के लिए बहुत अधिक सोच रहा था जिसमें सोचने की बिल्कुल आवश्यकता नहीं थी。 इसके विपरीत, एक बार जब मैं एक यादृच्छिक (random) समवर्ती (concurrent) bug को ढूंढ रहा था, तो सामान्य स्तर पर यह काफी देर तक बिना किसी नतीजे के घूमता रहा। मैंने तीव्रता को बढ़ाकर high कर दिया और दोबारा चलाया, तब जाकर इसने वास्तव में गहराई से सोचकर रेस कंडीशन (race condition) के कारणों और समाधानों को स्पष्ट किया।

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

💡 एक वाक्य में सारांश: मॉडल बदलने से पहले रीजनिंग शक्ति के बारे में सोचें—यदि यह पर्याप्त स्मार्ट न लगे तो इसे एक स्तर ऊपर करें, यदि यह धीमा लगे तो एक स्तर नीचे करें, अक्सर सिर्फ इसे घुमाने से ही काम हो जाता है।

---

04 व्यावहारिक संदर्भ तालिका: किस काम के लिए कौन सा मॉडल + कितनी रीजनिंग शक्ति

सिर्फ सिद्धांतों को समझाने से बेहतर है सीधे नुस्खा देना। नीचे दी गई तालिका मेरी अपनी दैनिक उपयोग की "परिदृश्य → मॉडल + रीजनिंग शक्ति" तुलना तालिका है, आप इसे कॉपी कर सकते हैं और अपनी आदतों के अनुसार समायोजित कर सकते हैं:

परिदृश्य	अनुशंसित मॉडल	रीजनिंग शक्ति
आर्किटेक्चर डिज़ाइन, तकनीक चयन	gpt-5.5	high / xhigh
क्रॉस-मॉड्यूल रीफैक्टरिंग, जटिल संशोधन	gpt-5.5	high
मुश्किल / यादृच्छिक bug डिबगिंग	gpt-5.5	high
दैनिक सुविधाएँ लिखना, तर्क जोड़ना	gpt-5.5	medium
छोटे bug ठीक करना, स्वरूपण (formatting) समायोजित करना, टिप्पणियाँ जोड़ना	gpt-5.4-mini	low
सब-एजेंटों द्वारा बैच में सरल कार्यों को संसाधित करना	gpt-5.4-mini	low / medium
रियल-टाइम पेयरिंग, उच्च-आवृत्ति त्वरित प्रश्नोत्तर	gpt-5.3-codex-spark	minimal

इस तालिका का उपयोग कैसे करें? शुरुआत में बहुत अधिक चिंता न करें, बस "दैनिक मोड" (फ्लैगशिप + medium) से शुरुआत करें, और विशिष्ट समस्याओं का सामना करने पर ही तदनुसार समायोजित करें:

• यदि इसका समाधान बहुत सतही है और सीमा मामलों (boundary cases) को छोड़ देता है → तीव्रता को high पर सेट करें।
• यदि बहुत सारे और सरल मैन्युअल काम आपको धीमा कर रहे हैं → gpt-5.4-mini पर स्विच करें और बैच में चलाएं।
• यदि आप केवल कुछ छोटे प्रश्न पूछना चाहते हैं और इसके सोचने की प्रतीक्षा नहीं कर सकते → तत्काल प्रकार के मॉडल और minimal का उपयोग करें।

मेरी वास्तविक आदत है: डिफ़ॉल्ट कॉन्फ़िगरेशन "फ्लैगशिप + medium" है, अधिकांश कार्यों के लिए इसे बदलने की आवश्यकता नहीं होती; केवल तभी जब मैं "कठिन काम करने" या "बैच में काम करने" के मोड में प्रवेश करता हूँ, तो मैं इसे मैन्युअल रूप से स्विच करता हूँ。 स्विच करने को अपने टूलबॉक्स में एक स्क्रू ड्राइवर की तरह समझें जिसका उपयोग जरूरत पड़ने पर किया जाता है, न कि हर समय हाथ में पकड़े जाने वाले हथौड़े की तरह—जरूरत होने पर ही इसे निकालें, हर बार इस पर परेशान न हों।

💡 एक वाक्य में सारांश: डिफ़ॉल्ट रूप से "फ्लैगशिप + medium" का उपयोग करें, और केवल "कठिन कार्यों" और "बैच कार्यों" के दौरान ही मैन्युअल रूप से बदलें।

---

05 स्विच करने के चार तरीके: डिफ़ॉल्ट, स्टार्ट, बातचीत और सब-एजेंट

यह जानने के बाद कि किसे चुनना है, आपको यह भी पता होना चाहिए कि कैसे स्विच करना है। Codex चार तरीके प्रदान करता है, जो "हमेशा के लिए" से लेकर "केवल इस बार" तक की सभी आवश्यकताओं को कवर करते हैं।

① डिफ़ॉल्ट मॉडल सेट करें (हमेशा के लिए)。 कॉन्फ़िगरेशन फ़ाइल ~/.codex/config.toml में एक लाइन लिखें, और इसके बाद शुरू होने वाले सभी सत्र इसका उपयोग करेंगे:

# ~/.codex/config.toml
model = "gpt-5.5"
model_reasoning_effort = "medium"

② प्रारंभ करते समय अस्थायी रूप से निर्दिष्ट करें (केवल इस सत्र के लिए)。 -m / --model फ्लैग का उपयोग करें:

# 用指定模型起一个新会话
codex -m gpt-5.5

# codex exec 非交互模式同样适用
codex exec -m gpt-5.4-mini "把这个文件里的过期 import 清理掉"

③ बातचीत के दौरान स्विच करें (बीच में बदलना)。 Codex सत्र में सीधे स्लैश कमांड टाइप करें, एक चयनकर्ता दिखाई देगा, उसमें से एक चुनें और स्विच करें:

/model

नए संस्करण के /model पैनल में, आप आमतौर पर मॉडल चुनने के साथ-साथ रीजनिंग शक्ति भी चुन सकते हैं। यह वास्तव में कैसा दिखता है, यह आपके स्थानीय पैनल पर निर्भर करता है।

④ सब-एजेंटों के लिए अलग से कॉन्फ़िगर करें (काम का विभाजन)。 मुख्य एजेंट प्रबंधन के लिए फ्लैगशिप का उपयोग करता है, और सरल बैच कार्यों को gpt-5.4-mini चलाने वाले सब-एजेंटों को सौंपता है—यह सबसे किफायती तरीका है, विवरण के लिए देखें〔21 सब-एजेंट (Subagents)〕।

चारों तरीकों की तुलना:

विधि	कैसे करें	प्रभाव क्षेत्र	कब उपयोग करें
डिफ़ॉल्ट बदलें	config.toml में model लिखें	इसके बाद के सभी सत्र	जब आपके पास एक स्थिर मुख्य मॉडल हो
प्रारंभ करते समय निर्दिष्ट करें	codex -m <मॉडल>	केवल वर्तमान सत्र	काम शुरू करने के लिए अस्थायी रूप से मॉडल बदलना हो
बातचीत के दौरान बदलें	/model	स्विच करने के बाद	जब बीच में लगे कि मॉडल बदलना चाहिए
सब-एजेंट कॉन्फ़िगरेशन	सब-एजेंट सेटिंग्स में निर्दिष्ट करें	वह विशिष्ट सब-एजेंट	जब मुख्य एजेंट प्रबंधन करे और सरल काम बाहर सौंपे जाएं

⚠️ एक अपवाद: क्लाउड Codex Cloud कार्यों के लिए वर्तमान में डिफ़ॉल्ट मॉडल को बदला नहीं जा सकता है, यह बिंदु आधिकारिक विवरण के अधीन है。

💡 एक वाक्य में सारांश: हमेशा के लिए config बदलें, अस्थायी काम के लिए -m का उपयोग करें, बातचीत के दौरान बदलने के लिए /model टाइप करें, और सरल कामों को mini सब-एजेंट को सौंपें।

---

06 अनुभव को और बेहतर बनाने वाले दो छोटे स्विच

एक बार मॉडल और तीव्रता तय हो जाने के बाद, अनुभव को और अधिक सुविधाजनक बनाने के लिए दो छोटे स्विच हैं। केवल यह जानना पर्याप्त है कि वे मौजूद हैं, शुरुआत में इनके साथ छेड़छाड़ करने की आवश्यकता नहीं है।

① रीज़निंग सारांश (model_reasoning_summary)—आप इसकी "सोचने की प्रक्रिया" को कितना देखना चाहते हैं。 इसके मान auto / concise / detailed / none हो सकते हैं। यदि आप देखना चाहते हैं कि यह चरण-दर-चरण कैसे सोचता है, तो detailed पर सेट करें; यदि आपको लगता है कि यह स्क्रीन को भर रहा है, तो सीधे बंद करने के लिए none पर सेट करें:

# ~/.codex/config.toml
model_reasoning_summary = "concise"

② सेवा स्तर (service_tier)—अपने अनुरोध को प्राथमिकता दें。 इसमें flex (लचीला, लागत अनुकूलित, थोड़ा धीमा हो सकता है) और fast (गति प्राथमिकता) शामिल हैं। यदि आप जल्दी में हैं और लागत की परवाह नहीं करते हैं, तो आप fast का प्रयास कर सकते हैं—ध्यान दें कि इसे प्रभावी बनाने के लिए आधिकारिक तौर पर एक feature flag को भी साथ में जोड़ने की आवश्यकता होती है:

# ~/.codex/config.toml
# 弹性模式（默认）
service_tier = "flex"

# 快速模式：需同时开启 feature flag，否则不生效
service_tier = "fast"
[features]
fast_mode = true

ये दोनों ऐसे विवरण हैं जिन्हें "अभ्यस्त होने के बाद ही छूना चाहिए"। शुरुआती लोगों के लिए डिफ़ॉल्ट सेटिंग्स रखना पूरी तरह से सही है।

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

---

07 动手环节：亲手感受「同一句话，不同档位」

केवल तालिका देखने से काम नहीं चलेगा, जब आप खुद नॉब को घुमाएंगे, तभी आपको अंतर याद रहेगा। नीचे दिए गए तीन चरण पाँच मिनट में पूरे किए जा सकते हैं।

पहला चरण: देखें कि आपके खाते के लिए कौन से मॉडल उपलब्ध हैं。

Codex सत्र में प्रवेश करें और टाइप करें:

/model

अपेक्षित आउटपुट: एक मॉडल चयनकर्ता दिखाई देगा, जो आपके वर्तमान खाते / पैकेज के लिए उपलब्ध मॉडल सूचीबद्ध करेगा (हर किसी के लिए अलग दिखना सामान्य है)। पहले देखें कि कौन से उपलब्ध हैं और वर्तमान में कौन सा चयनित है।

दूसरा चरण: एक डिफ़ॉल्ट कॉन्फ़िगरेशन सेट करें。

फ़ाइल ~/.codex/config.toml खोलें (यदि नहीं है तो बनाएं), और लिखें:

model = "gpt-5.5"
model_reasoning_effort = "medium"

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

तीसरा चरण: एक ही प्रॉम्प्ट को दो अलग-अलग रीजनिंग शक्तियों पर चलाएं और अंतर की तुलना करें。

एक ऐसा काम चुनें जो थोड़ा कठिन हो, जैसे "इस फ़ंक्शन को अधिक आसानी से परीक्षण योग्य (testable) बनाने के लिए रीफैक्टर करने में मेरी मदद करें, और अपने निर्णयों को स्पष्ट करें"।

1. पहले डिफ़ॉल्ट medium के साथ चलाएं, और ध्यान दें: इसने कितना समय लिया और समाधान कितना व्यापक है。
2. कॉन्फ़िगरेशन में model_reasoning_effort को बदलकर high करें, सत्र को पुनरारंभ करें, और उसी प्रॉम्प्ट को फिर से चलाएं।

अपेक्षित परिणाम: आप देखेंगे कि high पर चलने वाला प्रयास स्पष्ट रूप से धीमा है, लेकिन समाधान अक्सर अधिक गहराई से सोचा गया होता है—उदाहरण के लिए, इसमें अधिक सीमा मामलों (boundary cases) पर विचार किया गया होगा, वैकल्पिक समाधान या फायदे-नुकसान (trade-offs) का विश्लेषण दिया गया होगा। इस "थोड़ा धीमा, लेकिन अधिक गहरा" होने के अंतर को स्वयं महसूस करने के बाद, आप भविष्य में आसानी से स्तरों को समायोजित कर पाएंगे, आपको तालिका को रटने की आवश्यकता नहीं होगी।

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

---

सारांश

इस अध्याय में "काम पर किसे लगाना है" को दो स्तरों के नॉब और एक रणनीति में विभाजित किया गया है:

• मॉडल चुनने का सार: कार्य की कठिनाई को कंप्यूटिंग पावर से मिलाना, जितना अधिक मजबूत होगा उतना बेहतर होगा ऐसा नहीं है, बल्कि जो सबसे उपयुक्त हो वही बेहतर है।
• वर्तमान मॉडलों को जानें: फ्लैगशिप gpt-5.5 कठिन कार्यों के लिए, gpt-5.4-mini त्वरित और किफायती विविध कार्यों के लिए, gpt-5.3-codex-spark तुरंत उत्तर के लिए; gpt-5.2 और gpt-5.3-codex अप्रचलित हो चुके हैं, इन्हें कॉन्फ़िगरेशन में न लिखें।
• रीजनिंग शक्ति एक छिपा हुआ तुरुप का पत्ता है: यदि यह स्मार्ट न लगे तो एक स्तर ऊपर करें, यदि यह धीमा लगे तो एक स्तर नीचे करें, यह अक्सर मॉडल बदलने से भी अधिक तेज़ परिणाम देता है।
• एक संदर्भ तालिका + एक आदत: डिफ़ॉल्ट रूप से "फ्लैगशिप + medium" का उपयोग करें, और केवल "कठिन कार्यों" और "बैच कार्यों" के दौरान ही मैन्युअल रूप से स्विच करें।
• बदलने के चार तरीके: डिफ़ॉल्ट बदलना, स्टार्ट करते समय निर्दिष्ट करना, सत्र के भीतर बदलना, और सब-एजेंट के लिए अलग से कॉन्फ़िगर करना, आवश्यकतानुसार उपयोग करें।

अब आप यह करने में सक्षम होने चाहिए: जब आप /model खोलें तो भ्रमित न हों, किसी कार्य को देखते ही समझ जाएं कि किस मॉडल और कितनी रीजनिंग शक्ति का उपयोग करना है, और इन चार तरीकों से उस पर स्विच कर सकें।

---

अगले अध्याय〔31 उन्नत तकनीकें और गति बढ़ाना〕में, हम "किसे काम पर लगाना है और कितनी शक्ति का उपयोग करना है" से एक कदम आगे बढ़ेंगे: उन उन्नत तकनीकों के बारे में बात करेंगे जो पूरी वर्कफ़्लो को तेज़, अधिक किफायती और कम पुनरावृत्ति (rework) वाली बना सकती हैं। एक छोटी सी बात पर विचार करें—क्या आपने कभी ध्यान दिया है कि कई बार आपको धीमा करने वाला मॉडल की कमजोरी नहीं होती, बल्कि यह होता है कि आपका दिया गया संदर्भ (context) बहुत अव्यवस्थित है, जिससे यह भटक जाता है? यही वह समस्या है जिसे हम अगले अध्याय में हल करेंगे।

---

अनुशंसित पठन

• उन्नत तकनीकें और गति बढ़ाना: आपको धीमा करने वाला मॉडल नहीं, बल्कि आपका खराब संदर्भ है
• इंस्टॉलेशन और लॉगिन (Mac / Windows / Linux)
• सब्सक्रिप्शन और बिलिंग