أعلنت Anthropic عن Claude Opus 5.5 في 22 سبتمبر 2026. تُغطّي هذه المقالة الإصدار في 30 سبتمبر لأنه تحديث نموذج أساسي لم يكن مغطّى في الموقع؛ ولم يصدر اليوم.
تقدّم الشركة النموذج للأعمال الطويلة في Agentic Coding وKnowledge Work. وقصة الـAPI العملية تجمع بين سعر أقل وContext Window بحجم مليون Token وMaximum Output يصل إلى 128K، مع تغييرات كاسرة متعددة. لذلك لا يستطيع فريق إنتاج الترحيل بأمان عبر تبديل Model String فقط.
تقول Anthropic إن Opus 5.5 أقل كلفة بنسبة 40% من Opus 5 في الأحمال المعتادة، وإنه يولد المخرجات أسرع بأكثر من 30%. هذه قياسات أعلنتها الشركة وليست ضمانات مستقلة. السؤال المفيد هو: هل يخفض النموذج الكلفة لكل مهمة ناجحة في أحمالك بعد احتساب Thinking Tokens وRetries وTool Calls والمراجعة البشرية؟
السعر يغيّر قرار التوجيه
سعر Claude API القياسي هو 4 دولارات لكل مليون Input Tokens و20 دولارًا لكل مليون Output Tokens، بدل 5 و25 دولارًا في Opus 5. وتكلف Cache Reads مقدار 0.20 دولار بدل 0.50، بينما تبلغ Cache Writes خمسة دولارات بدل 6.25. ويتوفر Fast Mode بسعر 8 دولارات للإدخال و40 دولارًا للإخراج لكل مليون Token.
تجعل هذه الأسعار Opus 5.5 أقرب للأحمال الطويلة، لكنها لا تجعله Default تلقائيًا لكل Request. قد تبقى مهمة Extraction قصيرة أنسب لنموذج أصغر. أما Repository Migration أو تحقيق متعدد الخطوات أو Knowledge Workflow مرتفعة القيمة فقد تبرر Opus. وجّه بحسب صعوبة المهمة وكلفة الفشل، ثم قِس النتائج الناجحة.
أنشئ سجل كلفة لكل Candidate Run: Uncached Input وCache Writes وCache Reads وThinking والمخرجات الظاهرة وTool Requests والزمن وRetries وحالة المهمة النهائية. اقسم الكلفة الكلية على المهام المقبولة لا عدد API Calls. يمكن لنموذج أعلى سعرًا أن يكون أوفر إذا أنهى المهمة بمكالمات أقل، ويمكن لمسار طويل فاشل أن يكون أغلى مما يوحي به السعر المعلن.
المواصفات مختلفة فعليًا
تذكر صفحة النموذج الرسمية Context Window بحجم 1M وMaximum Output قدره 128K، وAdaptive Thinking يعمل دائمًا، وDefault Effort قيمته medium. معرّف Claude API هو `claude-opus-5-5`. ولا يحتاج السياق إلى Beta Header الذي استخدمته بعض التكاملات القديمة.
مليون Token قدرة استيعاب، وليس سببًا لإرسال كل مستند متاح. ما زالت جودة Retrieval والترتيب وحدود Prompt Cache والخصوصية مهمة. تزيد Prompts الضخمة الكمون وتفتح مجالًا أكبر للتعليمات المتعارضة. اختبر أصغر سياق يحافظ على جودة المهمة، ثم أضف الدليل عندما يغيّر النتيجة.
كما يشمل Maximum Output كلاً من Thinking والنص الظاهر. Request كانت تخصص الحد للنص فقط قد تتوقف مبكرًا بعد الترحيل، لأن `max_tokens` يغطي التفكير والرد. توصي Anthropic بالتحكم في العمق عبر Effort، والبدء بحد كبير عند xhigh أو max ثم ضبطه بالقياس.
لم يعد من الممكن تعطيل Thinking
يقبل Opus 5.5 غياب حقل Thinking أو Adaptive Thinking. أما إرسال Disabled Thinking أو Manual Thinking Budget فيعيد HTTP 400. أداة التحكم الوحيدة المدعومة في العمق هي `output_config.effort` بقيم low وmedium وhigh وxhigh وmax.
يغير ذلك Response Parsing. قد يبدأ الرد بـThinking Block، ولذلك يصبح افتراض `content[0].text` هشًا. اختر Blocks حسب النوع. وفي Tool Loops، أعد Assistant Message كاملة، بما فيها Signed Thinking Blocks ومن دون تعديل، عند إرسال Tool Results. قد يؤدي إسقاط تلك الكتل أو تغيير ترتيبها إلى إبطال المحادثة.
نص Thinking محذوف افتراضيًا. إذا كان المنتج يعرض للمستخدم Narration بين Tool Calls كحالة تقدم، فقد يرى الآن فترة صمت طويلة. استخدم Display Settings الموثقة للملخص أو Progress Updates عندما تناسب التجربة، ووضح أن Progress Text ليست Execution Log دائمة.
فرض أداة بعينها يفشل الآن
يُرفض Tool Choice من نوع `any` أو فرض Named Tool. توجّه Anthropic التكاملات إلى Auto Tool Selection مع Strict Tool Schemas أو Structured Outputs. هذا ليس تعديل Request شكليًا: التطبيق الذي استخدم Forced Tool Choice كحد صلاحيات يحتاج تصميمًا جديدًا.
أبقِ Authorization خارج النموذج. يستطيع Agent تحديد أن الأداة مناسبة، لكن يجب على التطبيق التحقق من اسمها وArguments وصلاحية المستخدم وIdempotency Key وسياسة المخاطر. استخدم Strict Schema ضيقة، واضبط `additionalProperties: false` حيث تتطلب المواصفة، وارفض أي Mutation بلا Product Approval صريحة.
تُرفض كذلك Sampling Overrides غير الافتراضية مثل Temperature وtop-p وtop-k. ولا تُدعم Assistant-message Prefills. استبدل Prefill بـStructured Output أو System Instructions واضحة، واختبر السلوك بدل افتراض أن Request نجحت مع Opus 5 ستنجح مع 5.5.
وكلاء Computer Use يحتاجون ترحيل Toolset
على Claude API وGoogle Cloud، تُرفض أداة `computer_20251124` القديمة. يجب أن تعلن التكاملات `computer_toolset_20260801`، وتحذف Beta Header السابقة، وتكيف الحلقة مع Member Tool-use Blocks التي قد تتعدد في الدور الواحد. ويجب أن يعيد كل Tool Result اسم Toolset الموثق.
توضح Anthropic أن Amazon Bedrock يحتفظ بسلوك توافق مختلف، فلا تستخدم Payload واحدة بلا اختبار عبر المزودين. احتفظ بـProvider-specific Conformance Tests لمعرّفات النماذج وإصدارات الأدوات وأشكال الردود. ويجب تشغيل Computer Use داخل بيئة مقيدة بحدود للنطاق والأفعال والبيانات؛ فالنموذج الأقوى لا يستبدل Sandboxing والموافقات.
التوجيه وFallback يحتاجان قواعد للمحادثة
ترتبط Thinking Blocks بالنموذج والمحادثة. يستطيع Opus 5.5 قراءة Thinking Blocks من عدة عائلات Claude سابقة، بينما لا تستطيع معظم Fallback Models استهلاك Thinking Blocks الخاصة به. لذلك قد يفقد Router يغير النموذج وسط المحادثة تلك الحالة الخفية.
اعتبر المحادثة الظاهرة وTool Results وApplication State السجل القابل للنقل. حافظ على Append-only Conversation عندما تتطلب الـAPI ذلك. وإذا احتاج Fallback إلى الاستلام، لخّص Task State المتحقق منها في Request جديدة بدل افتراض انتقال التفكير الداخلي. واختبر Refusals صراحة: قد يعيد Opus 5.5 `stop_reason: refusal` مع Category، ولا تصلح كل حالة للـServer-side Fallback نفسه.
ادعاءات Benchmarks تحتاج تقييمك المحلي
تنشر Anthropic تحسينات في Agentic Coding وComputer Use وKnowledge Work مع إعدادات الاختبار وتحفظاته. وتقول الشركة نفسها إن فروق Benchmarks أصبحت مؤشرًا أقل موثوقية للفروق في العالم الحقيقي. يجب أن يوجه هذا التحذير الترحيل.
أنشئ Release Set من مهام حقيقية: تغييرات Repository يجب أن تجتاز الاختبارات، وتقارير بحث يمكن التحقق من حقائقها، وTool Workflows بآثار دقيقة، وحالات Long Context تمثل الإنتاج. قِس الصحة وCritical Failure Rate وزمن الإكمال واستهلاك Tokens والكلفة لكل مهمة مقبولة وجهد المراجع. وشغّل كل Candidate على أكثر من Effort Level؛ فـmedium هو Default الجديد، بينما كان Opus 5 يبدأ من high.
افصل ادعاء الشركة عن دليلك. سجّل Model ID وEffort وإصدارات Prompt والأدوات وDataset وCache State وسياسة Retry. Score واحدة بلا هذه المدخلات لا تكفي لقرار Routing.
خطة ترحيل تحد المخاطر
أولًا، احصر كل Request Builder وResponse Parser. ابحث عن Model ID القديم وإعدادات Thinking الصريحة وManual Budgets وForced Tools وSampling Parameters وPrefills وBeta Headers وPositional Text Parsing ونوع Computer Use القديم.
ثانيًا، حدّث العقد في Development Environment. اقرأ Blocks حسب النوع، وحافظ على Thinking Blocks في Tool Loops، وحدد Effort صراحة، وتحقق من Strict Schemas، وتعامل مع Refusal وContext-limit Stop Reasons. وأعد ضبط `max_tokens` كي يتسع Thinking من دون إنشاء ميزانية مخرجات غير مضبوطة.
ثالثًا، أعد تشغيل Evaluation Set ثابتة على الحزمتين القديمة والجديدة. قِس كلفة المهمة الكلية والكمون بدل أسعار Tokens فقط. افحص الانحدارات بحسب Workflow Slice، وتحقق من بقاء Progress وCancellation وTimeouts وAudit Trails صحيحة.
رابعًا، شغّل Shadow Traffic مع تعطيل Mutations. بعد ذلك انشر Canary لشريحة صغيرة مؤهلة خلف Route قابلة للتراجع. احتفظ بالحزمة السابقة كاملة—النموذج وPrompts والأدوات وParser—قابلة للنشر. تراجع عن الحزمة لا اسم النموذج وحده.
القرار العملي
يقدم Claude Opus 5.5 تغيرًا مهمًا في السعر والقدرة للوكلاء الصعبين، لكنه يشدد API Contract في الوقت نفسه. لدى الفرق التي تشغل مهام Coding أوResearch أوComputer Use طويلة سبب قوي لتقييمه. أما المهام البسيطة فيجب مقارنته فيها بنماذج أصغر بدل افتراض أن Flagship هو الخيار الاقتصادي.
يصبح الترحيل جاهزًا عندما تنجح Request Validation، وتُقرأ Response Blocks بأمان، وتبقى Tool Authorization خارج النموذج، وتتحسن الكلفة لكل مهمة مقبولة، وتعمل Failure Paths، ويعيد Rollback حزمة سابقة خضعت للتقييم. قبل ذلك، السعر الأقل دعوة للاختبار لا إذنًا لتبديل حركة الإنتاج بلا قياس.
المراجع الرسمية
تدعم هذه المراجع سلوك الأدوات المذكورة. الأمثلة وقرارات التصميم توضيحية، ويجب تكييفها مع متطلبات المشروع وإصداراته.
إعداد: Noor Yasser
تعمل على تحدٍ تقني مشابه؟
أساعد الفرق على تحويل القرار المعماري إلى نطاق واضح وتنفيذ يمكن تشغيله ومراجعته بثقة.
