الفرق بين كلود سونيت 5 وسونيت 4.6: التغييرات الرئيسية وهل يجب الترقية؟

أصدرت Anthropic نموذج Claude Sonnet 5 في 30 يونيو 2026، وهو بديل مباشر لـ Sonnet 4.6. يمكنك تغيير معرف النموذج، وفي معظم الحالات، يستمر الكود الخاص بك في العمل. ولكن عبارة "في معظم الحالات" تحمل بعض التداعيات في تلك الجملة. يأتي Sonnet 5 مع مُحلل كلمات جديد (tokenizer)، وتفكير تكيفي مُفعّل افتراضيًا، وعدد قليل من معلمات الطلب التي تُرجع الآن أخطاءً بدلاً من العمل. تشرح هذه المقالة بالتفصيل ما الذي تغير، وما هي التكلفة، وما إذا كانت الترقية تستحق العناء لعبء عملك.

النسخة المختصرة: نفس السعر لكل رمز (token)، ودرجات أفضل في مهام البرمجة والمهام الوكيلية (agentic tasks)، وثلاثة تغييرات صغيرة في الكود، وملاحظة غير واضحة تتعلق بالمُحلل اللغوي (tokenizer) تؤثر على عدد الرموز والميزانيات الخاصة بك. اقرأ التفاصيل قبل تشغيل التبديل في الإنتاج.

الترقية في لمحة

يحتفظ Sonnet 5 بنفس تسعيرة الرمز (token) مثل Sonnet 4.6، لذا على أساس كل رمز، لا يتغير شيء في فاتورتك. إنه يحسن المعايير المهمة لاستخدام الأدوات والبرمجة. ويغير بما يكفي من السلوك الافتراضي لدرجة أن التبديل الأعمى قد يفاجئك.

إليك المقارنة جنبًا إلى جنب.

كل شيء آخر يعمل على Sonnet 4.6 يعمل على Sonnet 5 بدون تغييرات أخرى في الكود: المخرجات المنظمة، والرؤية، والتخزين المؤقت للموجهات (prompt caching)، واستخدام الأدوات، والدفعات (batch) كلها تنتقل. الميزة الوحيدة التي تفقدها في المنصة هي Priority Tier، والتي لا تتوفر في Sonnet 5.

ما الذي تحسن: المعايير

يُوضع Sonnet 5 كنموذج Sonnet الأكثر وكالة (agentic) حتى الآن، والأرقام المبلغ عنها تدعم ذلك في العمل الذي يعتمد بكثافة على الأدوات. هذه هي معايير إطلاق Anthropic، وقد تم تأكيدها عبر المقالات المنشورة يوم الإطلاق. تعامل معها على أنها أرقام مبلغ عنها، وليست اختبارات مستقلة.

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

Sonnet 5 أيضًا أكثر أمانًا من 4.6 وفقًا لمقاييس Anthropic: معدل أقل للسلوكيات غير المرغوب فيها، هلوسة وتملق أقل، ومقاومة أفضل لحقن الأوامر (prompt injection). إنه أول نموذج من فئة Sonnet مزود بحماية للأمن السيبراني في الوقت الفعلي. سلوك واحد يجب معرفته: رفض طلب محظور يعود كاستجابة HTTP 200 ناجحة مع stop_reason: "refusal"، وليس كخطأ. تعامل مع سبب التوقف هذا عند تحليل استجابتك.

التغييرات الثلاثة الحقيقية في الكود

معظم عمليات الترحيل لا تمس سوى هذه الأمور الثلاثة. راجعها، واضبطها عند الحاجة، وسيبقى بقية تكاملك دون تغيير.

1. التفكير التكيفي مفعل الآن افتراضيًا

في Sonnet 4.6، كان عدم وجود حقل thinking يعني عدم التفكير. في Sonnet 5، يتم تشغيل الطلب الذي لا يحتوي على حقل thinking مع تفعيل التفكير التكيفي. يقرر النموذج مقدار التفكير بناءً على المهمة، ويمكنك توجيه العمق باستخدام معلمة الجهد (low, medium, high, أو xhigh).

هذا مهم لأن max_tokens هو حد أقصى صارم لإجمالي الإخراج، ويشمل إجمالي الإخراج الآن رموز التفكير بالإضافة إلى نص استجابتك. قد يقوم max_tokens الذي تم تحديده لنص الاستجابة فقط في 4.6 بتقصير إجابتك الآن في Sonnet 5، لأن التفكير يستهلك من نفس الميزانية.

إذا كان عبء عمل ما يعمل سابقًا بدون تفكير وتريد الاحتفاظ بذلك، أوقف التفكير بشكل صريح:

from anthropic import Anthropic

client = Anthropic()

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    thinking={"type": "disabled"},
    messages=[
        {"role": "user", "content": "Return the OpenAPI 3.1 path object for GET /invoices/{id}."}
    ],
)

print(response.content[0].text)

لاستخدام التفكير التكيفي بعمق متحكم فيه، اضبط الجهد بدلاً من تعطيله:

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=8192,
    thinking={"type": "adaptive"},
    effort="medium",
    messages=[
        {"role": "user", "content": "Draft integration tests for the POST /orders endpoint."}
    ],
)

لاحظ الشكل: thinking={"type": "adaptive"}، وليس ميزانية رمز. هذا يقود إلى التغيير التالي.

2. تم إزالة التفكير الموسع اليدوي

النمط القديم thinking: {type: "enabled", budget_tokens: N} يُرجع خطأ 400 في Sonnet 5. كان هذا النمط مهملًا بالفعل في 4.6، لذلك فإن معظم الكود الحالي قد ابتعد عنه، ولكن تحقق منه. استبدل أي ميزانية يدوية بتفكير تكيفي ومعلمة الجهد. إذا كنت تحدد budget_tokens كبيرًا للمهام الصعبة، فإن effort="high" أو effort="xhigh" هو البديل المناسب.

3. معلمات العينات تُرجع الآن خطأ 400

تعيين temperature أو top_p أو top_k إلى قيمة غير افتراضية يُرجع خطأ 400 في Sonnet 5. إهمالها، أو تركها على قيمها الافتراضية، أمر مقبول. كان هذا القيد موجودًا بالفعل في Opus 4.7 والإصدارات الأحدث؛ وهو جديد لفئة Sonnet.

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

شيء واحد لم يتغير عن 4.6: لا يزال التعبئة المسبقة لرسالة المساعد غير مدعومة وتُرجع خطأ 400. إذا كنت تفرض بدء استجابة عن طريق التعبئة المسبقة لدور المساعد، فاستخدم المخرجات المنظمة أو output_config.format أو تعليمات موجه النظام بدلاً من ذلك.

ملاحظة المُحلل اللغوي التي لا يحذرك أحد بشأنها

يستخدم Sonnet 5 مُحلل رموز جديدًا (tokenizer). ينتج نفس النص المدخل حوالي 30% رموزًا أكثر مما كان عليه في Sonnet 4.6، أي حوالي 1.3 ضعف. هذا ليس تغييرًا في واجهة برمجة التطبيقات (API). أشكال الطلب والاستجابة والبث متطابقة، ولا تكتب أي كود جديد لذلك. لكنه يغير أي شيء تقيسه أو تخصص له ميزانية بالرموز.

إليك ما يجب إعادة قياسه:

• عدد الرموز وحقول usage. يبلغ نفس الموجه (prompt) عن المزيد من الرموز تحت Sonnet 5. لا تعيد استخدام أعدادك من 4.6. أعد تشغيل عد الرموز مقابل claude-sonnet-5 لأي موجه تتابعه.
• نافذة سياقك التي تبلغ مليون رمز تحتوي على نص أقل. يغطي كل رمز الآن نصًا أقل في المتوسط، لذا فإن النافذة نفسها تتسع لعدد أقل من الأحرف من محتواك. إذا كنت تقوم بتعبئة السياق بالقرب من الحد الأقصى، فتحقق مما إذا كان لا يزال مناسبًا.
• ميزانيات max_tokens التي تم تحديد حجمها بالقرب من الإخراج المتوقع قد تُقصر. الميزانية التي كانت تستوعب استجابتك النموذجية بشكل مريح في 4.6 قد تقطعها في Sonnet 5. بالاقتران مع التفكير التكيفي الذي يشارك هذه الميزانية، هذا هو السبب الأكثر شيوعًا للإجابات القصيرة غير المتوقعة بعد الترقية.
• تكلفة النص المتكافئ لكل طلب قد تكون أعلى. سعر الرمز الواحد لم يتغير، ولكن المزيد من الرموز لكل طلب يعني أنك تدفع أكثر مقابل نفس النص.

تستحق هذه النقطة الأخيرة مثالاً عمليًا. لنفترض أن موجهًا واستجابة كانا 10,000 رمز في Sonnet 4.6. نفس النص يصبح حوالي 13,000 رمز في Sonnet 5. بسعر متطابق لكل رمز، يكلف هذا الطلب حوالي 30% أكثر على الرغم من أن قائمة الأسعار تبدو كما هي. نمذِج أعباء عملك الحقيقية بحساب الرموز قبل أن تفترض تساوي التكلفة الثابتة. يتعمق تفصيل أسعار Sonnet 5 في هذا الأمر مع حسابات السعر التمهيدي مقابل السعر القياسي.

يمكنك قياس التحول بنفسك باستخدام نقطة نهاية عد الرموز:

curl https://api.anthropic.com/v1/messages/count_tokens \
  --header "x-api-key: $ANTHROPIC_API_KEY" \
  --header "anthropic-version: 2023-06-01" \
  --header "content-type: application/json" \
  --data '{
    "model": "claude-sonnet-5",
    "messages": [
      {"role": "user", "content": "Summarize the changelog for our billing API v3 release."}
    ]
  }'

قم بتشغيل نفس الاستدعاء باستخدام claude-sonnet-4-6 وقارن الأعداد. هذا الاختلاف هو تأثير ميزانيتك الحقيقي.

تكاليف الترقية

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

لذا خلال فترة السعر التمهيدي، يكون النص المتكافئ أرخص لكل رمز من السعر القياسي لـ 4.6، مما يعوض جزئيًا الزيادة بنسبة 30% تقريبًا في الرموز بسبب المُحلل اللغوي الجديد. بعد 31 أغسطس، ستتطابق أسعار الرموز مرة أخرى مع 4.6، ويعني تأثير المُحلل اللغوي أن الطلب المتكافئ قد يكلف أكثر مما كلفه نفس الطلب في 4.6. نمذِج هذا مقابل حركة المرور الفعلية لديك. بالنسبة لأسعار الدفعات والتخزين المؤقت للموجهات، تحقق من صفحة تسعير Anthropic بدلاً من افتراض خصم ثابت.

إذا كنت تقيم الجيل الأقدم من حيث التكلفة أيضًا، فإن أدلة تسعير Sonnet 4.6 و تكلفة Claude API توفر لك الأسس للمقارنة.

هل يجب أن ترقي؟ حكم حسب المستخدم

تبديل معرف النموذج أمر تافه. يعتمد ما إذا كنت ستقوم بذلك على ما تشغله.

قم بالترقية الآن إذا كنت تبني وكلاء (agents) أو أدوات برمجة أو سير عمل كثيف الأدوات.

هذا هو الفوز الأوضح. تقع مكاسب SWE-bench Pro و OSWorld بالضبط حيث تعيش التطبيقات الوكيلية، وتحسينات الأمان تقلل من السلوك غير المرغوب فيه في الحلقات الذاتية. قم بمراجعة المعلمات الثلاث، أعد قياس ميزانيات الرموز الخاصة بك، وأطلقها.

قم بالترقية، ولكن اختبر بعناية، إذا كنت تشغل أعباء عمل إنتاجية عالية الحجم.

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

قم بالترقية عن قصد إذا كنت تعتمد على temperature أو budget_tokens أو التعبئة المسبقة.

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

توقف إذا كنت تحتاج تحديدًا إلى Priority Tier.

إنه غير متوفر في Sonnet 5. إذا كان اتفاق مستوى الخدمة (SLA) الخاص بك يعتمد عليه، فابقَ على 4.6 لتلك المسارات حتى تتغير متطلباتك.

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

اكتشف الانحدارات باستخدام مجموعة طلبات محفوظة في Apidog

الطريقة الأكثر أمانًا للترقية هي مقارنة Sonnet 5 بـ Sonnet 4.6 على موجهاتك الخاصة، وليس على جدول معايير. وهذا بالضبط هو نوع الاختبار قبل وبعد الذي صُممت منصة API لأجله.

Apidog هي أداة شاملة لتطوير واختبار واجهة برمجة التطبيقات (API). عندما تستدعي Claude API، فإنك تضرب نقطة نهاية HTTP مع رؤوس المصادقة، وجسم طلب JSON، واستجابة JSON. يتيح لك Apidog حفظ هذا الطلب مرة واحدة وإعادة تشغيله كمجموعة قابلة لإعادة الاستخدام، مما يحول ترحيل النموذج إلى اختبار متكرر بدلاً من إعادة محاولة يدوية.

عملية ترحيل عملية تبدو كالتالي:

1. احفظ طلبات Messages API الإنتاجية الخاصة بك كمجموعة Apidog، طلب واحد لكل موجه (prompt) تمثيلي.
2. قم بتخزين ANTHROPIC_API_KEY الخاص بك كمتغير بيئة حتى لا تضطر أبدًا إلى لصقه في جسم الطلب.
3. قم بإعداد بيئتين تختلفان فقط بقيمة model: claude-sonnet-4-6 و claude-sonnet-5.
4. أضف تأكيدات على شكل الاستجابة وعلى عدد رموز usage، ثم قم بتشغيل المجموعة مقابل كلتا البيئتين.
5. قارن بين التشغيلين. ستظهر لك فروق عدد الرموز التأثير الحقيقي للمحلل اللغوي على موجهاتك، وأي تأكيد فاشل هو تراجع يجب التحقيق فيه قبل النشر.

يمكنك أيضًا محاكاة نقطة نهاية Claude في Apidog لبناء واختبار تكاملك المحيط، بما في ذلك مسار stop_reason: "refusal"، دون إنفاق رموز. إذا كان تطبيقك مصممًا لوكلاء ويستدعي أدوات أخرى، فإن Apidog هو المكان الذي تختبر وتحاكي فيه واجهات برمجة التطبيقات التابعة أيضًا.

قم بتنزيل Apidog لبناء مجموعة المقارنة، أو افتح Apidog في المتصفح للبدء من طلب. إذا كنت تنتقل من Postman لهذا الغرض، فإن دليل اختبار API بدون Postman يغطي التدفق المعادل.

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

هل Claude Sonnet 5 بديل مباشر لـ Sonnet 4.6؟ غالبًا. تقوم بتغيير معرف النموذج من claude-sonnet-4-6 إلى claude-sonnet-5، ثم تراجع ثلاثة أمور: التفكير التكيفي مفعل الآن افتراضيًا (مما يؤثر على max_tokens)، والتفكير الموسع باستخدام budget_tokens يُرجع خطأ 400، ومعلمات العينات غير الافتراضية تُرجع خطأ 400. كل شيء آخر ينتقل. راجع دليل Sonnet 5 API لإعداد الطلب الكامل.

هل يكلف Sonnet 5 أكثر من Sonnet 4.6؟ لكل رمز، لا. كلاهما يكلف 3 دولارات لكل مليون إدخال و 15 دولارًا لكل مليون إخراج بالأسعار القياسية. لكن مُحلل الرموز الجديد في Sonnet 5 ينتج حوالي 30% رموزًا أكثر لنفس النص، لذا قد يكلف الطلب المتكافئ أكثر حتى بنفس سعر الرمز الواحد. يوجد سعر تمهيدي قدره 2 دولار / 10 دولارات لكل مليون حتى 31 أغسطس 2026.

لماذا يتم قطع استجابتي بعد الترقية؟ التفكير التكيفي مفعل افتراضيًا في Sonnet 5، وتشارك رموز التفكير نفس ميزانية max_tokens مثل نص استجابتك. الميزانية التي كانت تناسب إجابتك في 4.6 قد تقوم بتقطيعها الآن. ارفع max_tokens، أو قم بتعيين thinking={"type": "disabled"} إذا كنت لا تريد التفكير في تلك المكالمة.

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

ماذا حدث لـ temperature و budget_tokens؟ كلاهما يُرجع الآن خطأ 400 في Sonnet 5 عند تعيينهما إلى قيم غير افتراضية. أزل القيم غير الافتراضية لـ temperature و top_p و top_k، ووجه السلوك من خلال موجه النظام الخاص بك. استبدل التفكير الموسع budget_tokens بالتفكير التكيفي بالإضافة إلى معلمة الجهد. يغطي دليل تغييرات Fable 5 و Mythos API نفس النمط في الفئة الأعلى.