GPT-6 Astra أم Claude Fable 5.1 أم Gemini 4 Carbon: كيف تختار للبرمجة والبحث والكتابة؟

كلما صدر نموذج لغوي جديد، كان السؤال الأكثر شيوعًا هو نفسه: هل هو أقوى من النموذج السابق؟

لكننا في عمل API Hop اليومي نهتم بأمر آخر: عندما نريد إنجاز العمل نفسه، هل يستطيع النموذج الجديد إتمام المهمة بصورة أفضل وأسرع؟ كم سننتظر؟ وكم ستبلغ التكلفة؟ وهل سيظل الأمر بحاجة إلى تدخل بشري للتعديل؟

نركز هذه المرة على اختبارات GPT-6 Astra وClaude Fable 5.1 وGemini 4 Carbon: تقييمات القدرات العامة، وبيانات وكلاء البرمجة، وحالات إصلاح مشاريع فعلية، واختبارات المهام الطويلة والكتابة وإنشاء صفحات الويب.

النتيجة أولًا: مهام مختلفة ومعايير تقييم مختلفة

خلاصتنا: يختلف أداء النماذج باختلاف سياق العمل.

المعلومات الأساسية للنماذج الثلاثة

لنبدأ بالمعلومات الأساسية التي تقدمها الجهات الرسمية.

ثمة نقطة يسهل إغفالها: النموذج نفسه والأداة التي تستخدمه ليسا الشيء نفسه. في مهمة برمجة واحدة مثلًا، قد تختلف قراءة الملفات وتنفيذ الأوامر وإدارة السياق وإعادة المحاولة عندما يعمل النموذج عبر Codex أوClaude Code أوAntigravity CLI. فالنتيجة التي نراها في النهاية هي نتيجة «النموذج + الأداة + الإعداد».

إذا كان المطلوب تنقيح فقرة، فقد لا يبدو هذا الفرق بارزًا؛ أما إذا أردنا تشغيل النموذج لساعات داخل مستودع كبير، فغالبًا تكون بيئة الأدوات مهمة جدًا.

مقارنة القدرات العامة: Carbon الأعلى درجة، لكنه لا يفوز بالضرورة في كل مهمة

لننظر أولًا إلى التقييم العام ضمن الإصدار نفسه.

يتصدر Carbon هذا الإصدار من المؤشر العام. يستحق نموذج Google الجديد الاهتمام فعلًا، خصوصًا في الاستدلال المعقد والمعرفة والمهام العلمية.

متوسط تكلفة API لـ Astra في هذه المهام أقل من الإعدادين المدرجين للنموذجين الآخرين.

انخفاض الدرجة العامة لـ Fable لا يعني أنه أضعف في جميع الأعمال. فاختبار العمل المعرفي المتخصص أدناه يعطي نتيجة مختلفة.

كيف نختار للبرمجة؟ نهتم أكثر بجودة التعديل والتكلفة الفعلية

أولًا، بيانات وكلاء البرمجة من الإصدار نفسه

يتمثل العمل التطويري اليومي في تنفيذ المتطلبات وإصلاح الأخطاء داخل مستودع ثم تسليم النتيجة؛ لذلك نستخدم تقييم وكلاء البرمجة.

حققت تركيبة Carbon درجة أعلى؛ وكانت Astra + Codex أسرع وأقل في متوسط تكلفة API ضمن هذه البيانات؛ بينما جاءت درجة Fable + Claude Code بينهما، لكن بتكلفة ووقت أعلى.

64 مسألة برمجية: أنجز Fable أكثر، لكن فاتورته أغلى أيضًا

نرى أن اختبار imec/aistack أقرب، من مجرد الدرجة العامة، إلى أسئلة المطوّرين: هل أُصلح الخطأ؟ هل أُنجز المتطلب؟ وكم بلغت التكلفة؟

النتيجة لافتة: حلّ Fable عددًا إضافيًا قدره 17 مسألة، بتكلفة إجمالية إضافية تقارب €68. إذا كان المشروع يعطي أولوية كبيرة لحل المسائل الصعبة، فقد تكون هذه المسائل الـ 17 أهم من المبلغ الموفر؛ أما عند معالجة مهام بسيطة كثيرة يوميًا، فتزداد أهمية التكلفة والسرعة.

خطأ Gradle نفسه: أصلحه كلاهما، فلماذا فضّل المطوّر دمج نسخة Fable؟

توجد أيضًا حالة أصغر لكنها قريبة جدًا من التطوير اليومي.

لاحظنا أن مدونة Gradle الهندسية طلبت من وكيلين إصلاح مشكلة إعداد وثائق واحدة، باستخدام المستودع نفسه وقيود المهمة نفسها. وكانت النتيجة: نجح الاثنان.

لماذا فضّل المطوّر في النهاية دمج تعديل Fable؟ تحققنا من الفروق: كان نطاق الإعداد الذي عدّله Fable أكثر تحديدًا، وأسلوبه أقرب إلى نمط المستودع، وأضاف اختبار انحدار؛ أما تعديل Astra فحل المشكلة الحالية، لكن نطاق الإعداد كان أوسع وقد يسبب آثارًا غير متوقعة عند إضافة كائنات مشابهة مستقبلًا.

نرى أن درس الحالة يتجاوز «من أنجز المهمة أسرع بدقيقتين»: إتمام المهمة هو الحد الأدنى. يجب أيضًا فحص اتساع التعديل، ووجود اختبارات انحدار، وقدرة من يأتي لاحقًا على صيانته.

في مراجعة الشيفرة، الاستدلال الأكثر ليس أفضل دائمًا

كررنا هذه الفكرة عند تقديم نماذج أخرى، ولمسنا في تطويرنا أيضًا أن زيادة الاستدلال لا تضمن نتيجة أفضل.

في سير مراجعة الشيفرة هذا، كان High أبطأ ولم تتحسن المقاييس العامة. لذلك لا تفترض أن High أوMax يستحقان وقتًا وتكلفة إضافيين لمجرد اسميهما. يجب اختبار الأثر الفعلي في سياق العمل.

البحث والعمل على المواد: التشغيل وإنتاج نتيجة لا يعنيان أن الناتج مفيد

في اختبار العمل المعرفي، تغير موضع Fable

لنغيّر نوع المهمة ونرى ما إذا كانت النتائج تتغير.

لهذا لا ننصح بالاكتفاء بترتيب عام واحد: النماذج نفسها تغير ترتيبها النسبي عندما انتقلنا إلى مهام العمل المعرفي.

إذا كنت تنظم أبحاث العملاء أو تكتب تقارير أو تعد مواد عمل، يمكنك وضع Fable ضمن أولويات التجربة.

حتى مهمة بحث بميزانية $10,000 قد تنتهي برفض الورقة

أجرت CRUX تقييمًا طويل المدة يستحق الاطلاع: أعطت Astra وFable 5.1 أسئلة بحث من أوراق غير منشورة، مع ميزانية بحث قدرها $10,000، ثم طلبت من مؤلفي الأبحاث الأصلية مراجعة الأوراق الناتجة.

لاحظنا تقدم النموذجين في تصميم التجارب واستخدام الموارد، لكن الخبراء رفضوا الورقتين النهائيتين صراحةً. شملت المشكلات التي أشار إليها فريق البحث الحكم البحثي والابتكار والتواصل وتعديل الاتجاه عند الإخفاق. ومن المهم أن النموذجين عالجا سؤالين بحثيين مختلفين، لذلك لا تصح مقارنة درجاتهما النهائية كمنافسة عادلة مباشرة. تقرير CRUX البحثي

نرى أن هذه الحالة مفيدة جدًا لمن يستخدم الذكاء الاصطناعي في البحث فعليًا.

مثلًا، إذا طلبنا من النموذج دراسة منافس SaaS، فلا نحتاج إلى 20 صفحة نصية فقط، بل إلى التحقق من صحة الأسعار المذكورة وحداثة الميزات وقنوات مصادر الزيارات وجدوى الاستفادة من الميزات الجديدة.

يمكن للعمل الطويل زيادة حجم الإخراج، لكنه لا يضمن تلقائيًا صحة الاتجاه؛ وقد تكون النتيجة كمية كبيرة من المحتوى غير المفيد. ينبغي أن نكتب المتطلبات مسبقًا، ثم نطلب من النموذج ملء المحتوى ضمن الإطار المحدد، ليصبح المسار أكثر قابلية للضبط.

مهمة Carbon الطويلة لخمس ساعات واجهت مشكلات تسليم أيضًا

سمح تقييم FrontierCS للنموذج بالعمل حتى خمس ساعات لكل مهمة، مع مطالبته باستعادة طريقة أُزيلت من تنفيذ ورقة بحثية، أو تقديم طريقة أفضل.

في هذا الاختبار الخارجي، انتهت بعض التشغيلات مبكرًا قبل تسليم النتائج بسبب طريقة تعامل الوكيل مع المهام الخلفية.

في المهام التي سلّم كلاهما نتائجها، كان متوسط درجة Carbon أعلى؛ لكن ما نريد التنبيه إليه هو أن الوكيل القادر على العمل لساعات قد يسيء تقدير الهدف أو لا يكمل التسليم النهائي.

كتابة المقالات وبناء المواقع: ماذا توضح الحالات المنشورة؟

المادة نفسها: بنية Fable أفضل وسير عمل Astra أسرع

في عملنا البحثي، قدمنا ملف PDF من 20 صفحة إلى Fable 5.1 وAstra كلٍ على حدة، وطلبنا تحويله إلى مقالة طويلة.

كانت مقدمة Fable وتنظيم المقالة أقرب إلى تفضيلاتنا، واضحة البنية ومحكمة المنطق، لكن Astra أكمل المسار كله أسرع.

ننصح المستخدمين عند كتابة المقالات بالنماذج بتجهيز مادة منظمة أولًا، أو تحديد مخطط وبنية عامة على الأقل، حتى يمكن تقييم مطابقة الإخراج للمتطلبات.

إنشاء صفحات الويب: الدرجة لا تعادل الزيارات والتحويلات

عرضت لقطة صفحة WebDev Arena بتاريخ 2026-10-27 الدرجات التالية:

المصدر: الترتيب الأصلي لـ WebDev Arena.

إنشاء صفحات الويب مهمة تجمع التطوير وكتابة المقالات ومواءمة قواعد محركات البحث. لذلك، رغم عرض درجات WebDev Arena، فإن توصيتنا في API Hop، استنادًا إلى خبرتنا الواسعة في بناء الويب، هي استخدام Fable لتخطيط المقالات وAstra للتطوير.

مقارنة الأسعار: سعر الرمز نفسه وفاتورة نهائية مختلفة

نصادف كثيرًا مقارنة تختار الأرخص بمجرد سعر المليون رمز. هذا الرقم مهم بالطبع، لكن من غير المنطقي تحديد الأرخص على أساسه وحده في المهام المعقدة ذات جولات الاستدلال واستدعاءات الأدوات والإعادات المتعددة.

أولًا، أسعار API الرسمية العادية

وحدة الجدول التالي هي دولار / مليون رمز؛ وليست أسعار البيع على منصة API Hop.

هناك تفصيلان آخران قد يؤثران في الفاتورة:

• Astra: عندما يتجاوز الإدخال في طلب واحد 272K رمز، تُضاعف أسعار الإدخال والتخزين المؤقت للطلب كله بمقدار 2، وسعر الإخراج بمقدار 1.5؛ ولا تقتصر الزيادة على الجزء المتجاوز للحد.
• Fable 5.1: تنص الوثائق الرسمية على استخدام أسعار الإدخال والإخراج القياسية لسياق 1M؛ ولكتابة التخزين المؤقت رسوم منفصلة تختلف باختلاف مدة الاحتفاظ.

إذا وضعنا باستمرار مستودعات كبيرة أو مواد طويلة أو سجل محادثات ضخمًا في السياق، فيجب الانتباه لهذه القواعد، وإلا فقد تفاجئنا الفاتورة.

مثال حسابي لاستخدام ثابت

لنفترض أن طلبًا يستخدم بالضبط 100,000 رمز إدخال غير مخزن مؤقتًا، وينتج 10,000 رمز إخراج قابل للفوترة إجمالًا. نتجاهل مؤقتًا رسوم الأدوات وكتابة التخزين المؤقت والإعادات والأسعار الخاصة بالباقات.

حساب هذا الجدول بسيط جدًا: رموز الإدخال / 1,000,000 × سعر وحدة الإدخال + رموز الإخراج / 1,000,000 × سعر وحدة الإخراج.

ثبتنا عدد الرموز هنا في الحساب؛ لكن في التشغيل الفعلي، قد تختلف أطوال التفكير والإخراج وعدد الإعادات بين النماذج.

«تكلفة كل ناتج مقبول» معيار تقييم أفضل

إذا كانت للمهمة حدود ومعايير قبول واضحة، فيمكننا استخدام الآتي:

متوسط تكلفة كل ناتج مقبول = تكاليف API والأدوات لكل التشغيلات ÷ عدد المهام التي اجتازت القبول

يجب أن تشمل التكاليف الكاملة هنا الإخفاقات وإعادة المحاولة. ثم نسجّل بصورة منفصلة وقت التعديل البشري المطلوب لكل نتيجة ناجحة؛ فإذا كان نموذج أرخص بمقدار $2 لكنه يحتاج نصف ساعة إضافية من التعديل، فقد يختلف الاختيار الفعلي تمامًا.

تعرض صفحات النماذج في API Hop أسعار المنصة والأسعار الرسمية المرجعية. ننصح بالنظر إليهما منفصلين والاعتماد على قواعد التسوية الفعلية؛ سعر المنصة لا يساوي سعر API الرسمية. صفحة Astra في API Hop · صفحة Fable في API Hop · صفحة مقارنة API

كيف نتحقق من النماذج الثلاثة باستخدام مهامنا؟

نقترح تقسيم العمل الفعلي إلى مهام صغيرة ذات معايير قبول واضحة، والبدء بخطأ صغير أو متطلب محدود.

لجعل العملية قابلة لإعادة الإنتاج، سنجهز الأنواع الثلاثة التالية من المهام أولًا. هذه خطة اختبار وليست نتائج تجارب أنجزناها بالفعل.

سنشغّل كل نوع مهمة ثلاث مرات لكل نموذج متاح. يمكن البدء بجولة لـ Astra وFable؛ وعندما لا يتأكد وجود مدخل اختبار عام قابل لإعادة الإنتاج لـ Carbon، سنترك نتيجته فارغة، ولن نستبدل Argon بـ Carbon أبدًا.

لجعل البيانات مفيدة، سنثبت إصدار المواد ووصف المهمة والحدود الزمنية والمالية. نستخدم جلسة جديدة في كل مرة، ونسجّل معرّف النموذج الدقيق وإعداد الاستدلال وإصدار الأدوات وحدوث التحويل الاحتياطي والتكلفة والوقت والناتج النهائي. في الكتابة نركز على الأخطاء الواقعية والتعديل البشري؛ وفي إصلاح الأخطاء نركز على الاختبارات ونطاق التغيير.

إذا أردت إجراء مقارنة نصية أيضًا، فيمكنك البدء بهذا القالب البسيط:

نحتاج إلى كتابة مقالة سهلة القراءة للمستخدمين العاديين اعتمادًا على المادة الواقعية التالية.

القراء: أشخاص يتعرفون إلى هذه المسألة لأول مرة
المهمة: شرح المشكلة وتقديم حلول قابلة للتنفيذ وتوضيح شروط ملاءمتها
يجب تغطية: [اذكر 3—5 نقاط رئيسية]
الممنوع: إضافة بيانات غير موجودة في المادة، أو اختلاق تجارب اختبار، أو المبالغة في الاستنتاجات
الإخراج: نص المقالة ومصادر الحقائق المقابلة والمعلومات التي لا تزال بحاجة إلى تأكيد

المادة:
[ألصق المادة نفسها]

مبدأ مهم: لا تحتفظ بأفضل إخراج فقط. المهام الفاشلة والاستدعاءات المتكررة والتدخل البشري تكاليف حقيقية ترافق استخدام النماذج.

الأسئلة الشائعة

هل يستطيع الجميع استخدام Gemini 4 Carbon الآن؟

حتى 2026-10-30، لا يصح هذا الفهم. تقول Google إنها تتيحه أولًا لبعض جهات الدفاع السيبراني، ثم توسّعه تدريجيًا إلى شركاء موثوقين. وجود اختبارات لدى مؤسسات بحثية لا يعني أن كل المطوّرين يملكون صلاحية API عامة عادية. سنحدّث الشرح وفق الإتاحة الرسمية وكتالوج النماذج الفعلي في المنصة. إعلان Google الرسمي

إذا تساوى سعر الإدخال والإخراج في Astra وFable، فلماذا قد تختلف تكلفة المهمة كثيرًا؟

لأن عدد الرموز المستخدمة وإصابات التخزين المؤقت وشدة الاستدلال واستدعاءات الأدوات والإعادات تختلف. حتى عندما يعلن النموذجان $10 للإدخال و$50 للإخراج لكل مليون رمز، لا يضمن ذلك تكلفة متساوية لإصلاح الخطأ نفسه. بلغت الفاتورتان في حالة Gradle مبلغَي $3.54 و$4.34. اختبار Gradle الفعلي

هل Max في Fable 5.1 أفضل حتمًا من شدة استدلال أقل؟

لم نرَ دليلًا يدعم هذا الحكم المطلق. بل وجد اختبار CodeRabbit لمهام مراجعة الشيفرة نفسها أن الإعداد الأعلى استدلالًا أبطأ وأقل في معدل الاسترجاع العام. نوصي بالبدء بإعداد يحقق معايير القبول، ثم تقييم جدوى رفع شدة الاستدلال. اختبار CodeRabbit الفعلي

أي النماذج الثلاثة أنسب للمقالات الصينية الطويلة؟

لا ننوي حاليًا تقديم ترتيب نهائي للثلاثة. توجد حالات كتابة ومعايير للعمل المعرفي، لكنها لا تشكل اختبارًا ثلاثيًا بمواد وبيئة ومعايير كتابة صينية موحدة. نقترح استخدام المادة الصينية نفسها ومقارنة دقة الحقائق والبنية والنبرة ووقت التعديل.

لماذا تختلف الترتيبات بين مواقع التقييم؟

لأن مجموعات المهام وطرق التقييم وإعدادات الاستدلال وأدوات الوكلاء وأسس حساب التكلفة قد تختلف. اختبار المعرفة العامة وإصلاح مستودع حقيقي وتنظيم وثائق العمل ليست المهمة نفسها. ننصح بفحص إصدار الترتيب وتاريخ الاختبار وإعدادات النموذج وشروط النجاح على الأقل قبل اعتماد الاستنتاج.

هل يمكن مقارنة النماذج الثلاثة في المهمة نفسها مباشرةً على API Hop؟

يمكنك أولًا مراجعة GPT-6 Astra وClaude Fable 5.1 وكتالوج النماذج المدرجة حاليًا في API Hop للتحقق من الإتاحة والأسعار الفعلية، ثم مقارنة الإخراج بمهمة نصية واحدة. لا نصف Carbon حاليًا بأنه نموذج يستطيع الحساب العادي استدعاءه مباشرةً. كذلك لا تعادل أداة النصوص عبر الإنترنت بيئة وكيل كاملة قادرة على تنفيذ الشيفرة ورفع الملفات وتصفح الويب؛ لذا يجب التحقق من قدرات الأدوات منفصلًا عند مقارنة وكلاء البرمجة.

أخيرًا، كيف نختار؟

بعد جمع هذه البيانات العامة، أصبحت طريقة اختيارنا أبسط.

إذا أردنا إصلاح خطأ في مستودع قائم، فسنبدأ باختبار Astra وFable على المهمة نفسها داخل مشروعنا: نفحص الإتمام واختبارات الانحدار وتكلفة الصيانة اللاحقة، لا من يخرج الشيفرة أولًا فقط.

إذا أردنا تنظيم مواد أو كتابة تقارير أو إجراء بحث طويل الأمد، فسنركز أكثر على أداء Fable في العمل المعرفي، ونعتبر تقييمات Carbon الجديدة اتجاهًا لاختبارات لاحقة؛ لكن كل نموذج يحتاج إلى تدقيق حقائق وقبول تسليم واضح.

إذا أردنا إنتاج مقالات أو صفحات هبوط باستمرار، فسنحسب أولًا مدى تلبية متطلبات المحتوى ووقت تعديل كل قطعة، بدلًا من الاعتماد على ترتيب القدرات العامة لتحديد مسار المحتوى كله.

نرى أن أنفع صيغة للمقارنة هي: قبول الناتج + التكاليف الكاملة + وقت الانتظار + مقدار التعديل البشري.

لتجربة مهمة نصية حقيقية أولًا، نوفر في API Hop شروح النماذج وتسعيرها ومداخل تجربتها لـ Astra وFable 5.1، ويمكنك مراجعة الأنواع والشروط الحالية عبر صفحة مقارنة API. نحن نقدم خدمات النماذج، لكن اختبارات الجهات الخارجية الواردة هنا ليست تجارب خاصة بـ API Hop؛ وسنحتفظ بالمصادر وحدود الاختبارات لتتمكن من الحكم بنفسك.

المصادر وسجل التحديثات

تاريخ التحقق من المواد: 2026-10-29. تشير الترتيبات المذكورة إلى الإصدارات التي كانت متاحة حينها؛ وقد تتغير الأسعار وصلاحيات النماذج ونتائج التقييم. عند ظهور معلومات إتاحة رسمية جديدة أو اختبارات خاصة بنا قابلة لإعادة الإنتاج، سنسجّل التغييرات منفصلة، ولن نستبدل شروط الاختبار القديمة ببيانات جديدة دون توضيح.

النماذج والأسعار الرسمية

• OpenAI: مواصفات GPT-6 Astra وفوترته
• Anthropic: الصفحة الرسمية لنموذج Claude Fable 5.1
• Google: تقديم Gemini 4 Carbon، 2026-10-28

التقييمات والحالات المستقلة

• Artificial Analysis: نتائج Carbon في Intelligence Index v5.0
• Artificial Analysis: مقارنة Astra وFable في القدرات العامة والعمل المعرفي
• Artificial Analysis: Antigravity CLI وCodex
• Artificial Analysis: Claude Code وCodex، بما فيه نتائج Fable 5.1
• imec/aistack: عدد 64 مهمة برمجية والفواتير الفعلية
• مدونة Gradle الهندسية: طريقتان لإصلاح خطأ وثائق واحد
• CodeRabbit: اختبار فعلي لمراجعة الشيفرة بـ Fable 5.1
• CRUX: مهام بحث مفتوحة لـ Astra وFable
• FrontierCS: مهام شيفرة بحثية لخمس ساعات باستخدام Gemini 4 Carbon
• Aaron Makelky: تجربة الكتابة والمواقع مع Astra وFable
• WebDev Arena: ترتيب إنشاء صفحات الويب

ملاحظة تحريرية: يشير ضمير «نحن» إلى تحقق فريق API Hop من المواد وتحليلها وتوصيات الاستخدام، ولا يعني أننا أعدنا شخصيًا تنفيذ تجارب الجهات الخارجية. جميع حسابات التكاليف التوضيحية تحدد افتراضاتها صراحةً؛ ولا تُجمع درجات أنظمة التقييم المختلفة وتكاليفها أو تُحوَّل مباشرةً.