أطلقت Anthropic نموذج Claude Sonnet 5.5 في 28 سبتمبر بسعر دولارين لكل مليون رمز إدخال (input token) و10 دولارات لكل مليون رمز إخراج (output token). وكانت OpenAI قد أطلقت GPT-6 Sol في 22 سبتمبر بالأسعار ذاتها: دولارين و10 دولارات. ستة أيام فقط تفصل بين الإطلاقين، وبالسعر الرسمي نفسه، ويقع كل منهما أسفل النموذج الرائد مباشرة في مختبره. بالنسبة لأي فريق يختار النموذج الافتراضي لوكلاء البرمجة (coding agents)، فإن مقارنة الأسعار وحدها لا تحسم أي شيء. فالخيار الفعلي يدور حول Claude Code مقابل Codex كبيئة تشغيل (Runtime) تحيط بكل نموذج، وما تكلفه كل توليفة لإنجاز المهمة الواحدة.
تعني التجربة المنصفة اختبار بيئتي تشغيل (Runtimes)، وإعدادين مختلفين، ومجموعتين من النتائج، مع مراجع واحد يحاول تذكر أي نافذة طرفية (terminal) أنتجت هذا الفارق البرمجي (diff) أو ذاك. فاختيار النموذج لا يتطلب سوى سطر إعداد واحد، لكن المقارنة بينهما تجسد فوضى الوكلاء البرمجية في أبهى صورها المصغرة.
خلاصة سريعة
يتطابق نموذجا Claude Sonnet 5.5 وGPT-6 Sol في تكلفة الرمز الواحد (token)، لكنهما يختلفان في بيئة التشغيل (Runtime) التي يعتمدها الفريق عادةً: Claude Code لنموذج Sonnet 5.5، وCodex لنموذج Sol. يحتوي جدول الإطلاق الخاص بشركة Anthropic على أربعة صفوف تتضمن عموداً لـ GPT-6 Sol؛ يتصدر فيها Sonnet 5.5 ثلاثة صفوف بوضوح، بينما يعتمد الصف الرابع، FrontierCode، على مستوى الجهد (effort). كما تتباين التكلفة لكل مهمة حسب الاختبار المعياري: ففي FrontierCode، يُعادل أفضل أداء لـ Sonnet 5.5 أفضل أداء لـ Sol بنحو خُمس التكلفة تقريباً؛ أما في AA-Briefcase، فتبلغ تكلفة أفضل أداء لـ Sol نحو 2.67 دولار للمهمة، مقابل 29.19 دولار لـ Sonnet 5.5. هذا جدول صادر عن جهة واحدة. لذا، يمكنك حسم المقارنة بين Sonnet 5.5 وGPT-6 Sol بتشغيل المهمة (Task) ذاتها عبر كلتا بيئتي التشغيل على كودك البرمجي الفعلي وحساب دقائق المراجعة لكل تعديل مقبول. كما يُعد الاحتفاظ بكليهما خياراً وجيهاً تماماً طالما بقيت المهمة (Task) هي المرجع الأساسي للتسجيل.
ما الذي تتيح لك الأرقام المنشورة مقارنته فعلياً؟
أربعة صفوف فقط. يقارن منشور إطلاق Claude Sonnet 5.5 بين نماذج Sonnet 5.5 وSonnet 5 وOpus 5.5 وGPT-6 Sol، وهذه الصفوف وحدها هي التي تحتوي على أرقام تخص Sol:
| الصف في جدول Anthropic | جهة التشغيل | Sonnet 5.5 | GPT-6 Sol |
|---|---|---|---|
| FrontierCode 1.1 (Main) | Cognition: نماذج Claude في Claude Code، ونماذج GPT في Codex CLI | 46.2% عند max، و52.1% عند xhigh | 49.3% |
| GDPval-AA v2.1 | Artificial Analysis | 1844 | 1487 |
| AA-Briefcase v1.1 | Artificial Analysis | 1811 | 1483 |
| Chartography, no tools | اختبار معيار Surge AI؛ جرى تقييم Sonnet 5.5 بواسطة Anthropic، وSol وفقاً لتقرير Surge AI | 61.6% | 53.6% |
هذا جدول صادر عن جهة مزودة واحدة. فقد نُشر إعلان OpenAI الخاص بنموذج Sol قبل ستة أيام من وجود Sonnet 5.5، وبالتالي فإن جدول المقارنة الوحيد الذي يجمع كلا النموذجين من شركة مزودة هو جدول Anthropic. كما يتضمن كلا العمودين تنبيهاً بشأن أخطاء برمجية: فقد اعتمدت اختبارات Artificial Analysis لنموذج Sonnet 5.5 على نسخة ما قبل الإطلاق كانت تحوي خطأً برمجياً في المخرجات المنظمة (structured-output) جرى إصلاحه لاحقاً، كما أصلحت OpenAI مؤخراً خطأً في فهم الصور لدى Sol قد لا تعكسه نتائج Artificial Analysis وSurge AI.
صف FrontierCode هو ما ينبغي لأي فريق برمجي التدقيق فيه، لأنه يمثل بالفعل مقارنة بين بيئتي تشغيل (Runtime): فنسبة 52.1% مقابل 49.3% تمثل Claude Code مع Sonnet 5.5 مقابل Codex CLI مع Sol، وهما التوليفتان اللتان ستنشرهما عملياً. وتكتسب الحاشية السفلية الخاصة بنتيجة الحد الأقصى (max) الأهمية ذاتها؛ إذ يفرض FrontierCode عقوبات على التعديلات الخارجة عن نطاق المهمة، وعند تعيين الجهد على أقصى مستوى (max effort)، شغل Sonnet 5.5 مهارة مراجعة الكود في Claude Code بتكرار أكبر، مما أدى إلى تفرع العمل لعدة وكلاء فرعيين (subagents). وفي حالتين فحصتهما شركة Cognition، تسبب ذلك في انتهاء مهلة التشغيل (timeout) أو إجراء تعديلات خارج نطاق المهمة. أي: جهد أكبر، وفارق برمجي (diff) أوسع، ومراجعة أطول.
لا يوجد أي عنصر آخر في الصفحة يحمل أرقاماً لنموذج Sol. كما ترسم مخططات الجهد لكل من Terminal-Bench 4.0 وCursorBench 4.0 بيانات نموذج GPT-5.6 Sol، نظراً لعدم نشر أي أرقام لنموذج GPT-6 Sol.
هناك مؤشر مجمع واحد من جهة خارجية؛ إذ يضع موقع Artificial Analysis نقطة النهاية (endpoint) الخاصة بنموذج Sonnet 5.5 بأقصى جهد عند 56 نقطة على مؤشر الذكاء (Intelligence Index) الخاص به، ليحل في المرتبة الثالثة من بين 216 نموذجاً حتى 29 سبتمبر. في المقابل، سجل Sol 48 نقطة في 23 سبتمبر عند آخر تسجيل لدينا. تاريخان مختلفان، ومؤشر متغير باستمرار، ولا يقيس أيٌّ من الرقمين أداء مستودعك البرمجي الخاص.
التكلفة لكل مهمة مكتملة، وليس لكل رمز
لا تعكس الأسعار المتطابقة للرموز (tokens) الكثير عن الفاتورة الفعلية، لأن عدد الرموز المستهلكة لكل مهمة يعتمد على النموذج، ومستوى الجهد (effort)، وبيئة التشغيل (Runtime). وتنشر صفحة إطلاق Anthropic النتيجة والتكلفة لكل مهمة حسب مستوى الجهد لصفين من الصفوف المشتركة:
| مستوى الجهد | FrontierCode: Sonnet 5.5 | FrontierCode: GPT-6 Sol | AA-Briefcase: Sonnet 5.5 | AA-Briefcase: GPT-6 Sol |
|---|---|---|---|---|
| low | 29.3%, $0.19 | 37.3%, $0.43 | 1264, $0.87 | 905, $0.12 |
| medium | 36.5%, $0.24 | 45.9%, $0.77 | 1461, $1.64 | 1142, $0.34 |
| high | 49.4%, $0.42 | 47.7%, $1.04 | 1634, $3.95 | 1289, $0.63 |
| xhigh | 52.1%, $1.59 | 48.4%, $1.32 | 1746, $9.63 | 1364, $1.19 |
| max | 46.2%, $20.78 | 49.3%, $2.07 | 1811, $29.19 | 1483, $2.67 |
لنبدأ بقراءة نتائج FrontierCode أولاً؛ يحقق Sonnet 5.5 عند مستوى الجهد high نسبة 49.4% بتكلفة 0.42 دولار للمهمة، ليتساوى مع أفضل نتيجة لـ Sol البالغة 49.3% بتكلفة 2.07 دولار؛ وتلخص Anthropic ذلك بأنه «نحو خُمس التكلفة لكل مهمة تقريباً». أما التفصيل الأهم الذي يستوجب الانتباه فيقع في مستوى أدنى: فعند مستوى medium، يسجل Sonnet 5.5 نسبة 36.5%، وهي أقل من نتيجة Sol حتى عند مستوى low، علماً بأن medium هو مستوى الجهد الافتراضي في Claude Code لنموذج Sonnet 5.5. ويقترح دليل هندسة الأوامر (prompting guide) من Anthropic البدء بمستوى high، أو medium للبرمجة القائمة على الوكلاء في المهام محددة المعالم. وهكذا، فإن إعداداً قد لا يلتفت إليه أحد يمكن أن يحسم المقارنة بأكملها.
أما اختبار AA-Briefcase، وهو معيار مخصص لمهام العمل المعرفي، فيسير في الاتجاه المعاكس؛ إذ تبلغ تكلفة أفضل نتيجة لـ Sol نحو 2.67 دولار للمهمة؛ بينما تبلغ تكلفة أفضل نتيجة لـ Sonnet 5.5 نحو 29.19 دولار، أي قرابة أحد عشر ضعفاً، مقابل نتيجة أعلى. وإعداد Sonnet 5.5 الأقرب لتكلفة Sol عند المستوى الأقصى (max) هو medium بتكلفة 1.64 دولار، حيث يحقق 1461 نقطة مقابل 1483. النموذجان نفسهما، لكن بنتيجة معكوسة تماماً حول أيهما أقل تكلفة مقابل النتيجة المحققة.
يُقلص التخزين المؤقت (Caching) هذه الفجوة ويغير معالمها؛ إذ يقرأ Sonnet 5.5 المدخلات المخزنة مؤقتاً بسعر 0.10 دولار لكل مليون رمز، مع تكلفة كتابة في الذاكرة المؤقتة لمدة 5 دقائق تبلغ 2.50 دولار (أسعار Anthropic). بينما تخصم OpenAI ما نسبته 90% على قراءة المدخلات المخزنة مؤقتاً في GPT-6، أي 0.20 دولار من أصل دولارين، وبذلك تصبح تكلفة القراءة المخزنة مؤقتاً في Sonnet 5.5 نصف تكلفتها في GPT-6. لكن الفرق الجوهري يكمن في ما يؤدي إلى إبطال التخزين المؤقت (cache invalidation)؛ حيث تذكر OpenAI أن تغيير جهد التفكير الاستنتاجي (reasoning effort) أو مدى توفر الأدوات لم يعد يبطل التخزين المؤقت، في حين يوضح دليل هندسة الأوامر لـ Sonnet 5.5 من Anthropic أن تغيير مستوى الجهد الرئيسي بين الطلبات يبطله، مشيراً إلى إعداد تجريبي (beta) لتحديد الجهد لكل رسالة على حدة. والوكلاء الذين يغيرون مستوى الجهد في منتصف المهمة سيلاحظون أثر ذلك مباشرة في الفاتورة.
لا تمثل أيٌّ من هذه الأرقام تكلفتك الفعلية لكل تعديل مقبول؛ فالتشغيل الرخيص الذي يتطلب عمليتي إعادة تشغيل ومراجعة مطولة هو في الواقع التشغيل الأكثر تكلفة.
كيف تحسم القرار على قاعدة كودك البرمجي الخاصة؟
قم بتشغيل المهمة (Task) ذاتها عبر كلتا بيئتي التشغيل (Runtimes) واحسب الوقت الذي يقضيه المراجع البشري لقبول النتيجة. المعايير موضحة بالتفصيل في مقال كيفية المقارنة بين وكلاء البرمجة على قاعدة كودك الخاصة؛ وإليك خطوات الإعداد لهذه التوليفة.
لا تحدد Sharkly النماذج بنفسها؛ إذ ينص توثيق الوكلاء (Agents documentation) صراحةً على ما يلي: «يتبع الوكيل (Agent) النموذج الافتراضي لبيئة التشغيل (Runtime). ولا يضمن أو يعرض اسماً محدداً للنموذج. لذا غيّر النماذج من خلال إعدادات بيئة التشغيل أو أداة Computer، وليس على مستوى الوكيل». بالتالي، فإن ضبط النموذج يتم على مستوى Computer:
- Claude Code مع
claude-sonnet-5-5. يتطلب ذلك الإصدار v2.1.284 من Claude Code أو أي إصدار أحدث. النموذج الافتراضيdefaultفي Claude Code هو Opus 5.5 لخطط Pro وMax وTeam وEnterprise وواجهة برمجة تطبيقات Anthropic API؛ لذا سيقوم Computer بتشغيل Opus ما لم يقم أحد بتغييره، كما أن الاسم المستعارsonnetلا يشير إلى Sonnet 5.5 إلا عبر Anthropic API. حدد المعرف الكامل وثبّته وتأكد منه عبر الأمرclaude --model claude-sonnet-5-5على ذلك المضيف. يحتوي مقال تشغيل وكلاء Sonnet 5.5 في Sharkly على المسار الكامل للخطوات. - Codex مع
gpt-6-sol. قم بتعيين النموذج في إعدادات Codex على ذلك الـ Computer؛ يوضح مقال تشغيل وكلاء GPT-6 Sol في Sharkly الخطوات بالتفصيل. - دليل عمل مؤقت (Temporary working directory) لكلا الوكيلين. يحصل كل تشغيل على دليل معزول، كما يمكن لعمليات التشغيل المرتبطة بالمستودع تجهيز مسار عمل مستقل ونظيف (fresh worktree)، بحيث لا تشترك المحاولتان في مسار استخراج الكود (checkout) نفسه أبداً.
ثم دوّن تفاصيل التجربة قبل بدء أيٍّ من التشغيلين:
Task: SH-312, one real Task, same description and starting commit for both runs
Run A: Claude Code Agent, claude-sonnet-5-5, effort: medium (Claude Code default) or high
Run B: Codex Agent, gpt-6-sol, effort: whatever Codex on that Computer is set to, written here
Accept: the same acceptance test for both
Record: accepted y/n, human review minutes, reruns, files touched outside scope,
provider cost from your own Anthropic and OpenAI bills
Decide: after several Tasks of each kind you actually assign, not one
أسند المهمة (Task) إلى أحد الوكيلين، وابدأ تشغيل الوكيل الآخر بالإشارة إليه (mention) في تعليق؛ إذ تتيح لك Sharkly بدء تشغيل وكيل ليس هو المسند إليه المهمة عبر الإشارة الصريحة. ويعود كلا التشغيلين إلى المهمة ذاتها، مما يعني أن الفارقين البرمجيين (diffs) وتشغيلي الاختبار وأي أسئلة ستظهر جميعها في جدول زمني موحد بدلاً من سجلين منفصلين. ويمكنك الاطلاع على تجربة مخصصة لخطأ برمجي واحد مع معايير التقييم في مقال Claude Code مقابل Codex على الخطأ البرمجي نفسه.
امنح دقائق المراجعة الوزن الأكبر في تقييمك؛ إذ يشير دليل هندسة الأوامر من Anthropic إلى أن Sonnet 5.5 يضيف اختبارات وتوثيقاً وملفات صغيرة عند كافة مستويات الجهد، ويتواصل مبكراً في المهام الطويلة عند مستويي low وmedium، كما يبدأ جولات مراجعة إضافية أو يطلق وكلاء فرعيين للمراجعة عند مستويي xhigh وmax. وأياً كان ما يفعله Codex مع Sol في المواقف نفسها، فستكشفه التجربة بوضوح. كل هذا يصب مباشرة في وقت المراجعة، ولا يظهر أيٌّ منه في نتائج الاختبارات المعيارية.
لماذا يُعد خيار «الجمع بينهما» حلاً وجيهاً؟
لا تحسم الأدلة المنشورة فائزاً قاطعاً يناسب الجميع، وقد لا تنتهي تجربتك إلى فائز حاسم أيضاً. فالنتيجة المتباينة تُعد استنتاجاً مهماً بحد ذاتها، وليست فشلاً للتجربة.
اختر بيئة تشغيل (Runtime) واحدة إذا أظهرت التجربة عدم وجود فارق حقيقي يصمد أمام حساب دقائق المراجعة، أو عندما يفضل فريق صغير الاكتفاء باشتراك واحد وإعدادات موحدة. وإذا كنت تعتمد فقط على Claude Code وتفضل أسلوب عمل يركز على سطر الأوامر (terminal-first)، فقد لا تحتاج إلى طبقة إدارة على الإطلاق. واحتفظ بكليهما عندما تتباين النتائج بحسب نوع المهمة، أو إذا كنت ترغب في تغيير النموذج الافتراضي الشهر المقبل دون الحاجة إلى إعادة بناء سير العمل من الصفر. والحديث عن الشهر المقبل ليس مجرد افتراض: فقد أُطلقت نماذج Opus 5.5 وSol وLuna في يوم واحد، وتبعتها Sonnet 5.5 بعد ستة أيام فقط.
لا ينجح الجمع بين النموذجين إلا إذا كانت المهمة (Task) هي المرجع الأساسي للتسجيل، وليس بيئة التشغيل (Runtime). فلا يوجد نموذج آخر يمكنه قراءة كتل التفكير (thinking blocks) الخاصة بنموذج Sonnet 5.5؛ وبالتالي، عندما تنتقل المهمة من وكيل Claude Code إلى وكيل Codex، يظل التفكير الاستنتاجي محصوراً هناك، ولا ينتقل سوى ما كُتب صراحةً في المهمة. فالقرارات والافتراضات والأسئلة المفتوحة مكانها الوصف أو التعليقات. يتناول مقال تشغيل Claude Code وCodex معاً على قاعدة كود واحدة التفاصيل اليومية لهذا الاستخدام، بينما يشرح مقال Sonnet 5.5 أم Opus 5.5 آلية التوجيه من جانب نماذج Claude.
يتولى الوكلاء مهام البحث والتنفيذ والاختبار وإعداد التقارير، بينما يحدد البشر التوجه، ويمنحون الصلاحيات، ويعتمدون النتائج. قد تتغير بيئة التشغيل كل ثلاثة أشهر؛ لكن السياق والتقدم وموانع العمل (blockers) والنتائج والمراجعة البشرية يجب أن تظل مرئية في مكان واحد، بدءاً من الطلب وحتى الإطلاق النهائي.
كانت نسخة الأسبوع الماضي من هذا التساؤل، Opus 5.5 مقابل GPT-6 Sol، تعاني من مشكلة الأدلة المعكوسة ذاتها؛ إذ قارن منشور OpenAI نموذج Sol بنموذج من عائلة Claude تم تجاوزه بعد ساعات قليلة. حدد النموذج الافتراضي، وقِس أداءه على كودك الفعلي، واجعل بيئة التشغيل إعداداً قابلاً للتعديل في أي وقت. وإذا كنت ترغب في الاستمرار باستخدام عدة وكلاء برمجة بدلاً من إلزام نفسك بمنظومة واحدة، فهذه هي المشكلة التي صُممت Sharkly لحلها تحديداً: اربط Computer واحداً، وأنشئ وكيلاً (Agent) واحداً لكل بيئة تشغيل، وأسند إلى كليهما المهمة الحقيقية ذاتها.
