دليل إعداد API طرف ثالث لـ Codex CLI

هناك أمران في ~/.codex/config.toml: وجّه model_provider من المستوى الأعلى إلى معرّف المزوّد الخاص بك، ثم أضف جدولًا لذلك المعرّف تحت model_providers يتضمن base_url وwire_api وenv_key. تقول مرجعية الإعداد الرسمية إن responses هي القيمة الوحيدة المدعومة لـ wire_api، وإن env_key يحدد اسم متغير البيئة الذي يوفّر مفتاح API؛ ويشير requires_openai_auth إلى مزوّد يستخدم مصادقة OpenAI ويأخذ القيمة false افتراضيًا؛ وعندما تكون true يتجاهل Codex env_key، لذا استخدم أحد الخيارين. تضبط وثائق QCode requires_openai_auth = true مع المفتاح في ~/.codex/auth.json، وتستخدم env_key بدلًا من ذلك فقط في صيغة متغير البيئة.

مع QCode، استخدم https://api.qcode.cc/openai، من دون /v1 ومن دون شرطة مائلة في النهاية. تقول وثائق QCode إن base_url الخاص بـ Codex يجب أن يكون هذا بالضبط، ثم يستخدم Codex المسار /openai/v1/responses. القاعدة العامة في وثائق نقاط النهاية هي حذف الشرطة المائلة في النهاية، لأنها تنتج مسارًا بشرطتين مائلتين و404؛ ويعني 404 عادةً أن بادئة المسار خاطئة. النسخة الاحتياطية لآسيا هي https://asia.qcode.cc/openai، ويخدم us.qcode.cc أمريكا الشمالية وأوروبا.

تحقق من ثلاثة أمور: أن المفتاح يبدأ بـ cr_، وأن المفتاح الموجود في auth.json لا يحتوي على مسافات أو فواصل أسطر دخيلة؛ وفي حالة متغير البيئة، أن يكون اسم المتغير مطابقًا تمامًا لما يذكره env_key في config.toml (وهو QCODE_API_KEY في وثائق QCode)، وأن الجدول لم يعد يحتوي على requires_openai_auth = true (فعند وجوده يتجاهل Codex قيمة env_key)، وأن المتغير مضبوط فعلاً في الصدفة الحالية؛ وأخيرًا حالة المفتاح في لوحة تحكم QCode.

في أغلب الأحيان يكون مفتاح من المستوى الأعلى في المكان الخطأ: تقول الوثائق الرسمية إن model وmodel_provider يجب أن يأتيا قبل أول جدول TOML، لأن المفاتيح التي تأتي بعد ترويسة جدول تنتمي إلى ذلك الجدول. بعد ذلك، يتجاهل ملف .codex/config.toml الخاص بالمشروع كلاً من model_provider وmodel_providers، لذا يجب أن يكون المزوّد في ملف ~/.codex/config.toml على مستوى المستخدم، ولا يمكن أن يكون اسم الجدول openai. كذلك تشير وثائق QCode إلى أنه منذ Codex 0.134.0 لم تعد جداول profiles القديمة في config.toml معتمدة، وأن تشغيل --profile مع بقائها خطأ صارم. بعد بدء التشغيل، يعرض /status النموذج والمزوّد النشطين.

نعم. تشير وثائق QCode التي أُعيد التحقق منها في 2026-11-04 إلى أن Claude Code وCodex يستخدمان مفتاح API نفسه من QCode، وأن تبديل النماذج لا يتطلب أي إعداد إضافي. لكن إرسال نموذج Claude إلى Codex لن ينجح: تقول وثائق QCode إن Codex يستخدم بروتوكول OpenAI Responses، الذي يخدم عائلة GPT فقط، لا نماذج Claude أو GLM وKimi وDeepSeek وQwen؛ ولا تعمل نماذج Claude إلا عبر بروتوكول Anthropic. يوضح مثال الوثائق أن إرسال نموذج Claude إلى /openai/v1/chat/completions يعيد model_not_available_on_endpoint، ويُجرى هذا الفحص قبل المصادقة، لذا فهو يعني أن البروتوكول خاطئ وليس أن المفتاح سيئ. أما Claude فاستخدم معه Claude Code بالمفتاح نفسه.

الفرق هو البروتوكول والنماذج التي يخدمها: يستخدم Codex بروتوكول OpenAI Responses وعائلة GPT فقط، بينما يستخدم Claude Code بروتوكول Anthropic ونماذج Claude. ويبقى الباقي كما هو. اعتبارًا من 2026-10-07، توصي وثائق QCode بـ gpt-6-sol افتراضيًا (1.05M نافذة سياق، للأعمال العامة والمعقدة)؛ وgpt-6.1-sol هو تحديث GPT-6 Sol الصادر في 2026-09-29، وله أيضًا نافذة سياق 1.05M، ووفقًا للوثائق فإن قراءات التخزين المؤقت لديه بسعر أقل، وهو الافتراضي في الكتالوج المضمّن في Codex الرسمي منذ 0.159.1؛ وgpt-5.6-sol ينتمي إلى خط GPT-5.6 الرائد، وgpt-5.6-terra مضبوط للبرمجة، وgpt-6-astra هو أعلى فئة بسعر مرتفع، وgpt-6-luna هو ما تضعه OpenAI للمهام المركزة وعالية الحجم. يمكن استدعاء جميعها على QCode باستثناء gpt-6-luna؛ بدّل بتغيير النموذج أو باستخدام codex --model. لا يدعم QCode حاليًا gpt-6-luna أو gpt-5.6-luna (غير مدعوم على QCode)؛ يرجى استخدام نموذج GPT آخر، مثل gpt-6.1-sol أو gpt-6-sol أو gpt-5.6-terra. وبعد إعادة التحقق في 2026-11-04، أصبح سطر النماذج في صفحة Codex من الوثائق يوصي بـ gpt-6.1-sol نموذجًا افتراضيًا. اعتبارًا من 2026-11-04، يسرد جدول النماذج في صفحة Codex من وثائق QCode كلاً من gpt-6.1-sol وgpt-6.1-terra وgpt-6-sol وgpt-6-astra وgpt-5.6-terra؛ وgpt-6.1-terra هو الفئة المتوسطة من GPT-6.1، للبرمجة اليومية وأعمال الدفعات. gpt-5.6-sol ليس في ذلك الجدول لكنه لا يزال مدرجًا على /models.