مراجعة Claude Sonnet 5: التكلفة الحقيقية ومتى تختاره بدل Opus 4.8

الخلاصة في سطر واحد

انتقل إلى Sonnet 5 للوكلاء والبرمجة والأتمتة كثيفة استخدام الأدوات، لكن احسب أثر تغيير tokenizer قبل افتراض أن التكلفة انخفضت.

أطلقت Anthropic نموذج Sonnet 5 في 30 يونيو 2026 بوصفه أقوى نماذج Sonnet التي طورتها لمهام الوكلاء: يخطط للأعمال متعددة الخطوات، ويشغّل أدوات مثل المتصفح والطرفية، ويُكمل المهام التي كانت نماذج Sonnet السابقة تتوقف في منتصفها. يعمل النموذج بالإعداد effort=high افتراضيًا عبر API وفي Claude Code، وعند هذا المستوى يقترب من Opus 4.8 في بعض المهام، بجزء من سعر Opus. لذلك أصبح الخيار الافتراضي الأنسب لمعظم مستخدمي Claude Code ومطوري الوكلاء.

السبب الذي يستدعي التريث مالي لا يتعلق بالقدرات. تبدو أسعار الإطلاق كأنها خفض مباشر، لكن tokenizer الجديد يحسب النص نفسه على هيئة رموز أكثر بنحو 30%، كما أن هناك 3 تغييرات غير متوافقة في API ستعيد الخطأ 400 إذا نُفّذ الترحيل من دون الانتباه إليها. التفاصيل أدناه.

مراجعة Claude Sonnet 5: ما الذي تغيّر فعلًا منذ Sonnet 4.6؟

يأتي Sonnet 5 كترقية مباشرة لـ Sonnet 4.6، تستبدل قدرًا محدودًا من التحكم اليدوي بمستوى أعلى كثيرًا من الاستقلالية.

أبرز مكاسبه قدرته على مواصلة مهام الوكلاء حتى النهاية. وفق توصيف Anthropic، تركزت أوضح قفزات القدرات الأخيرة في نماذج فئة Opus، لكن Sonnet 5 يقلص الفجوة: يقترب أداؤه من Opus 4.8 بسعر أقل، ويقدم نطاقًا أوسع بكثير من خيارات الموازنة بين التكلفة والسرعة مقارنةً بـ Sonnet 4.6. كما يتفوق على 4.6 في الاستدلال واستخدام الأدوات والبرمجة والعمل المعرفي، وذكر شركاء حصلوا على وصول مبكر أنه أنهى مهام برمجية متعددة الخطوات وراجع مخرجاته من تلقاء نفسه. وفي الاختبارات التي تبرزها Anthropic، أي البحث الوكيلي (BrowseComp) واستخدام الحاسوب (OSWorld-Verified)، يتفوق بوضوح على 4.6، ويمكنه عند رفع مستوى الجهد أن يضاهي Opus 4.8 في بعض المهام. ووفق تقرير السلامة الصادر عن Anthropic، هو أيضًا أقل ميلًا إلى السلوكيات غير المرغوبة من 4.6، وأضعف بوضوح من نماذج Opus الحالية في مهام الأمن السيبراني؛ وهي ميزة لمعظم الاستخدامات التجارية وليست خسارة.

أهم تغيير عملي في السلوك هو أن التفكير التكيفي مفعّل افتراضيًا. في Sonnet 4.6، كان الطلب الذي لا يتضمن الحقل thinking يعمل من دون تفكير. أما في Sonnet 5، فالطلب نفسه يستخدم التفكير التكيفي. النتيجة إجابات أفضل تلقائيًا، لكن بما أن max_tokens يضع سقفًا مشتركًا للتفكير ونص الإجابة، فقد يقطع الآن حد المخرجات المضبوط لـ 4.6 الجزء الظاهر من الرد. لذا يجب إعادة ضبط max_tokens في أي مهمة كانت تعمل سابقًا من دون تفكير.

سعر Claude Sonnet 5 الحقيقي ضمن عائلة Claude 5 كاملة

يبدأ سعر Sonnet 5 عند $2 لكل مليون رمز إدخال و$10 لكل مليون رمز إخراج ضمن الأسعار التمهيدية السارية حتى 31 أغسطس 2026، ثم يرتفع إلى $3 للإدخال و$15 للإخراج بعد ذلك. يوضح الجدول موقعه بين بقية نماذج العائلة وفق الأسعار الحالية:

عند قراءة هذه الأسعار كنسب تصبح المفاضلة واضحة. خلال الفترة التمهيدية، تبلغ تكلفة Sonnet 5 لكل رمز 40% من تكلفة Opus 4.8، وحتى بعد اعتماد سعر ما بعد أغسطس ستبقى عند 60% من تكلفة Opus. وفي الاتجاه الآخر، يكلف النموذج ما يعادل 3x سعر Haiku 4.5 وفق السعر القياسي، بينما تتوقف نافذة سياق Haiku عند 200k مقابل 1M كاملة في Sonnet 5. هكذا يحتل Sonnet 5 موقع الوسط عمدًا: أرخص من Opus، وأعلى قدرات بوضوح من Haiku، مع نافذة السياق نفسها البالغة 1M وسقف الإخراج نفسه البالغ 128k المتاحين في النماذج الرائدة.

هناك مواصفة تؤثر بهدوء في المهام الطويلة: يحتفظ Sonnet 5 بسياق 1M رمز بوصفه الخيار الافتراضي والحد الأقصى معًا، من دون إصدار ذي سياق أصغر، ويمكنه الوصول إلى 300k رمز إخراج عبر Batch API عند استخدام ترويسة الإصدار التجريبي output-300k-2026-03-24. أما ما يفتقده مقارنةً بفئة Opus فهو الوصول إلى Priority Tier، إذ لا تتاح هذه الخدمة لـ Sonnet 5.

ضريبة tokenizer التي تغيب عن حساب تكلفة Claude Sonnet 5

انخفض السعر المعلن، لكن التكلفة الفعلية لوحدة العمل لم تنخفض بالمقدار نفسه؛ فنموذج Sonnet 5 يستخدم tokenizer جديدًا يحول النص ذاته إلى رموز أكثر بنحو 30% مقارنةً بـ Sonnet 4.6.

tokenizer هو المكوّن الذي يقسم النص إلى الوحدات القابلة للفوترة والمسماة رموزًا. تختلف آليته في Sonnet 5 عنها في 4.6، وتذكر Anthropic بوضوح أن نص الإدخال نفسه ينتج عددًا أكبر من الرموز بنحو 30%، مع اختلاف النسبة الدقيقة بحسب المحتوى. لم يتغير سعر الرمز الواحد. لكن الفوترة تتم حسب عدد الرموز؛ فإذا كان طلب ما يُحتسب على أنه 10,000 رمز في 4.6، فسيُحتسب الآن على أنه نحو 13,000 رمز، ما يرفع تكلفة المهمة المكافئة بنحو 30% قبل إدخال تغير السعر نفسه في الحساب. ويعني ذلك أيضًا أن نافذة السياق البالغة 1M تتسع لنص فعلي أقل، وأن حد max_tokens المضبوط على مخرجات 4.6 قد يقطع الرد مبكرًا.

القاعدة العملية هي: توقف عن إعادة استخدام أعداد الرموز المقاسة على النماذج الأقدم، وأعد القياس باستخدام Sonnet 5. إذا كانت توقعات التكلفة أو ميزانيات الطلب الواحد أو منطق تعبئة السياق مبنية على أرقام 4.6، فهي متفائلة الآن. هذا هو النمط نفسه الذي ظهر سابقًا في فئة Opus وشرحته بالتفصيل في تغيير tokenizer في Opus 4.7؛ والحل واحد: أعد العد، ثم اتخذ القرار.

لا يعني ذلك أن Sonnet 5 مرتفع التكلفة. ففي فترة السعر التمهيدي، يظل أقل كثيرًا من Opus عند مقارنة مخرجات متقاربة. لكن المقارنة الصادقة هي "$2 sticker minus a real capability gain plus a ~30% token overhead," لا "it got cheap." احسبها على مهامك الفعلية قبل افتراض وجود وفر.

3 تغييرات غير متوافقة يجب معالجتها قبل الانتقال

الترحيل من 4.6 سهل في معظمه، لكن 3 أنواع من الطلبات التي كانت تعمل سابقًا ستعيد الآن الخطأ 400. عالجها أولًا، وإلا ستتوقف حلقة الوكيل منذ الاستدعاء الأول.

# Fails on Sonnet 5 (returns 400)
resp = client.messages.create(
    model="claude-sonnet-5",
    temperature=0.7,
    thinking={"type": "enabled", "budget_tokens": 32000},
    max_tokens=4000,
    messages=[...],
)

# Works: no sampling params, adaptive thinking, roomier max_tokens
resp = client.messages.create(
    model="claude-sonnet-5",
    thinking={"type": "adaptive"},
    max_tokens=8000,
    messages=[...],
)

مقارنة Claude Sonnet 5 و Opus 4.8: متى يكون الأرخص هو الخيار الصحيح؟

في البرمجة الوكيلية والأتمتة المعتمدة على الأدوات، يكون Sonnet 5 عند effort=high هو نقطة البداية، ولا حاجة للانتقال إلى Opus 4.8 إلا عندما تتطلب المهمة فعلًا سقف القدرات الأعلى.

حجة Sonnet 5 الأساسية هي إمكانية ضبط الجهد. فهو يقدم مستويات الجهد نفسها medium وhigh وextra-high المتاحة في فئة Opus، وتظهر منحنيات التكلفة مقابل الأداء لدى Anthropic أنه يغطي نطاقًا أوسع بكثير من 4.6: كفاءة قوية عند الجهد المتوسط، وقدرة تصل عند رفع الجهد إلى مستوى Opus 4.8 في بعض المهام. وبما أن تكلفته تساوي 40% من تكلفة Opus خلال الفترة التمهيدية، وترتفع إلى 60% بعد أغسطس، فمن المنطقي البدء بـ Sonnet 5 وتصعيد المهام الصعبة المحددة فقط إلى Opus، بدل دفع سعر Opus لكل شيء.

أما مبررات البقاء على Opus 4.8 فأضيق نطاقًا لكنها حقيقية: الأعمال التي تبرر فيها قمة منحنى القدرات تكلفتها، وأصعب مهام البرمجة الوكيلية، والجلسات المستقلة الطويلة التي تكون فيها تكلفة خطوة فاشلة واحدة مرتفعة، وأي حالة لا يكفي فيها وصف "matches on some tasks" لأن المهام الحاسمة هي تحديدًا التي لا يضاهيها. وإذا كنت تفوض أعمال إنتاج غير مراقبة على نطاق واسع، فقد يكون فارق السعر أقل كلفة من تشغيل واحد سيئ على Sonnet.

التقييم الصريح: لماذا يصفه بعض المستخدمين بالتراجع؟

انقسمت آراء المجتمع، وسيكون تجاهل ذلك غير صادق. فإلى جانب الإشادة بأنه "finishes tasks 4.6 couldn't"، ظهرت هذا الشهر في r/ClaudeAI نقاشات تحمل عناوين مباشرة مثل "Sonnet 5 is a downgrade"، إلى جانب سلسلة مستمرة من منشورات "is it actually worth using" و"what's the consensus". هذه الفجوة بين توصيف Anthropic بأنه "close to Opus 4.8" وبين تجربة بعض المستخدمين تستحق الذكر.

هناك عاملان يفسران معظم هذا الانطباع. أولًا، يغير تشغيل التفكير التكيفي افتراضيًا شكل الإجابة وزمن الاستجابة، ولذلك قد تبدو التجربة مختلفة في مسارات العمل المضبوطة على مخرجات 4.6 الأقصر والخالية من التفكير، حتى عندما تتحسن الجودة. ثانيًا، يجعل تغيير tokenizer مقارنة التكلفة أسوأ قبل إعادة القياس، فيُفهم أولًا على أنه "more expensive" قبل أن يُفهم على أنه "different tokenizer". لا يعني أي منهما أن النموذج سيئ؛ بل يعني أن الترقية المباشرة نادرًا ما تكون مباشرة تمامًا. اختبره على التعليمات الفعلية التي تستخدمها قبل تصديق حكم أي شخص، بما في ذلك حكمي.

من ينبغي له الانتقال الآن، ومن الأفضل له الانتظار؟

هل ترحّل إعدادًا للبرمجة أو الوكلاء وتريد ضبط العناصر الأهم أولًا؟ احصل على قائمة إعداد Claude Code وCodex المجانية، التي تجمع خطوات التهيئة وضبط التكلفة الواجب تنفيذها قبل استبدال نموذج في بيئة الإنتاج، وتابع كل تحليل جديد للنماذج فور صدوره.