كثير من الأشخاص الذين يستخدمون Codex فعليًا في أعمال جادة يواجهون مشكلة حقيقية جدًا: الحصة ببساطة ليست كافية. إذا كنت تستخدمه من حين لآخر فقط للتجربة، فقد تكون خطة Plus كافية. لكن بمجرد أن تبدأ باستخدام Codex لكتابة الأكواد، وتصحيح الأخطاء، وتقسيم المهام، وإجراء الأبحاث، أو إدارة المشاريع — ويزداد استخدامك — يبدأ السؤال يراودك: هل هناك طريقة لمواصلة استخدام Codex بنفس الطريقة، ولكن مع إنفاق أقل قليلاً بشكل عام؟
لهذا السبب بالتحديد قمت مؤخرًا بمشاركة مشروع Codex Third-Party Workers كمصدر مفتوح. فكرتي بسيطة جدًا: لا تشغّل كل مهمة بنفس التكلفة.
قبل هذا، كان Codex يتعامل مع كل شيء — كبيرًا كان أو صغيرًا، مهما كان نوعه — عبر نفس المسار. الآن أضفت طبقة جدولة مهام إلى سير عمل Codex. يبقى Codex هو الوكيل الرئيسي: فهو يفهم المهمة، ويقسمها، ويحكم على ما يجب فعله، ويراجع، ويقوم بالموافقة النهائية. لكن بعض المهام الفرعية المناسبة للتفويض يمكن إرسالها إلى واجهات برمجة تطبيقات نماذج خارجية أرخص. وبمجرد اكتمالها، تعود النتائج إلى Codex. باختصار: يعطي المستخدم مهمة ← يفهمها Codex ويقسمها ← تُرسل المهام الفرعية المناسبة إلى Workers الخارجية ← تُنجز Workers المهام ← تعود النتائج إلى Codex ← يتحقق Codex منها ويُنهي الأمر.
إذن هذا المشروع لا يتعلق باستبدال Codex. بل يتعلق بحل سؤال عملي أكثر: كيف تجعل حصة Plus الخاصة بك تدوم لفترة أطول؟
بالنسبة لمستخدمي Plus، أعتقد أن هذا مهم حقًا. إذا كنت تشغّل Codex مرة كل فترة، فلست بحاجة للتفكير كثيرًا في التكاليف — النسخة المجانية كافية تمامًا. لكن بمجرد أن يصبح Codex أداة عملك اليومية، فإن كيفية تخصيص حصتك، وأي المهام تبقى مع Codex، وأيها يمكن أن تذهب إلى نماذج أرخص — يصبح هذا بحد ذاته مشكلة تستحق التحسين.
هدفي هو: التأكد من إنفاق حصة Plus الخاصة بك على الأشياء التي تريد Codex من أجلها حقًا. كل شيء آخر يمكن تفويضه يذهب إلى واجهات برمجة تطبيقات مزودين أقل تكلفة.
الأمر لا يتعلق بالحصول على Codex مجانًا — فواجهات برمجة التطبيقات الخارجية لا تزال تكلف مالًا. ما تحسّنه حقًا هو متوسط التكلفة عبر سير عمل الذكاء الاصطناعي بأكمله. بالنسبة لنفس المشروع، تشغيل كل شيء عبر مسار واحد مكلف مقابل تقسيم الأشياء بناءً على المهمة — يمكن أن تبدو الفاتورة النهائية مختلفة تمامًا.
لهذا أعود دائمًا إلى: لا تشغّل كل مهمة بنفس التكلفة.
حاليًا، يضم Codex Third-Party Workers بالفعل عدة حزم مزودين خارجيين: DeepSeek V4 Flash وMiniMax-M3 وAlibaba Cloud Bailian Qwen3.7-Max.
تم التحقق من MiniMax-M3 وQwen3.7-Max بالفعل عبر استدعاءات API حقيقية، وسطر الأوامر، وتشغيلات الوكلاء الفرعيين في Codex Desktop. تم دمج DeepSeek V4 Flash واجتاز اختبارات العزل، على الرغم من أننا ما زلنا نجري التحقق الكامل من وقت التشغيل على المثبّت العام.
لتجنب الفخ الكلاسيكي — توفير بضعة سنتات على استدعاءات API ولكن ينتهي بك الأمر مع فوضى من مفاتيح API وإعدادات محلية — وضعت بعض الضمانات للأمان والتثبيت. تُقرأ مفاتيح API من macOS Keychain؛ ويتم تشغيل تجربة جافة افتراضيًا؛ ويجب عليك استخدام --apply صراحةً لإجراء تغييرات حقيقية؛ وتتعامل Workers الخارجية فقط مع المهام ذات الحدود الواضحة؛ والنتيجة النهائية لا تزال تعود إلى سلسلة Codex الرئيسية للمراجعة. اجتاز الخط الأساسي الحالي 37 من 37 اختبار عزل.
بالطبع، لا يزال في مرحلة بيتا. حاليًا يدعم macOS فقط، وستحتاج إلى Codex Desktop، ودعم الوكلاء الفرعيين المخصصين، وNode.js 20+. يتم اختبار Windows ويجب أن يعمل أيضًا. وتذكر — يتم فوترة واجهات برمجة تطبيقات المزودين الخارجيين بشكل منفصل. لذا هذا ليس حلاً سحريًا حيث "بمجرد تثبيت Codex Third-Party Workers، ستدوم Plus إلى الأبد."
تختلف وتيرة استخدام الجميع، ومزيج المهام، وأسعار الأطراف الخارجية. لكن إذا كنت مستخدمًا مكثفًا لـ Codex، فإليك اقتراحي: لا تذعر وتقفز إلى خطة أكثر تكلفة بمجرد أن ترى حصتك تضيق. أولاً، ألقِ نظرة حقيقية على كيفية استهلاك مهامك لها. أي منها يحتاج Codex بشكل مطلق؟ أي منها يمكن تفويضه؟ ما هو الإيقاع الصحي لحصة Plus الخاصة بك؟ بمجرد أن تتحكم في ذلك، يمكن أن تتيح لك إضافة واجهات برمجة تطبيقات نماذج خارجية أرخص إنجاز المزيد من العمل بتكلفة إجمالية أقل.
هذه هي المشكلة الحقيقية التي أردت معالجتها بهذا المشروع مفتوح المصدر. الأمر لا يتعلق باستخدام ذكاء اصطناعي أقل. بل يتعلق بإنفاق أقل قليلاً، وإنجاز المزيد قليلاً.
رابط المشروع: https://github.com/dhy365-creator/codex-third-party-workers
إنه مفتوح المصدر بالكامل بموجب رخصة MIT. إذا كنت أيضًا مستخدمًا مكثفًا لـ Codex، جرّبه. إذا وجدت الفكرة مفيدة، فسأكون ممتنًا لنجمة. شكرًا!