Selected model is at capacity: معالجة Codex وحدود الاستخدام

رسالة «Selected model is at capacity» خطأ يصنّفه Codex ضمن الحمل الزائد على الخادم. تحققنا من ارتباط الرسالة بشيفرة OpenAI المنشورة، ووجدنا الرسالة الكاملة نفسها مع serverOverloaded في سجل التنفيذ على هذا الكمبيوتر. ينبغي فصلها عن نفاد حصة الاستخدام أو تعطل الكمبيوتر. لكن المعلومات العامة وسجلات الجهاز لم تحدد سبب الحمل الزائد.

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

ماذا يحدث؟ وما الذي توضحه سجلات الأعطال الرسمية؟

تقول الرسالة إن النموذج المختار بلغ طاقته الاستيعابية، وتطلب تجربة نموذج آخر. لا يوجد ما يبرر تفسير «capacity» هنا بأنها ذاكرة الكمبيوتر أو مساحة القرص. تسجل صفحة حالة OpenAI الرسمية أعطالًا في الخدمة ظهرت خلالها هذه الرسالة.

يثبت هذان السجلان أن الرسالة نفسها قد تظهر أثناء أعطال الخدمة، وأن تبديل النموذج لا يفيد دائمًا. لا يحدد عدد الأعطال المنشورة معدل تكرار الخطأ، ولا يثبت أن خطأك ناتج عن سبب عطل سابق. التواريخ تتبع الصفحات الرسمية؛ ولم نحوّل أوقاتها إلى توقيت اليابان القياسي.

لا ينشر أي من السجلين سببًا جذريًا، مثل نقص عتاد بعينه أو خلل تبديل الحساب. عبارات مثل «وحدات GPU غير كافية» أو «مصادقة Pro معطلة» تتجاوز ما تحققنا منه. راجعنا المصادر الرسمية الأصلية في 1 أكتوبر 2026، ونفصل الحقائق المثبتة عن توصياتنا.

الفرق عن حدود الاستخدام و401 وthread not found

قد تبدو هذه المشكلات كلها توقفًا للعمل، لكنها تتطلب فحوصًا مختلفة. عند خطأ السعة، ابدأ بالتحقق من الرسالة الكاملة على الشاشة وحالة استخدامك معًا. يمكن أن تحدث أنواع مختلفة من المشكلات في الحساب نفسه.

تحقق من الحصة المتبقية في شاشة الاستخدام المخصصة

يوجّه دليل OpenAI للأسعار والاستخدام المستخدمين إلى لوحة الاستخدام للتحقق من الحدود الحالية. أثناء جلسة Codex CLI يمكنك أيضًا استخدام /status. التحقق مباشرة بعد الخطأ يسهل مقارنة الرسالة بالحصة المتبقية في تلك اللحظة.

يوضح الدليل الرسمي أيضًا أن العمل الجاري قد يستمر ضمن قيود الاستخدام العادل، حتى إذا بُلغ حد الاستخدام أثناء المعالجة. لذلك، ظهور خطأ ثم تقرير إنجاز لا يثبت وحده ما إذا كان الحد قد بُلغ. وبالعكس، قد يقع عطل في الخدمة مع بقاء حصة كبيرة. راجع مقارنتنا لخطط ChatGPT Pro بشأن الحصص المشمولة والأرصدة الإضافية.

عند خطأ 401، تحقق أولًا من طريقة تسجيل الدخول

يميز دليل مصادقة Codex بين تسجيل الدخول بحساب ChatGPT وتسجيل الدخول بمفتاح API. تعرض قائمة الملف الشخصي في تطبيق سطح المكتب الحساب النشط أو حالة مفتاح API. في CLI استخدم codex login status.

حتى إذا ظهرت «Incorrect API key» وأنت مسجل بحساب ChatGPT، فإن الشاشة وحدها لا تثبت أنك أعددت مفتاحًا خاطئًا. تحديد بيانات الاعتماد المرفوضة يحتاج إلى تحقيق إضافي. خطأ السعة ليس سببًا لتسجيل الخروج فورًا أو حذف ملفات المصادقة. استخدام مفتاح API يترتب عليه احتساب أسعار API المعتادة بصورة منفصلة عن اشتراك ChatGPT.

إذا كانت الرسالة thread not found، فراجع تحقيقنا ودليل معالجة خطأ «thread not found» في Codex. أخطاء المصادقة أو المحادثة السابقة على الكمبيوتر نفسه لا تثبت ارتباطًا سببيًا بخطأ السعة الحالي.

ميّز أخطاء HTTP 503 في API عن رسالة التطبيق

يوضح دليل رموز أخطاء OpenAI API أن HTTP 503 وservice_unavailable_error وserver_is_overloaded تدل على حمل زائد مؤقت على النموذج. يشمل HTTP 429 أخطاء معدل الطلبات أو حدود الاستخدام، بينما يتعلق HTTP 401 بالمصادقة.

خطوات استئناف العمل

تستند التوصيات التالية إلى سجلات الأعطال الرسمية وأدلة الاستخدام ووثائق معالجة المشكلات العامة. وليست منشورة بوصفها إصلاحًا مضمونًا لهذا الخطأ تحديدًا.

1. احفظ طلبك وآخر عمل مكتمل

إذا بقي الطلب غير المرسل ظاهرًا، فانسخه واحتفظ بآخر تقرير إنجاز أو بحالة الملفات المعدلة. قبل إغلاق المحادثة أو استبدالها، سجل المطلوب وما اكتمل منه. هذا يسهل الاستئناف.

رسالة الخطأ وحدها لا تثبت عدم تعديل ملفات أو تنفيذ أوامر. في التطوير باستخدام Git، راجع الفرق أو نفّذ git status قبل طلب التغيير نفسه مجددًا. وفي الأعمال التي تشمل نشرًا أو إرسال رسائل أو مشتريات، تحقق من النتيجة قبل تكرار التعليمات.

2. انتظر قليلًا وراجع صفحة الحالة الرسمية

افتح OpenAI Status وتحقق من الأعطال المؤثرة في Codex أو اختيار النماذج. قارن وقت خطأك بفترة العطل، بدلًا من الاكتفاء بحالته الحالية. وجود عطل سابق بالاسم نفسه لا يعني أنه ما زال قائمًا.

عند الحمل الزائد في API، توصي الإرشادات الرسمية بانتظار المدة المحددة في Retry-After على الأقل إن وُجدت، أو بزيادة الفاصل بين المحاولات إن لم توجد. لم نتحقق من عدد ثوانٍ ثابت يجب على مستخدمي التطبيق انتظاره عندما لا تُعرض مدة. توصيتنا هي الانتظار قليلًا قبل المحاولة بدلًا من إرسال طلبات متتابعة بسرعة. أثناء عطل منشور، تابع تحديثات التعافي الرسمية.

تعرض صفحة الحالة معلومات مجمعة. وقد لا تعكس بالكامل وضع حساب أو نموذج بعينه. عدم إدراج عطل لا يثبت أن الكمبيوتر معطل.

3. تحقق من الاستخدام وفكّر في نموذج آخر إذا كان العمل عاجلًا

تحقق من الحصة المتبقية وموعد إعادة التعيين. إذا أُعلن صراحة بلوغ حد الاستخدام، فاتبع الإشعار عند اتخاذ القرار. لا تعتبر شراء أرصدة إضافية أو إعادة تعيين مدفوعة وسيلة تعافٍ إذا كانت رسالة السعة هي الوحيدة. استعادة حصتك وقدرة النموذج على قبول الطلبات مسألتان منفصلتان.

يوضح دليل اختيار النموذج الرسمي أن عناصر اختيار النموذج وجهد الاستدلال في تطبيق سطح المكتب تقع أسفل حقل الطلب. في CLI التفاعلي استخدم /model. تختلف النماذج المتاحة بحسب الحساب والعميل وعوامل أخرى؛ فلا تفترض توفر نموذج لا يظهر في واجهتك.

قد يغير تبديل النموذج طبيعة الردود واستهلاك الحصة. لا يوجد ما يبرر اختيار أعلى النماذج فئة دائمًا لتجنب أخطاء السعة. عند تسليم أعمال تنفيذ أو تصميم معقدة، راجع المخرجات الجديدة بالفروق والاختبارات. ويوفر دليلنا لمقارنة أجيال GPT Sol واختيارها سياقًا إضافيًا.

4. افحص استجابة التطبيق بشكل منفصل إذا كان التطبيق نفسه متجمدًا

ميّز بين خطأ السعة وعدم استجابة الإدخال أو الطرفية أو واجهة التطبيق. للمحادثات التي تبدو عالقة، توصي إرشادات معالجة المشكلات الرسمية بفحص الموافقات المعلقة، واختبار الطرفية بأمر بسيط، وتجربة طلب صغير في محادثة جديدة.

إذا بقيت الطرفية عالقة، توصي الإرشادات بانتظار اكتمال المحادثات النشطة قبل إعادة تشغيل التطبيق. يعالج ذلك حالة عدم استجابة عامة؛ ولا يقول إن إعادة التشغيل تحل نقص الطاقة الاستيعابية على الخادم. تحقق أولًا من حالة المحادثات الأخرى التي ما زالت تعمل.

إذا استأنفت في محادثة جديدة، قدّم باختصار الهدف ومجلد العمل والتغييرات المكتملة والمهام المتبقية. لا ترسل «تابع» فقط بافتراض توفر المحادثة السابقة كاملة. تستخدم المحادثة الجديدة الخدمة نفسها، لذا لا تضمن تجنب خطأ السعة.

ما الذي تسجله إذا تكرر الخطأ؟

إذا تكرر الخطأ، احتفظ بأدلة تساعد التحقيق لاحقًا. تسجيلها قبل تغيير الإعدادات مرارًا يوضح ظروف الإخفاق.

بحسب السجلات المتاحة، قد لا تتمكن من تأكيد أن النموذج المختار في الإعدادات هو الذي استُخدم فعلًا في الطلب الفاشل. إذا سجلت الإعداد الظاهر فقط، فلا تصف إلا هذا الدليل. كذلك، لا يثبت التعافي مباشرة بعد التبديل أن التبديل أصلح المشكلة؛ فقد تكون الخدمة تعافت في الوقت نفسه.

يوضح الدليل الرسمي إرسال الملاحظات بإدخال / في حقل الرسالة. عند الإرسال من محادثة قائمة، يمكنك اختيار مشاركة المحادثة أو عدمها. احذف مفاتيح API وعناوين البريد والمحادثات الخاصة ومعلومات الشركة الداخلية من السجلات أو الصور المرسلة. لا حاجة إلى نشر قيم المفاتيح أو ملفات المصادقة نفسها.

تقرير يتضمن التاريخ والنموذج والرسالة الدقيقة والحصة الظاهرة أكثر فائدة من عبارة «يتعطل باستمرار». قد يساعد رمز HTTP أو معرّف الطلب، إن توفر، الدعم في التحقيق، لكن لا تملأ الفراغات بالتخمين.

ما وجدناه على هذا الكمبيوتر وما بقي مجهولًا

بعد أن أبلغ مستخدم عن تكرر المشكلة مع صور للشاشة، كلّفت AI Arte Codex على هذا الكمبيوتر بإجراء تحقيق للقراءة فقط في الاستخدام والسجلات المحلية يوم 1 أكتوبر 2026. كان إصدار حزمة تطبيق Windows هو 26.928.3736.0. لم نتحقق من تثبيت الإصدار نفسه وقت الأخطاء.

لم يعثر البحث الأول على الخطأ في 32,737 سجلًا بقاعدة السجلات المعتادة، ولا في 15 ملفًا لسجلات سطح المكتب، ولا في 143 ملفًا محدثًا لسجلات الجلسات. بعدما تساءل قارئ عن النتائج، فحصنا مواقع تخزين أخرى ووجدنا سجلات الإخفاق في قاعدة منفصلة لسجل التنفيذ. كان نطاق البحث الأول غير كافٍ.

وقت التحقيق اللاحق، كانت 35 من أصل 6,781 دورة في سجل التنفيذ إخفاقات. وخلال كامل الفترة المسجلة، احتوت 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 سبتمبر أن اكتشاف بيانات اعتماد داخلية للخدمة وإبطالها خطأً سبب أخطاء 401 و502 في Codex عند تسجيل الدخول عبر ChatGPT. لا يحدد ذلك سبب أخطاء الحمل الزائد التي فحصناها هنا. لا تخلط بين عطل مصادقة داخلي فسّرته الجهة رسميًا وأخطاء الحمل الزائد الحالية.

لم يغير التحقيق النماذج أو الاشتراكات، ولم يستخدم إعادة تعيين مدفوعة أو يحذف بيانات الاعتماد. ولم نرسل عمدًا طلبات متكررة بسرعة لإعادة إنتاج المشكلة، لذا لا توجد لدينا مقارنة تجريبية للإجراءات التي تعيد الخدمة. نفصل أمثلة الأعطال المثبتة رسميًا عن ملاحظات هذا الكمبيوتر الواحد.

الخلاصة: حدد الخطأ قبل اختيار الإجراء

إذا ظهرت «Selected model is at capacity»، فاحفظ طلبك وانتظر قليلًا وتحقق من تقارير الأعطال والاستخدام. للعمل العاجل يمكنك التفكير في نموذج آخر متاح، لكن بعض الأعطال تؤثر في نماذج متعددة. خطأ السعة وحده لا يبرر إنفاق المزيد أو شراء إعادة تعيين مدفوعة أو حذف بيانات الاعتماد.

تحقق من المصادقة عند 401، وحالة المحادثة عند thread not found، وحالة الاستخدام عند إشعار الحد. تسجيل الوقت والرسالة الكاملة والنموذج والحصة المتبقية عند تكرر الخطأ يفيد التحقيق التالي أكثر من تغيير الإعدادات دون معرفة السبب.

الأسئلة الشائعة

هل يحدث هذا مع اشتراك Pro؟

أبلغ مستخدم هذا المقال عن الرسالة نفسها مع اشتراك Pro. لكن بلاغًا واحدًا لا يحدد معدلات الأعطال بحسب الخطة. لا تقول السجلات الرسمية إن Pro مستثنى. تحقق من الحصة المتبقية في الاشتراك بصورة منفصلة عن قدرة النموذج على قبول العمل في تلك اللحظة.

هل تصلحه أرصدة إضافية أو إعادة تعيين مدفوعة؟

لم نجد دليلًا رسميًا على أن هذه الإجراءات تحل خطأ السعة هذا. تتعلق الأرصدة الإضافية وما شابهها بحصة استخدامك. تحقق أولًا من بلوغ الحد فعلًا، ولا تخلط بين استعادة الحصة والتعافي من خطأ السعة.

لماذا يستمر بعد تبديل النموذج؟

تصف سجلات الأعطال الرسمية الرسالة نفسها مع نماذج متعددة. ظهورها مع نموذج آخر لا يثبت وحده تعطل الكمبيوتر أو الحساب. تحقق من تقارير الأعطال والحصة المتبقية، وسجل نتائج المحاولات. لا تثبت الوثائق العامة وجود نموذج يضمن تجنب الخطأ.

هل أعيد تشغيل التطبيق أم أفتح محادثة جديدة؟

لم نثبت ضرورة أي منهما. قد تساعد هذه الإجراءات في فحص عدم استجابة التطبيق أو الطرفية، لكنها لا تضمن حل مشكلة سعة الخدمة. تحقق من الأعمال الأخرى الجارية، واحفظ طلبك والتغييرات والمهام المتبقية قبل اتخاذ القرار.