“Selected model is at capacity” को Codex सर्वर पर अधिक भार वाली त्रुटि के रूप में वर्गीकृत करता है। हमने OpenAI के सार्वजनिक कोड में इस संदेश का संबंध जाँचा और इस कंप्यूटर के निष्पादन इतिहास में वही पूरा संदेश serverOverloaded के साथ पाया। इसे उपयोग सीमा खत्म होने या PC खराब होने से अलग समझें। लेकिन सार्वजनिक जानकारी और कंप्यूटर के रिकॉर्ड से अधिक भार का मूल कारण तय नहीं हुआ।

Selected model is at capacity. Please try a different model.

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

01 अपना अनुरोध सहेजें और प्रतीक्षा करें

अपना प्रॉम्प्ट और पिछली पूर्णता रिपोर्ट रखें। बार-बार भेजने के बजाय दोबारा कोशिश से पहले रुकें।

02 सेवा की समस्याएँ और उपयोग जाँचें

OpenAI Status और अपना उपयोग अलग-अलग जाँचें। उपयोग सीमा बची होने पर भी सेवा में समस्या आ सकती है।

03 काम जरूरी हो तो विकल्प सोचें

खुद कोई अन्य उपलब्ध मॉडल चुनें। कई मॉडलों को प्रभावित करने वाली समस्या में बदलाव मदद नहीं भी कर सकता।

लेख में सुझाया गया क्रम। मॉडल बदलना एक विकल्प है, निश्चित समाधान नहीं।

विषय सूची

क्या हो रहा है? आधिकारिक घटना रिकॉर्ड क्या बताते हैं

संदेश कहता है कि चुना गया मॉडल अपनी क्षमता तक पहुँच गया है और कोई अन्य मॉडल आजमाने को कहता है। यहाँ “capacity” को PC की मेमोरी या डिस्क की जगह समझने का आधार नहीं है। OpenAI के आधिकारिक स्टेटस पेज पर इस संदेश वाली सेवा समस्याओं के रिकॉर्ड हैं।

16 जून 2026: Codex में क्षमता संबंधी त्रुटियाँ

OpenAI Status के अनुसार Desktop, Web, API, CLI और VS Code एक्सटेंशन प्रभावित थे। रिकॉर्ड में राहत के उपाय लागू होने और समस्या सुलझने की सूचना है (आधिकारिक घटना रिकॉर्ड)।

9 जुलाई 2026: कई मॉडलों में वही संदेश

OpenAI Status की रिपोर्ट में लेख की शुरुआत वाला पूरा त्रुटि संदेश है। उसमें स्पष्ट रूप से कई मॉडल प्रभावित होने और बाद में सेवा बहाल होने की बात है (आधिकारिक घटना रिकॉर्ड)।

इन दो रिकॉर्डों से पता चलता है कि वही संदेश सेवा समस्याओं के दौरान आ सकता है और मॉडल बदलना हमेशा मदद नहीं करता। प्रकाशित घटनाओं की संख्या से त्रुटि की आवृत्ति तय नहीं होती, न यह सिद्ध होता है कि आपके मामले का कारण किसी पिछली घटना जैसा था। तारीखें आधिकारिक पेजों के अनुसार हैं; हमने उनके समय को जापान मानक समय में नहीं बदला है।

किसी भी रिकॉर्ड में किसी खास हार्डवेयर की कमी या अकाउंट बदलने के बग जैसा मूल कारण प्रकाशित नहीं है। “पर्याप्त GPU नहीं हैं” या “Pro प्रमाणीकरण खराब है” जैसे दावे जाँची गई जानकारी से आगे जाते हैं। हमने 1 अक्टूबर 2026 को मूल आधिकारिक स्रोत जाँचे और स्थापित तथ्यों को अपनी सिफारिशों से अलग रखा है।

उपयोग सीमा, 401 और thread not found से अंतर

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

संदेश या स्थितिमुख्य जाँचइसका अर्थ कैसे समझें
Selected model is at capacityआधिकारिक घटना रिपोर्ट, घटना का समय और चुना गया मॉडलकेवल इस संदेश का अर्थ उपयोग सीमा खत्म होना नहीं है।
उपयोग सीमा या रीसेट की प्रतीक्षा का नोटिसउपयोग स्क्रीन पर बची सीमा और रीसेट का समयप्रतीक्षा या आगे काम करने का तरीका तय करने से पहले बची सीमा जाँचें।
401 Unauthorized
Incorrect API key provided		लॉगिन का तरीका और सक्रिय अकाउंटप्रमाणीकरण समस्या का उपाय क्षमता त्रुटि से अलग है।
thread not foundप्रभावित चैट खुलती है या फिर शुरू होती है या नहींइसका अर्थ चैट नहीं मिली है; इसे मॉडल पर भीड़ से न जोड़ें।

उपयोग की अलग स्क्रीन पर बची सीमा जाँचें

OpenAI की कीमत और उपयोग गाइड वर्तमान सीमाएँ जाँचने के लिए उपयोग डैशबोर्ड बताती है। Codex CLI सत्र में /status भी इस्तेमाल कर सकते हैं। त्रुटि के तुरंत बाद जाँचने से उस समय बची सीमा और त्रुटि की तुलना आसान होती है।

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

401 आने पर पहले लॉगिन का तरीका जाँचें

Codex प्रमाणीकरण गाइड ChatGPT से लॉगिन और API कुंजी से लॉगिन में अंतर बताती है। डेस्कटॉप ऐप का प्रोफाइल मेनू सक्रिय अकाउंट या API कुंजी की स्थिति दिखाता है। CLI में codex login status इस्तेमाल करें।

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

यदि संदेश thread not found है, तो Codex की “thread not found” त्रुटि की हमारी जाँच और समस्या समाधान गाइड देखें। उसी PC पर पहले आए प्रमाणीकरण या चैट के त्रुटि संदेश वर्तमान क्षमता त्रुटि से कारण संबंध सिद्ध नहीं करते।

API के HTTP 503 और ऐप के संदेश में अंतर रखें

OpenAI API त्रुटि कोड गाइड HTTP 503, service_unavailable_error और server_is_overloaded को मॉडल पर अस्थायी अधिक भार के संकेत बताती है। HTTP 429 में अनुरोधों की दर या उपयोग सीमा की त्रुटियाँ आती हैं, जबकि HTTP 401 प्रमाणीकरण से संबंधित है।

ऐप के शब्दों से HTTP कोड का अनुमान न लगाएँ
API दस्तावेज त्रुटियों के प्रकार अलग करने में मदद करते हैं, लेकिन यह स्थापित नहीं करते कि Codex का “at capacity” संदेश हमेशा HTTP 503 है। इस कंप्यूटर की जाँच में भी प्रभावित अनुरोधों का HTTP कोड नहीं मिला।

काम फिर शुरू करने के चरण

आगे की सिफारिशें आधिकारिक घटना रिकॉर्ड, उपयोग गाइड और सामान्य समस्या समाधान दस्तावेजों पर आधारित हैं। इन्हें इस खास त्रुटि का निश्चित समाधान बताकर प्रकाशित नहीं किया गया है।

1. अपना प्रॉम्प्ट और अंतिम पूरा काम सहेजें

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

केवल त्रुटि संदेश यह साबित नहीं करता कि कोई फाइल नहीं बदली गई या कोई कमांड नहीं चली। Git से विकास करते समय वही बदलाव दोबारा माँगने से पहले अंतर देखें या git status चलाएँ। प्रकाशन, संदेश भेजने या खरीद से जुड़े काम में परिणाम जाँचे बिना निर्देश न दोहराएँ।

2. थोड़ी प्रतीक्षा करें और आधिकारिक स्टेटस पेज जाँचें

OpenAI Status खोलें और Codex या मॉडल चयन को प्रभावित करने वाली समस्याएँ जाँचें। केवल वर्तमान स्थिति देखने के बजाय त्रुटि के समय की घटना की अवधि से तुलना करें। उसी नाम की पिछली घटना का अर्थ यह नहीं कि वह अभी भी जारी है।

API पर अधिक भार के लिए आधिकारिक निर्देश कहते हैं कि Retry-After हो तो कम से कम बताई गई अवधि तक रुकें; न हो तो कोशिशों के बीच अंतर बढ़ाएँ। ऐप में प्रतीक्षा अवधि न दिखने पर कितने निश्चित सेकंड रुकना चाहिए, इसकी पुष्टि नहीं हुई। हमारी सलाह है कि तेजी से बार-बार अनुरोध भेजने के बजाय थोड़ी प्रतीक्षा करके दोबारा कोशिश करें। सूचीबद्ध घटना के दौरान आधिकारिक बहाली अपडेट देखें।

स्टेटस पेज समेकित जानकारी दिखाता है। वह किसी विशेष अकाउंट या मॉडल की स्थिति को पूरी तरह नहीं दिखा सकता। घटना सूची में न होने से PC खराब होना सिद्ध नहीं होता।

3. उपयोग जाँचें और काम जरूरी हो तो अन्य मॉडल पर विचार करें

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

गुणवत्ता और निरंतरता को प्राथमिकता दें

उसी मॉडल से काम जारी रखना हो तो बहाली की प्रतीक्षा करें। इस समय में जरूरतें, बदलाव और बाकी जाँचें देखें।

अभी आगे बढ़ने को प्राथमिकता दें

अन्य उपलब्ध मॉडल चुनें और छोटे काम से जारी रखें। कई मॉडलों की समस्या बदलाव के बाद भी काम रोक सकती है।

आधिकारिक मॉडल चयन गाइड के अनुसार डेस्कटॉप ऐप में मॉडल और तर्क प्रयास के विकल्प प्रॉम्प्ट फील्ड के नीचे हैं। इंटरैक्टिव CLI में /model इस्तेमाल करें। उपलब्ध मॉडल अकाउंट, क्लाइंट और अन्य कारकों से बदलते हैं, इसलिए इंटरफेस में न दिखने वाले मॉडल को उपलब्ध न मानें।

मॉडल बदलने से उत्तरों का स्वरूप और उपयोग की खपत बदल सकती है। क्षमता त्रुटि से बचने के लिए हमेशा सबसे ऊँची श्रेणी का मॉडल चुनने का आधार नहीं है। जटिल कार्यान्वयन या डिजाइन सौंपते समय नए आउटपुट को बदलावों और टेस्ट से जाँचें। हमारी GPT Sol पीढ़ियों की तुलना और चयन गाइड भी संदर्भ देती है।

4. ऐप खुद अटका हो तो उसकी प्रतिक्रिया अलग से जाँचें

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

टर्मिनल अटका रहे तो निर्देश ऐप फिर शुरू करने से पहले सक्रिय चैट पूरी होने की प्रतीक्षा करने को कहते हैं। यह सामान्य प्रतिक्रिया न मिलने की स्थिति का उपाय है; इसमें यह नहीं कहा गया कि रीस्टार्ट सर्वर की क्षमता की कमी दूर करता है। पहले अन्य चलती चैट की स्थिति जाँचें।

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

दोबारा होने पर क्या रिकॉर्ड करें

त्रुटि दोहराए तो आगे की जाँच के लिए प्रमाण रखें। बार-बार सेटिंग बदलने से पहले रिकॉर्ड करने से विफलता की परिस्थितियाँ स्पष्ट रहती हैं।

सहायता अनुरोध और बार-बार आने वाली त्रुटियों की सूची

  • त्रुटि की तारीख, समय और समय क्षेत्र
  • Codex कहाँ इस्तेमाल किया: ऐप, CLI या IDE, और उसका संस्करण
  • चुना गया मॉडल, तर्क प्रयास और गति सेटिंग
  • पूरा त्रुटि संदेश और उससे ठीक पहले की कार्रवाई
  • उस समय बची सीमा, रीसेट समय और आधिकारिक घटना जानकारी
  • प्रतीक्षा और दोबारा कोशिश का परिणाम, और क्या अन्य मॉडल पर भी संदेश आया

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

आधिकारिक गाइड संदेश फील्ड में / लिखकर फीडबैक भेजने का तरीका बताती है। मौजूदा चैट से भेजते समय बातचीत साझा करनी है या नहीं, यह चुन सकते हैं। भेजे जाने वाले लॉग या स्क्रीनशॉट से API कुंजी, ईमेल पता, निजी बातचीत और कंपनी की आंतरिक जानकारी हटा दें। कुंजी के मान या प्रमाणीकरण फाइलें खुद प्रकाशित करने की जरूरत नहीं है।

तारीख, मॉडल, सटीक संदेश और स्क्रीन पर बची सीमा वाला रिपोर्ट केवल “बार-बार खराब हो रहा है” से अधिक उपयोगी है। HTTP कोड या अनुरोध ID मिले तो सहायता की जाँच में मदद कर सकते हैं, लेकिन अनुमान से जानकारी न भरें।

इस कंप्यूटर पर क्या मिला और क्या अज्ञात है

एक उपयोगकर्ता ने स्क्रीनशॉट के साथ बार-बार त्रुटि की सूचना दी, जिसके बाद AI Arte ने 1 अक्टूबर 2026 को इस कंप्यूटर पर Codex से उपयोग और स्थानीय लॉग की केवल पढ़कर जाँच कराई। Windows ऐप पैकेज संस्करण 26.928.3736.0 था। त्रुटि के समय भी वही संस्करण था, इसकी पुष्टि नहीं हुई।

पुष्टि हुई

निष्पादन इतिहास में वही पूरा संदेश serverOverloaded के साथ था। सार्वजनिक कोड भी इसे सर्वर पर अधिक भार के रूप में वर्गीकृत करता है।

स्थापित नहीं हुआ

अधिक भार का कारण, उस समय बची सीमा, HTTP कोड और विफल अनुरोध में इस्तेमाल वास्तविक मॉडल।

पहली खोज में नियमित लॉग डेटाबेस के 32,737 रिकॉर्ड, 15 डेस्कटॉप लॉग फाइलों और 143 अपडेट हुई सत्र रिकॉर्ड फाइलों में त्रुटि नहीं मिली। पाठक के सवाल के बाद हमने अन्य संग्रह स्थान जाँचे और अलग निष्पादन इतिहास डेटाबेस में विफलता रिकॉर्ड पाए। पहली खोज का दायरा पर्याप्त नहीं था।

अगली जाँच के समय निष्पादन इतिहास की 6,781 बारी में 35 विफलताएँ थीं। पूरी रिकॉर्ड अवधि में 13 में वही पूरा त्रुटि संदेश और codexErrorInfo: serverOverloaded था। इनमें से 12 पाँच चैट में 30 सितंबर 2026 को 22:10:01 से 1 अक्टूबर को 00:24:55 (JST) के बीच हुईं। जिस चैट में उपयोगकर्ता ने त्रुटि स्क्रीनशॉट लगाए थे, उसमें भी 30 सितंबर को 22:15:06, 22:57:58, 23:12:31 और 23:24:38 पर चार विफलताएँ थीं, जिनके संदेश और वर्गीकरण मेल खाते थे। ये विफल बारी के रिकॉर्ड किए गए समाप्ति समय हैं, स्क्रीनशॉट के समय नहीं। ये इसी कंप्यूटर के रिकॉर्ड हैं, सभी उपयोगकर्ताओं की त्रुटि दर नहीं।

ऐप के साथ शामिल Codex CLI संस्करण 0.159.2 था। उसी सार्वजनिक टैग की त्रुटि परिभाषाओं में पूरा संदेश ServerOverloaded से जुड़ा है, जिसे उपयोग सीमा खत्म होने से अलग रखा गया है। स्ट्रीम प्रसंस्करण कोड server_is_overloaded को अधिक भार की त्रुटि में बदलता है और प्रदर्शन रूपांतरण कोड उसे लेख की शुरुआत वाले पूरे संदेश से जोड़ता है। उसी त्रुटि कोड वाली HTTP 503 प्रतिक्रियाएँ बदलने का रास्ता भी है, लेकिन त्रुटियाँ स्ट्रीम के भीतर भी आ सकती हैं। इसलिए प्रदर्शित संदेश प्रतिक्रिया का HTTP 503 होना सिद्ध नहीं करता।

हमने यह स्थापित किया कि विफलताएँ सर्वर पर अधिक भार के रूप में वर्गीकृत और सहेजी गई थीं। रिकॉर्ड यह नहीं दिखाते कि वास्तविक GPU की कमी, अनुरोध रूटिंग या क्षमता नियंत्रण की समस्या थी। चार विफलताओं के अतिरिक्त विवरण खाली थे और HTTP कोड रिकॉर्ड नहीं था। पहली जाँच के दौरान साप्ताहिक सीमा का 31% बचा था और सामान्य उपयोग की अनुमति थी। यह त्रुटियों के समय की सीमा नहीं थी, और विफल अनुरोधों का वास्तविक मॉडल भी स्थापित नहीं हुआ।

प्रमाणीकरण त्रुटियों के लिए 25 सितंबर की अलग घटना की आधिकारिक मूल कारण रिपोर्ट बताती है कि आंतरिक सेवा क्रेडेंशियल को गलती से पहचानकर अमान्य करने से ChatGPT लॉगिन वाले Codex में 401 और 502 त्रुटियाँ हुईं। इससे यहाँ जाँची गई अधिक भार वाली त्रुटियों का कारण तय नहीं होता। आधिकारिक रूप से समझाई गई आंतरिक प्रमाणीकरण घटना को वर्तमान अधिक भार की त्रुटियों से न मिलाएँ।

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

सारांश: उपाय चुनने से पहले त्रुटि पहचानें

“Selected model is at capacity” आए तो प्रॉम्प्ट सहेजें, थोड़ी प्रतीक्षा करें और घटना रिपोर्ट व उपयोग जाँचें। जरूरी काम के लिए अन्य उपलब्ध मॉडल सोच सकते हैं, लेकिन कुछ घटनाएँ कई मॉडल प्रभावित करती हैं। केवल क्षमता त्रुटि अधिक पैसे खर्च करने, सशुल्क रीसेट खरीदने या क्रेडेंशियल हटाने का आधार नहीं है।

401 के लिए प्रमाणीकरण, thread not found के लिए चैट की स्थिति और सीमा नोटिस के लिए उपयोग स्थिति जाँचें। त्रुटि दोहराने पर समय, पूरा संदेश, मॉडल और बची सीमा रिकॉर्ड करना, कारण जाने बिना सेटिंग बदलने से अगली जाँच में अधिक मदद करता है।

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

क्या Pro सदस्यता में भी ऐसा होता है?

लेख के उपयोगकर्ता ने Pro सदस्यता में वही संदेश आने की सूचना दी। लेकिन एक रिपोर्ट से योजना के हिसाब से घटना दर तय नहीं होती। आधिकारिक घटना रिकॉर्ड Pro को छूट प्राप्त नहीं बताते। बची सदस्यता सीमा को उस समय मॉडल के काम स्वीकार कर पाने से अलग जाँचें।

क्या अतिरिक्त क्रेडिट या सशुल्क रीसेट इसे ठीक करते हैं?

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

मॉडल बदलने के बाद भी क्यों होता है?

आधिकारिक घटना रिकॉर्ड वही संदेश कई मॉडलों में आने का वर्णन करते हैं। दूसरे मॉडल में दिखना अपने आप PC या अकाउंट की खराबी सिद्ध नहीं करता। घटना रिपोर्ट और बची सीमा जाँचें तथा कोशिशों के परिणाम रिकॉर्ड करें। सार्वजनिक दस्तावेज कोई ऐसा मॉडल नहीं स्थापित करते जो त्रुटि से बचने की गारंटी दे।

क्या ऐप फिर शुरू करूँ या नई चैट खोलूँ?

हम यह स्थापित नहीं कर पाए कि कोई भी जरूरी है। ये उपाय प्रतिक्रिया न देने वाले ऐप या टर्मिनल की जाँच में मदद कर सकते हैं, लेकिन सेवा की क्षमता की समस्या हल होने की गारंटी नहीं देते। निर्णय से पहले अन्य चल रहे काम देखें और प्रॉम्प्ट, बदलाव तथा बाकी कार्य सहेजें।