كيفية تشغيل وكلاء GPT-6.1 Sol في Sharkly

أطلقت شركة OpenAI نموذج GPT-6.1 Sol خلال فعاليات مؤتمر DevDay في 29 سبتمبر بنفس السعر المعلن لنموذج GPT-6 Sol، بواقع 2 دولار لكل مليون رمز إدخال و10 دولارات لكل مليون رمز إخراج، مع خفض سعر رموز الإدخال المخزنة مؤقتًا إلى النصف ليصبح 0.10 دولار. لكن التفصيلة الأكثر أهمية للفرق التي تدير عدة وكلاء Codex جاءت في هدوء تام؛ فشاشة بدء التشغيل في توثيق Codex CLI تعرض الآن gpt-6.1-sol medium. وعلى أي جهاز Computer لا يثبت نموذجًا محددًا، سيتغير النموذج الذي يعتمد عليه الـ Agents تلقائيًا بمجرد قيام أي شخص بتحديث Codex على ذلك الـ Computer، وليس عندما يقرر الفريق ذلك.

لن يُظهر Sharkly هذا التغيير؛ فالـ Agent يتبع النموذج الافتراضي لبيئة التشغيل (Runtime) ولا يعرض اسم النموذج، وبالتالي بعد هذا الأسبوع يمكن لاثنين من الـ Agents بتعليمات متطابقة أن يعملا بنموذجين مختلفين على جهازي Computer مختلفين بينما تبدو مهامهما (Tasks) متطابقة تمامًا على لوحة المتابعة. ومن ثم، تصبح معرفة أي وكيل يعمل بأي نموذج وأي نتيجة صدرت عن أي منهما مسألة تعتمد على التذكر فقط. يغطي هذا الدليل الفروقات والتغييرات فقط منذ دليل GPT-6 Sol الخاص بنا: من أين يأتي النموذج الافتراضي الجديد، ومتى ينبغي تثبيته، والإعدادين اللذين تغيرا، وكيف ينبغي للـ Crew توجيه وتوزيع المهام الآن بعد أن باتت الفئة المتوسطة أقرب بكثير إلى الفئة العليا.

ملخص سريع (TL;DR)

يصل GPT-6.1 Sol إلى Sharkly عبر بيئة تشغيل Codex Runtime على الـ Computer، ولا يتغير أي شيء داخل Sharkly عند حدوث ذلك. تحقق من إصدار بنية Codex الذي يعمل على كل Computer وما إذا كان ملف ~/.codex/config.toml الخاص به يثبت نموذجًا محددًا. تتبع أجهزة Computer التي لم يتم تثبيت نموذج فيها الإعداد الافتراضي لأداة CLI، والذي يوضحه التوثيق الآن بأنه gpt-6.1-sol بمستوى جهد متوسط (medium effort). أما أجهزة Computer التي أُعدت وفقًا لدليلنا السابق فستظل تعمل على gpt-6-sol حتى يقوم أحد بتعديل سطر واحد. استبدل أي مستوى جهد none بالقيمة low، وتوقع أن يظهر خفض تكلفة الذاكرة المؤقتة إلى النصف على أجهزة Computer التي تستخدم مفاتيح API وليس عبر تسجيل الدخول بالاشتراكات، وتناول جدول التوجيه الموضح أدناه كقاعدة لتجربتها على مهامك (Tasks) الخاصة، وليس كحكم نهائي مطلق.

ما الذي تغير في كواليس Codex Runtime

يوضح توثيق Agents سبب تركيز هذا المقال على أجهزة الـ Computers بدلاً من الـ Agents: «يتبع الـ Agent النموذج الافتراضي لبيئة التشغيل (Runtime)، ولا يضمن أو يعرض اسم نموذج محدد. قم بتغيير النماذج من خلال إعدادات بيئة التشغيل Runtime أو إعدادات أداة Computer، وليس على مستوى الـ Agent نفسه». فالترقية هي حدث يخص بيئة التشغيل Runtime. وإليك الفروقات التي يشعر بها الـ Crew:

أضافت أداة Codex CLI المحدثة أيضًا ميزات التفاعل الصوتي، وعرض /agents، وتعديل التوجيهات (prompt editing)، واستئناف الجلسات (resume)، ومساحات العمل الشجرية (worktrees) في جميع الخطط. وتستحق هذه الميزات الاستخدام متى ما كنت تدير Codex يدويًا من الطرفية. ولكن بمجرد أن تصبح مهمة العمل مسؤولية الفريق، فإن الـ Task تصبح هي السجل المشترك. وفي الوضع المؤقت (Temporary mode)، يمنح Sharkly كل Task مسار دليل خاصًا بها، ويمكنه تجهيز worktree جديدة عند العمل على المستودعات البرمجية، كما تعود حالة التشغيل وسجلات الأحداث والأسئلة والنتائج إلى الـ Task لتكون متاحة للشخص التالي.

تثبيت النموذج، أو السماح لكل Computer باتباع الإعداد الافتراضي

ابدأ بحصر شامل ومراجعة للأجهزة، لأن القرار قد يختلف من Computer لآخر. يعرض الأمر sharkly computer list قائمة أجهزة الـ Computers المسجلة لمؤسستك، بينما يُرجع الأمر sharkly computer show <computer-id> بيانات جهاز Computer واحد مع بيئات التشغيل (Runtimes) التابعة له. وعلى جهاز الـ Computer نفسه، يؤدي تشغيل codex إلى طباعة رقم البنية واسم النموذج. ويوضح سجل تغييرات Codex أن الإصدار 0.159.1 (الصادر في 29 سبتمبر) جعل GPT-6.1 Sol هو النموذج الافتراضي، وتُظهر جلسة المثال في التوثيق model: gpt-6.1-sol medium.

عليك الانتباه لأمرين؛ الأول: ما هو الملف التنفيذي (binary) المشغّل؟ ففي نظام macOS، يمكن لجهاز Computer لا يحتوي على Codex مستقل أن يسجل أداة Codex CLI المدمجة داخل تطبيق ChatGPT المكتبي كبيئة تشغيل له، في حين يوصي توثيق Sharkly بتثبيت نسخة مستقلة من Codex وإضافتها إلى متغير PATH بدلاً من ذلك. الأمر الثاني: أي طبقة إعداد تحدد النموذج؟ فوفقًا لما توضحه أساسيات ضبط Codex، توضع الإعدادات الافتراضية الشخصية في ~/.codex/config.toml، بينما يمكن لمستودع برمجي تجاوزها عبر ملف .codex/config.toml الخاص به (والذي لا يُحمّل إلا للمشاريع الموثوقة)، في حين تأتي الخيارات الممررة عبر سطر الأوامر مثل -m أو --model لتكون لها الأولوية على كلا الملفين.

يتلخص القرار في حالتين: دع الـ Computer يتبع الإعداد الافتراضي إذا كان مخصصًا لشخص واحد يدير بضع مهام (Tasks) أسبوعيًا ويفضل تتبع أحدث نموذج توصي به OpenAI بدلاً من صيانة سطر إعداد في ملف التكوين. في المقابل، قم بتثبيت النموذج عندما يسند عدة أشخاص العمل إلى وكلاء (Agents) على ذلك الـ Computer، أو عندما يمتد عمل الـ Crew عبر أكثر من Computer، أو أثناء دورة عمل مستمرة (Sprint)؛ حيث قد يؤدي أي تغيير خفي وتلقائي إلى ظهور نتيجة يوم الثلاثاء ونتيجة يوم الخميس متطابقتين على صفحة الـ Task على الرغم من اختلاف النموذجين اللذين أنتجاهما فعليًا.

لتثبيت النموذج، عدّل إعداد المستخدم على الـ Computer الذي يشغل Codex Runtime:

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

يظهر كلا المفتاحين بهاتين القيمتين في توثيق إعدادات Codex. وإذا كنت قد اتبعت دليل GPT-6 Sol السابق، فسيكون الملف يحتوي بالفعل على model = "gpt-6-sol"، ولن يتغير النموذج على ذلك الـ Computer عند إجراء أي تحديث. يمكنك تعديل هذا السطر عندما تصبح مستعدًا، وليس قبل ذلك.

حدّث Codex باستخدام أداة التثبيت التي يعتمدها التوثيق للتثبيت والتحديث معًا، أو اطلب من Sharkly تحديث الـ CLI لبيئة تشغيل Runtime محددة:

curl -fsSL https://chatgpt.com/codex/install.sh | sh
# or, from anywhere with the Sharkly CLI:
sharkly computer update <computer-id> <runtime-id>

بعد ذلك، قم بإجراء إعادة فحص أو اختبار اتصال عبر صفحة تفاصيل الـ Computer، وتأكد من أن حالة Codex Runtime تظهر كـ Available. وأخيرًا، سجّل النموذج المثبت في وصف الـ Agent؛ إذ لا ينبغي للمراجع الذي يفحص التغييرات (diff) أن يضطر لفتح طرفية shell على جهاز Computer ما ليكتشف النموذج الذي كتب هذا الكود.

الإعدادان اللذان تغيرا: جهد التفكير والذاكرة المؤقتة

اختفى الخيار none تمامًا؛ حيث يقبل GPT-6.1 Sol القيم low وmedium وhigh وxhigh وmax، ولا يدعم none ولا minimal. لذا، فإن أي Computer يطلب إعداده القيمة none — والتي كانت خيارًا طبيعيًا للمسار السريع على GPT-6 Sol — يحتاج إلى تعديله إلى low قبل الانتقال، كما تستحق النتائج مراجعة دقيقة لأن مستوى low لا يزال يمارس التفكير والاستنتاج. وإذا فشلت عملية تشغيل بسبب الإعداد القديم، فإن سجل التنفيذ يحتفظ بالعنوان والاستجابة الأصلية لخدمة النموذج، وتوصي إرشادات استكشاف الأخطاء وإصلاحها في Sharkly بمراجعة خيارات النموذج والطلب بدلاً من إعادة المحاولة عشوائيًا دون فحص.

أما المكسب الأقل صخبًا والأكثر تأثيرًا فهو التخزين المؤقت (cache)؛ إذ حددت OpenAI سعر رموز الإدخال المخزنة مؤقتًا بقيمة 0.10 دولار لكل مليون رمز، وهو ما يمثل «انخفاضًا بنسبة 95% مقارنة بسعر الإدخال القياسي وبنسبة 50% مقارنة بسعر الإدخال المخزن مؤقتًا لنموذج GPT-6 Sol». وهنا يبرز الأثر الحقيقي مع الوكلاء (Agents) الذين يعملون لفترات طويلة؛ فعملية التشغيل التي تمتد لساعة كاملة داخل مستودع برمجي واحد تكرر إرسال قدر كبير من السياق نفسه باستمرار، كما أن أعضاء الـ Crew الذين ينطلقون من هيكل المستودع وقواعده وأوامر الاختبار نفسها يعيدون استخدام بادئة السياق (prefix) ذاتها طوال اليوم.

ولوضع الأمور في نصابها الصحيح، ثمة ثلاث ملاحظات جوهرية: أولاً، لا يظهر التوفير في تكلفة الرموز إلا على أجهزة Computer التي يُفوتر فيها Codex عبر مفتاح API، بينما يستهلك أي Computer يسجل الدخول باشتراك ChatGPT من حصة الخطة، وهو ما يناقشه المقال الآخر حول تشغيل GPT-6.1 Sol دون مفتاح API. ثانيًا، لم يتغير السعر الأساسي المعلن، وبالتالي فإن معالجة المدخلات غير المخزنة مؤقتًا تكلف المقدار نفسه كما في الأسبوع الماضي. ثالثًا، تفرض السياقات الطويلة رسومًا إضافية؛ حيث تسعّر OpenAI أي توجيه (prompt) يتجاوز 272 ألف رمز إدخال بضعف معدل الإدخال والتخزين المؤقت (2x) وبـ 1.5 ضعف لمعدل الإخراج للطلب بأكمله، لذا فإن الـ Agent الذي يسحب سياقًا ضخمًا عبر كل دورة يحتاج إلى تقليص بادئة السياق وتثبيتها قبل منحه ميزانية أكبر.

توجيه الـ Crew: الاختيار بين Astra أو 6.1 Sol أو Luna أو بيئة تشغيل Claude

ترتكز حجة OpenAI لترويج نموذج 6.1 Sol على تحقيقه لنتائج تقارب نموذج Astra بجزء بسيط من التكلفة، وجميع الأرقام المؤيدة لذلك مستمدة من اختبارات تشغيل أجرتها OpenAI نفسها. ففي اختبار DeepSWE v1.1، تشير OpenAI إلى أن 6.1 Sol يضاهي أداء Astra بنحو خُمس التكلفة تقريبًا ويتفوق على أفضل نتيجة حققها GPT-6 Sol بفارق 6.4 نقطة وبجهد أقل. وفي اختبار OSWorld 2.0 المخصص لتقييم استخدام الحاسوب، يقترب النموذج بفارق 2.1 نقطة فقط من Astra عند أقصى درجات الجهد (max effort) وبحوالي سُبع التكلفة لكل مهمة. ومع ذلك، فإن OpenAI واضحة وصريحة بشأن حدوده؛ إذ لا يزال Astra يحقق النتيجة الأعلى في Terminal-Bench Science بنسبة 68.1%، وتنصح OpenAI باستخدام Astra للمهام العلمية الأكثر تعقيدًا وصعوبة.

يصنف دليل اختيار النماذج من OpenAI عائلة النماذج بالطريقة نفسها: نموذج Astra للمشكلات الغامضة، ونموذج 6.1 Sol للأعمال المعقدة التي يمثل فيها الوقت والتكلفة عاملاً حاسمًا، ونموذج Luna للمهام المحددة والفرز الأولي، مع التأكيد على أن هذه التوجيهات مجرد نقطة انطلاق. ونظرًا لأن النموذج يتحدد داخل إعدادات بيئة التشغيل Runtime، فإن قاعدة التوجيه في Sharkly هي في جوهرها قاعدة تخص أجهزة الـ Computers: فالـ Agent المرتبط بجهاز Computer يعتمد Codex فيه على Astra افتراضيًا سيعمل بنموذج Astra. وإليك قاعدة انطلاق مقترحة للاختبار والتجربة:

يمثل السطر الأخير توثيقًا عمليًا للحياد تجاه المزودين، وليس ادعاءً مبنيًا على اختبار قياسي؛ فقد أُطلق نموذج Claude Sonnet 5.5 قبل يوم واحد من 6.1 Sol بنفس السعر البالغ 2 دولار و10 دولارات، في حين قارنت تدوينة OpenAI نموذج 6.1 Sol بنموذجي Opus 5.5 وFable 5.1، ولم تقارنه بـ Sonnet 5.5. ولم ينشر أي مزود مقارنة مباشرة بينهما، لذا فإن المقارنة الوحيدة المعتبرة هي التي تجريها بنفسك على مهامك (Tasks) الخاصة. تجدون التفاصيل الكاملة الداعمة لوضع قواعد مكتوبة تتضمن مسار تصعيد يدوي في مقال توجيه النماذج لفرق العمل (Crews).

لا يغير أي من هذا المحطة النهائية لسير العمل؛ فالوصول إلى نتائج تقارب Astra بتكلفة أقل يعني إنجاز المزيد من عمليات التشغيل يوميًا، ولكن كل عملية منها تنتهي في نهاية المطاف عند شخص يراجع فروقات الكود (diff). يبحث الوكلاء (Agents) وينفذون ويختبرون ويرفعون التقارير، بينما يحدد البشر التوجه العام، ويمنحون الصلاحيات، ويعتمدون النتائج. إن المهمة المفيدة حقًا هذا الأسبوع هي التأكد من قدرة لوحة المتابعة على الإجابة عن التساؤلات: أي Computer شغّل أي نموذج، وما الذي اكتمل بنجاح، وما الذي فشل بسبب إعداد جهد قديم، وما الذي ينتظر المراجعة. وإذا كنت لا تزال تدير طرفيات Codex يدويًا، فإن مقال إدارة وكلاء Codex المتعددين يشرح الطريقة اليدوية أولاً.

يمكنك بناء هذا يدويًا باستخدام مساحات العمل الشجرية (worktrees)، أو الاستعانة بـ Sharkly لإدارة سير العمل بالكامل.