Claude Haiku 5.5 يخفض الكلفة 75%، لكن المهام المعقدة تبقى لـSonnet

أعلنت Anthropic في بيان إطلاقها الصادر في 7 أكتوبر 2026 أن متوسط كلفة تشغيل Claude Haiku 5.5 أقل بنحو 75% من Haiku 4.5، ونقلت عن أليكس وانغ من Rogo وصفه للأعمال الملائمة له بأنها «quick lookups, subagents, and summaries». ويضع الإطلاق النموذج الصغير في موقع مناسب للطلبات القصيرة والمتكررة، بينما تظل البرمجة المعقدة متعددة الخطوات من الأعمال التي يرجح فيها اختيار Sonnet 5.5.

تدرج وثائق Claude Platform النموذج بوصفه نشطاً عبر Claude API بالمعرّف claude-haiku-5-5، وتسعّر كل مليون رمز إدخال وإخراج عند 0.10 و0.50 دولار للموجّهات التي لا تتجاوز 100 ألف رمز، وعند 0.50 و2.50 دولار للموجّهات الأطول؛ وتوضح أيضاً أن النص نفسه يُحتسب بنحو 30% رموزاً أكثر مقارنة بـHaiku 4.5، وأن التفكير التكيفي يعمل افتراضياً، مع حد إخراج تجريبي يبلغ 300 ألف رمز في Message Batches باستخدام ترويسة مخصصة. بذلك يصبح سعر الطلب مرتبطاً بطول موجّهه وحجم الإجابة، لا باسم النموذج وحده.

لماذا يختلف الوفر الفعلي عن سعر الرمز؟

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

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

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

ماذا تكلف مهام التصنيف والتلخيص والوكلاء الفرعيون؟

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

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

تتبدل الصورة لدى الوكيل الفرعي طويل السياق. إذا حمل كل طلب، في مثال مشروط آخر، 120 ألف رمز إدخال وأنتج ألف رمز إخراج، فإن ألف طلب تكلف 62.50 دولار وفق شريحة الموجّه الأطول. تتكون الحصيلة من 60 دولاراً للإدخال و2.50 دولار للإخراج؛ ولا تشمل إعادة المحاولة أو التخزين المؤقت أو استدعاء النموذج الأكبر. يوضح الفارق لماذا يمكن أن تكون خطوة استخراج ضيقة رخيصة، بينما يصبح تكرار السياق الطويل مصدر الإنفاق الأساسي.

أين تظهر أفضلية Sonnet في البرمجة؟

في اختبار Bito البرمجي المنشور في 9 أكتوبر 2026، حقق Sonnet 5.5 نتيجة إجمالية بلغت 82% مقابل 79% لـHaiku 5.5 عند مستوى الجهد المرتفع، بينما بلغت النتيجتان 77% و76% على الترتيب بالإعداد الافتراضي؛ وهذه متوسطات جلسات على مجموعة مهام برمجية اختبرتها Bito داخل Claude Code. يشير تقارب المتوسطين الافتراضيين إلى أن اختيار النموذج الأكبر لكل طلب برمجي قد يرفع التكلفة من دون فائدة مماثلة في الأعمال المحدودة، لكن فرق الجهد المرتفع يميل لمصلحة Sonnet في المجموعة المقاسة.

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

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

حدود API التي تؤثر في اختيار الحمل

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

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

اقرأ أيضًا:

• Claude Opus 5.5 يخفض الكلفة 40%، لكن المقارنة ما زالت من Anthropic
• Claude يدخل محادثات Webex، لكن الوظائف المتقدمة تحتاج إضافة مدفوعة
• Gemini Live ينفذ المهام بالصوت، لكن أقوى الميزات خلف الاشتراك