تتلخص المقارنة بين GPT-6.1 Terra وGPT-6.1 Sol في مقايضة أساسية واحدة: تبلغ تكلفة Terra نصف تكلفة Sol تمامًا لكل رمز (Token)، وبحسب ما أعلنته OpenAI، فهو أسرع بأكثر من ثلاث مرات، بينما يتفوق Sol محققًا 54 نقطة مقابل 48 لـ Terra في معيار خارجي لقياس كفاءة وكلاء البرمجة الذاتيين. أطلقت OpenAI نموذج Terra في 26 أكتوبر تحت معرّف gpt-6.1-terra ليمثل الفئة المتوسطة الجديدة بين Sol وGPT-6 Luna.
إذا كنت تشغّل وكيلاً برمجيًا واحدًا فقط، فاختر النموذج الذي تثق به ولا تشغل بالك. أما إذا كنت تدير عشرات الوكلاء، فإن النموذج الافتراضي يكتسب أهمية بالغة تفوق الاستثناءات؛ لأن هذا الإعداد الافتراضي هو ما تُحسب على أساسه تكلفة معظم خطوات الوكيل. يوضح هذا المقال قاعدة توجيه لفرق العمل (Crew) في منصة Sharkly: اعتماد Terra كنموذج افتراضي للأعضاء، وتخصيص Sol لقائد الفريق والحالات المعقدة، مع بيان تكلفة كل 1,000 خطوة لكل تركيبة.
خلاصة سريعة
اجعل GPT-6.1 Terra النموذج التشغيلي الافتراضي لأعضاء الفريق (Crew) المكلفين بمهام البرمجة الروتينية، والكتابة، واستخدام واجهات الكمبيوتر. واحتفظ بـ GPT-6.1 Sol لقائد الفريق وللمهام (Tasks) التي تفشل مرتين متتاليتين مع Terra. بناءً على نمط الخطوات التوضيحي لدينا، تبلغ تكلفة الاعتماد الكامل على Sol نحو 26.55 دولارًا لكل 1,000 خطوة وكيل، في حين تنخفض إلى 13.28 دولارًا عند الاعتماد الكامل على Terra، وتصل إلى 14.60 دولارًا عند تشغيل الأعضاء بنموذج Terra تحت قيادة Sol. وتظل قاعدة "Terra أولاً ثم التصعيد إلى Sol" أوفر تكلفة من الاعتماد الكامل على Sol ما لم تتطلب نصف مهامك التصعيد.
مقارنة سريعة بين GPT-6.1 Terra وGPT-6.1 Sol
| GPT-6.1 Terra | GPT-6.1 Sol | |
|---|---|---|
| معرّف واجهة برمجة التطبيقات (API id) | gpt-6.1-terra |
gpt-6.1-sol |
| الإدخال / الذاكرة المؤقتة / الإخراج لكل مليون رمز | $1 / $0.05 / $5 | $2 / $0.10 / $10 |
| مؤشر وكلاء البرمجة (Artificial Analysis) | 48 | 54 |
| السرعة (وفقًا لـ OpenAI) | أسرع بأكثر من 3 أضعاف في المتوسط | المعدل القياسي المرجعي |
| أدنى مستوى للجهد الاستدلالي (Effort) | none |
low |
| المجالات الموصى بها من OpenAI | استخدام الكمبيوتر، الكتابة، الإدراك البصري | المهام البرمجية الأكثر تعقيدًا |
جميع بنود التسعير مقسومة على النصف تمامًا، وهو ما يجعل جانب التكلفة محسومًا بوضوح، وينقل التساؤل الحقيقي إلى الجودة: كم مرة ستؤدي نتيجة Terra الأقل في البرمجة إلى الاضطرار لإعادة تشغيل المهمة؟
ثمة تفاصيل تسعيرية قليلة في Terra تصنع فارقًا في حلقات الوكلاء الطويلة: تبلغ تكلفة وضعي الدفعات (Batch) والمرن (Flex) نصف السعر الرسمي المعلن، بينما يتضاعف السعر في الوضع السريع (Fast). وتُحتسب الطلبات التي تتجاوز 272 ألف رمز إدخال بمقدار ضعفي سعر الإدخال والتخزين المؤقت و1.5 ضعف لسعر الإخراج للطلب بأكمله. يمكنك مراجعة جدول الأسعار الكامل على صفحة الأسعار لدى OpenAI.
ما الذي يحسمه اختيار بيئة التشغيل الافتراضية؟
بيئة التشغيل الافتراضية هي النموذج الذي يعتمده الوكيل (Agent) عند تشغيله دون تحديد نموذج مخصص. وفي إطار فريق العمل (Crew)، يحدد هذا الخيار تكلفة الجزء الأكبر من خطواتك، ومدة بقاء المهام المجدولة في قائمة الانتظار، وعدد النتائج التي تصبح جاهزة للمراجعة يوميًا.
تُعرَّف خطوة الوكيل (Agent Step) هنا بأنها استدعاء واحد للنموذج داخل حلقة التنفيذ الذاتية: قراءة السياق، والتفكير، وإصدار أمر استدعاء أداة أو إجراء تعديل. وقد تتطلب المهمة (Task) الواحدة عشرات الخطوات؛ ولهذا السبب يُعد حساب التكلفة لكل خطوة أكثر دقة وجدوى من الحساب لكل مهمة عند المقارنة بين بيئات التشغيل، فالمهام تتفاوت أطوالها بشكل كبير، بينما تظل بنية الخطوة ثابتة إلى حد كبير.
التكلفة لكل 1,000 خطوة وكيل
للمقارنة بين التوليفات المختلفة، نعتمد خطوة نمطية افتراضية تتكون من: 30 ألف رمز إدخال (يُسترد 85% منها عبر التخزين المؤقت للأوامر)، بالإضافة إلى 1,500 رمز إخراج بما في ذلك خطوات التفكير الاستدلالي. ونظرًا لأن حلقات الوكلاء الطويلة تعيد إرسال سياق المستودع البرمجي نفسه مع كل خطوة، فإن تحقيق نسبة تخزين مؤقت مرتفعة يُعد أمرًا معتادًا بمجرد تهيئة الجلسة.
وفق الأسعار الرسمية المعلنة وبنظام الفوترة عبر مفتاح API، تكلف هذه الخطوة الواحدة 0.0133 دولار مع Terra و0.0266 دولار مع Sol. وبحساب التكلفة لكل 1,000 خطوة:
| توليفة الفريق (Crew mix) | نسبة الخطوات المنفذة على Sol | التكلفة لكل 1,000 خطوة |
|---|---|---|
| الاعتماد الكامل على Sol | 100% | $26.55 |
| أعضاء بـ Terra وقائد بـ Sol | 10% | $14.60 |
| أعضاء بـ Terra، وقائد وحالات معقدة بـ Sol | 25% | $16.59 |
| الاعتماد الكامل على Terra | 0% | $13.28 |
| الاعتماد الكامل على Terra بجهد استدلالي أعلى (3,000 رمز إخراج) | 0% | $20.78 |
تبرز هنا ملاحظتان رئيسيتان: الأولى أن ترقية القائد إلى Sol تزيد التكلفة بنحو 1.30 دولار فقط لكل 1,000 خطوة مقارنة بالاعتماد الكامل على Terra؛ والسبب أن مهام القائد تقتصر على التخطيط وتفويض المهام، فلا يستهلك سوى نسبة ضئيلة من إجمالي الخطوات. والملاحظة الثانية أن تشغيل Terra بجهد استدلالي أعلى يظل أرخص من تشغيل Sol بإعداداته الافتراضية؛ فمضاعفة رموز الإخراج مع Terra تكلف أقل من الانتقال إلى النموذج الأكبر.
لا تشمل هذه الأرقام رسوم إنشاء التخزين المؤقت (Cache-write). وإذا كانت حواسيبك (Computers) تسجل الدخول عبر اشتراك ChatGPT بدلاً من مفتاح API، فستنعكس هذه الوفورات في إمكانية تشغيل مهام أكثر قبل الوصول إلى حدود الخطة بدلاً من وفر مالي مباشر بالدولار. وتوضح OpenAI أن Terra "متاح لجميع مشتركي باقات Plus وPro وEnterprise وEdu في ChatGPT Work وCodex"، بينما لا يتوفر لمشتركي باقتي Free وGo.
قاعدة التوجيه لفرق العمل في Sharkly
يُعرَّف فريق العمل (Crew) في Sharkly بأنه مجموعة عمل قابلة لإعادة الاستخدام تضم مستخدمين ووكلاء برمجيين ينسق أعمالهم وكيل قائد. ويعتمد أسلوب التنفيذ على أولوية القائد أولاً؛ حيث يقرأ القائد المهمة وتعليمات الفريق، ثم يتولى إنجاز العمل بنفسه أو يوجه الإشارة لوكلاء معينين لتنفيذ أجزاء محددة. يتكامل هذا الهيكل بدقة مع بيئتي التشغيل عبر الخطوات الآتية:
- تشغيل القائد عبر GPT-6.1 Sol: يحلل القائد الأهداف التي تكتنفها بعض الضبابية ويحدد الخطوات التالية ومن ينفذها. وأي خطأ في التخطيط ينعكس سلبًا على جميع الأعضاء ويضللهم؛ لذا يستحق هذا الموقع النموذج الأقوى. يوضح دليل قيادة الفرق لدينا لماذا تُعد ترقية مقعد القائد خيارًا اقتصاديًا ذا جدوى عالية.
- تشغيل الأعضاء عبر GPT-6.1 Terra بمستوى جهد
medium: تبدأ هنا كافة مهام البرمجة الروتينية، وإعادة بناء التعليمات البرمجية (Refactoring)، وكتابة الاختبارات، والتوثيق، وأوصاف طلبات السحب (PR descriptions)، ومهام استخدام واجهات الكمبيوتر. - التصعيد عند الإخفاق الثاني: إذا أخفق عضو يعمل بنموذج Terra في إنجاز المهمة مرتين، يقوم مسؤول بشري بإعادة إسنادها إلى نسخة Sol. لا تسمح للوكلاء بالتصعيد تلقائيًا بمجرد التخمين، بل احرص على أن يكون قرار التصعيد واضحًا ومسجلاً على سجل المهمة.
- تتبع معدلات التصعيد بحسب نوع المهمة: إذا تبيّن أن نمطًا محددًا من المهام — مثل عمليات الترحيل بين الخدمات المتعددة (Cross-service migrations) — يتطلب التصعيد في كل مرة، فوجه هذا النوع من المهام إلى Sol منذ البداية.
- إسناد مهام الفرز والتصنيف الأولي إلى Luna: يمكن نقل مهام التصنيف والتوزيع المبدئي إلى فئة أدنى؛ ويتناول دليل GPT-6 Luna تفاصيل هذا المسار.
تمثل هذه الآلية قاعدة انطلاق عملية وليست مجرد نتائج اختبارية. جرّب تطبيقها خلال دورة عمل (Sprint) واحدة، ودع معدلات التصعيد الواقعية في بيئة عملك تحدد لك الفواصل المناسبة بدقة.
متى تفقد استراتيجية "Terra أولاً" جدواها الاقتصادية؟
يترتب على التصعيد تكلفة فعلية؛ فالمحاولة غير الناجحة مع Terra تمثل إنفاقًا إضافيًا قبل الشروع في تشغيل Sol. وبافتراض السيناريو الأسوأ الذي تستهلك فيه محاولة Terra الفاشلة عدد خطوات يماثل جولة تشغيل كاملة على Sol: فإذا كانت تكلفة تشغيل Sol تساوي S، فإن محاولة Terra تكلف 0.5S. وبافتراض أن نسبة f من المهام يتم تصعيدها، فإن متوسط التكلفة المتوقعة لكل مهمة يصبح 0.5S مضافًا إليها حاصل ضرب f في S.
وتتساوى هذه المعادلة مع تكلفة الاعتماد الكامل على Sol عندما تصل نسبة f إلى 0.5؛ مما يعني أن استراتيجية "Terra أولاً" تظل الخيار الأوفر اقتصاديًا حتى تصل نسبة المهام المُصعّدة إلى النصف. وتنطبق الحسبة الحسابية نفسها على جولات العمل الأطول: يبقى Terra الخيار الأرخص لكل مهمة ما لم يستغرق ضعف عدد خطوات Sol لإنجازها.
ونظرًا لأن نقطة التعادل المالي تقع عند هامش متسع، فإن العامل الحاسم عمليًا غالبًا ما يكون وقت المطورين والمهندسين. فكل محاولة غير ناجحة تعني تعديلاً إضافيًا (Diff) يستلزم فتحه، أو سجلاً يحتاج إلى قراءة وفحص، أو إعادة توجيه يدوي من قِبل مسؤول. فإذا تجاوز معدل التصعيد نسبة 20% في نوع معين من المهام، فبادر بنقل هذا النوع مباشرة إلى Sol، حتى وإن كانت لغة الأرقام الخاصة بالرموز تدعم Terra.
ولا ننسى أن فارق السرعة يغير الموازين أيضًا؛ فالنموذج الذي ينجز عمله بأكثر من ثلاثة أضعاف السرعة يحرر موارد الحاسوب مبكرًا، مما يتيح للمهام المجدولة البدء في وقت أسرع، ويضمن اكتمال عدد أكبر من جولات التشغيل ضمن المهلة الزمنية المحددة لكل مهمة.
كيفية تطبيق هذه القاعدة في Sharkly
لا تبيع منصة Sharkly الرموز مباشرة، بل تُحسب تكلفة المهام وفق خطة Codex أو مفتاح API المربوط مسبقًا ببيئة التشغيل (Runtime) على كل حاسوب. لذا تأكد أولاً من عمل Terra لديك عبر تحديث Codex CLI إلى الإصدار 0.159.0 أو أحدث، ثم تنفيذ الأمر codex -m gpt-6.1-terra في نافذة الأوامر.
أما داخل Sharkly، فتوضح وثائق الوكلاء أن الوكيل "يعتمد نموذج بيئة التشغيل افتراضيًا"، ويتيح لك حقل النموذج (Model) اختيار أي نموذج آخر من القائمة التي توفرها بيئة التشغيل تلك. كما يمكنك ضبط النموذج المحدد عبر حقل المعاملات المخصصة (Custom arguments) في إعدادات الوكيل أو بيئة التشغيل.
احرص على بناء هذه القاعدة بالاعتماد على النسخ المتباينة (Variants) بدلاً من التعديل اليدوي المستمر. إليك تصورًا للإعدادات الثلاثة:
Agent "Codex, routine" Custom arguments: --model gpt-6.1-terra effort: medium
Agent "Codex, hard tail" Custom arguments: --model gpt-6.1-sol effort: medium
Crew leader Custom arguments: --model gpt-6.1-sol
تذكر وثائق النظام أن "استخدام نموذج افتراضي مختلف" هو أحد أبرز أسباب إنشاء نسخة متفرعة من الوكيل؛ إذ يحافظ ذلك على نفس التعليمات والمستودعات البرمجية الأصلية مع تغيير النموذج فقط. ويوفر استخدام نسختين متباينتين وضوحًا تامًا على لوحة المتابعة، حيث تظهر كل مهمة مسار التنفيذ الذي تولى تشغيلها. ولإجراء تجربة استثنائية، يمكنك استخدام خيار تحديد النموذج لكل تشغيل من قائمة المكلّفين بالمهام (Assignee picker)، وهو ما يتجاوز الإعداد الافتراضي للوكيل لتلك الجولة فقط.
تحافظ Sharkly على السياق الكامل، وسجل التقدم، والعوائق، والنتائج، وملاحظات المراجعة البشرية مسجلة على المهمة ذاتها أياً كان النموذج الذي تولى التنفيذ، وهو ما يجعل تتبع معدل التصعيد وحسابه أمرًا دقيقًا وممكنًا من الأساس.
ما لا يُغيره الاعتماد على نموذج افتراضي أقل تكلفة
يقلل Terra من تكلفة إنتاج التعديلات البرمجية، لكنه لا يخفض تكلفة قبولها واعتمادها؛ فالتشغيل بنصف السعر وثلاثة أضعاف السرعة قد يؤدي إلى تراكم مزيد من طلبات المراجعة بانتظار المهندسين في نهاية الأسبوع. احرص على مراجعة قائمة الفحص لديك قبل زيادة عدد أعضاء الفريق؛ ويشرح مقالنا حول المراجعة البشرية بوصفها عنق الزجاجة هذا الجانب باستفاضة.
علاوة على ذلك، لا يعد هذا النموذج حلاً مناسبًا للمهام بالغة الصعوبة؛ إذ توصي OpenAI نفسها بنموذجي Sol أو GPT-6 Astra لأعقد المهام البرمجية، وهو ما يؤكده فارق الست نقاط في مؤشر وكلاء البرمجة (Coding Agent Index). وتضمن القاعدة الموضحة أعلاه إبقاء تلك الفئة من المهام مسندة إلى Sol بشكل منهجي ومقصود.
خاتمة
اجعل Terra خيارك الافتراضي واجعل Sol هو الاستثناء. فوفق نمط المهام الموضح، يخفض هذا النهج فاتورتك الإجمالية إلى النصف تقريبًا مقارنة بالاعتماد الحصري على Sol، مع إبقاء المهام القيادية والمعقدة بيد النموذج الأكثر قوة. واجعل معيارك في توجيه فئات المهام مبنيًا على تتبع معدل التصعيد الفعلي، لا على مجرد سعر الرموز.
خطوتك التالية: أنشئ نسخة Terra مخصصة من وكيل Codex، وضعها ضمن فريق عمل يقوده Sol، وجرب تشغيلها لدورة عمل كاملة (Sprint). تجدر الإشارة إلى أن منصة Sharkly مجانية حاليًا للفرق التي تضم حتى 5 أفراد، وفق ما هو موضح في صفحة الأسعار.
الأسئلة الشائعة
هل يُعد GPT-6.1 Terra أفضل من GPT-6.1 Sol في البرمجة؟
لا؛ حيث يحقق Sol نتيجة 54 نقطة في مؤشر وكلاء البرمجة لدى Artificial Analysis مقابل 48 نقطة لـ Terra. ويتفوق Terra بوضوح في عاملي التكلفة والسرعة؛ لذا فهو الأنسب للمهام البرمجية الروتينية دون المهام المعقدة شديدة الصعوبة.
ما مقدار الفرق في التكلفة بين GPT-6.1 Terra وGPT-6.1 Sol؟
يبلغ نصف السعر تمامًا في جميع البنود: 1 دولار مقابل 2 دولار للإدخال، و0.05 دولار مقابل 0.10 دولار للذاكرة المؤقتة، و5 دولارات مقابل 10 دولارات للإخراج لكل مليون رمز.
هل ينبغي تشغيل قائد الفريق عبر نموذج Terra؟
من الأفضل بدء تشغيله عبر Sol؛ فالقائد لا يستهلك سوى نسبة محدودة من الخطوات، وبالتالي لا تمثل ترقيته عبئًا ماليًا كبيرًا، بينما يتسبب أي خطأ في التخطيط في إرباك وتشتيت جميع أعضاء الفريق.
هل يمكن ضبط مستوى الجهد (Effort) على none مع Sol؟
لا، فقد أُلغي الخيار none في GPT-6.1 Sol وأصبح أدنى مستوى متاح هو low، بينما يعيد Terra إتاحة خيار none مجددًا.
هل نموذج GPT-6.1 Terra مجاني؟
لا؛ إذ لا تتوفر له فئة مجانية عبر واجهة برمجة التطبيقات (API)، كما لا تتضمنه باقات Free وGo في ChatGPT. يمكنك مراجعة مقالنا حول تشغيل GPT-6.1 Sol دون مفتاح API لفهم الفارق بين استهلاك الباقات ونظام الفوترة حسب الرموز.
كيف يمكنني تحويل مهمة واحدة إلى Sol دون تغيير إعدادات الوكيل نفسه؟
يمكنك استخدام خيار تحديد النموذج لكل تشغيل من قائمة المكلّفين بالمهام (Assignee picker)؛ حيث يتجاوز هذا الاختيار النموذج الافتراضي للوكيل لتلك المهمة تحديدًا دون غيرها.
