Opus 5 اومد، با نصف قیمت Fable 5. benchmarkها عالی‌ان، ولی داستان اصلی تغییرات API هست.

Opus 5 بیست‌وچهارم ژوئیه ۲۰۲۶ عرضه شد. Opus 4.8، همون مدلی که این جایگزینش می‌شه، مدل هرروزِ منه، برای همین release رو با یه سوال مشخص خوندم: نه «باهوش‌تره یا نه» (هست)، بلکه «تو همون loopـی که الان دارم چی عوض می‌شه». جوابش از جدول benchmark جالب‌تر از آب دراومد، و بیشترش هم تو پست بلاگ انتشار نیست.

نسخه کوتاهش اینه. Opus 5 همون‌قدر که Opus 4.8 هزینه داره، پنج دلار برای هر میلیون input token و بیست‌وپنج برای هر میلیون output. این نصف قیمت Fable 5 هست، مدل رده‌بالای Anthropic، و Opus 5 تو بیشتر عددهای مهم تا فاصله فریاد‌رس به Fable می‌رسه. الان مدل پیش‌فرض روی Claude Max و قوی‌ترین مدل روی Claude Pro هست. اگه رو 4.8 بودی، این یه عوض کردن اسم مدله که با همون پول به‌طور محسوسی باهوش‌ترت می‌کنه.

ولی «string رو عوض کن و برو» سه تا تغییر رو قایم می‌کنه که آروم گازت می‌گیرن. اول بذار benchmarkها رو رد کنیم بره، چون کم‌غافلگیرکننده‌ترین بخشن.

benchmarkها، صادقانه

تیتری که Anthropic می‌فروشه اینه: «هوش frontier مثل Fable 5 با نصف قیمت»، و عددها هم بیشترش رو تأیید می‌کنن. روی Frontier-Bench v0.1 با max effort، Opus 5 امتیاز ۴۳٫۳٪ می‌گیره. Opus 4.8 تو همون تست ۱۸٫۷٪ گرفت. Fable 5، مدلی که دو برابر هزینه داره، ۳۳٫۷٪ می‌گیره. Opus 5 نه‌تنها فاصله‌ش با Fable رو می‌بنده؛ تو این benchmark خاص ازش رد می‌شه.

بقیه جدول هم همین شکلیه:

• SWE-bench Verified: ۹۶٫۰٪. باگ‌های واقعی GitHub، که با تست‌های مخفی خود پروژه‌ها نمره‌گذاری می‌شن. یه سال پیش مرز اینجا وسط‌های شصت بود.
• SWE-bench Pro: ۷۹٫۲٪، در مقابل ۸۰٫۰٪ Fable 5. فاصله کمتر از یه امتیاز، نصف هزینه. همین یه مقایسه، کل داستان فروشه.
• OSWorld 2.0: ۷۰٫۵۷٪، بالا از ۵۵٫۷٪ روی 4.8. این benchmark مربوط به computer use هست، یه desktop واقعی Ubuntu که با ماوس و کیبورد کنترل می‌شه.
• ARC-AGI-3 با high effort: ۳۰٫۱۶٪. Opus 4.8 اینجا ۱٫۵۲٪ گرفت. این benchmark مربوط به حل مسئله‌های تازه‌ست، همونی که جوری ساخته شده که نتونی با pattern-matching ازش رد شی، و این جهش غلط تایپی نیست.
• IMO 2026: ۴۲ از ۴۲، سطح مدال طلا روی مسئله‌های امسال المپیاد جهانی ریاضی.

من این عددها رو از release و موج اول پوشش خبری نقل می‌کنم، نه از یه system card که از اول تا آخر خونده باشمش، پس دقت تا رقم سوم اعشار رو با همون احتیاط همیشگی برخورد کن. چیزی که مهمه الگوئه، و الگو روشنه: عددهای agentic و reasoning جایی‌ان که Opus 5 جلو زده، و این کار رو کرده در حالی که رو قیمت Opus موند. اگه روزت رو تو یه coding agent می‌گذرونی، این همون عددیه که تو کارت ظاهر می‌شه.

این همون بخشیه که همه ازش screenshot می‌گیرن. حالا بخشی که واقعاً عوض می‌کنه چطور ازش استفاده می‌کنی.

حالا thinking به‌صورت پیش‌فرض روشنه، و max_tokensـت یه تله‌ست

رو Opus 4.8 و 4.7، درخواستی که فیلد thinking رو ست نمی‌کرد، بدون thinking اجرا می‌شد. این پیش‌فرض بود، و کلی کد دورش نوشته شد، مال منم توش. رو Opus 5 همون درخواست فکر می‌کنه. حذف کردن فیلد الان بهت adaptive thinking می‌ده؛ رفتار قدیمی «بدون thinking» حالا thinking: {type: "disabled"} هست که باید مشخصاً درخواستش کنی.

این فقط یه تغییر رفتار نیست، یه تغییر صورت‌حساب و بریدگیه، و همینه که آدم‌ها رو غافلگیر می‌کنه. max_tokens یه سقف سفت روی thinking به‌علاوه متن جواب هست، با هم. یه workload که هیچ‌وقت thinking رو ست نکرده، رو 4.8 تمیز اجرا شده، و max_tokens رو تنگ دور جواب اندازه‌گیری کرده، حالا یه تیکه از اون budget رو خرج reasoning می‌کنه و می‌تونه وسط جواب بِبُره. هیچی error نمی‌ده. فقط یه جواب کوتاه‌تر از چیزی که خواستی می‌گیری، و اگه output ساختاریافته رو پایین‌دست parse می‌کنی، این به‌شکل یه parse خراب ظاهر می‌شه نه یه علت واضح.

پس اولین کار موقع migration عوض کردن string مدل نیست. اینه که هر call site که هیچ‌وقت thinking رو دست نزده رو بگردی و یا max_tokens رو بالا ببری تا جا بمونه، یا مشخصاً thinking: {type: "disabled"} رو پاس بدی اگه واقعاً رفتار قدیمی رو می‌خوای.

و رو همون اهرم یه لبه دوم هم هست. خاموش کردن thinking فقط رو effort high یا پایین‌تر مجازه. thinking: {type: "disabled"} رو با effort xhigh یا max قاطی کن و یه 400 می‌گیری. این بررسی per request اجرا می‌شه، پس یه route که برای یه turn سخت effort رو xhigh می‌کنه در حالی که thinking هنوز خاموشه، رو همون turn شکست می‌خوره، حتی اگه هر turn قبلی تو همون گفتگو رد شده باشه. اگه رو 4.8 به‌صورت رفلکسی xhigh رو با thinking خاموش اجرا می‌کردی، این ترکیب حالا نامعتبره، و راستش احتمالاً با effort پایین‌تر و thinking روشن بهتر سرویس می‌گیری. Opus 5 رو low و medium به‌طور غیرعادی قویه؛ پیش‌فرض‌های effortـی که از یه مدل قبلی آوردی تقریباً هیچ‌وقت تنظیم درست نیستن.

داربست verification رو پاک کن

این همونیه که غافلگیرم کرد، چون یه توصیه‌ای رو برعکس می‌کنه که دائم می‌دم.

«از مدل بخواه کارش رو دوباره چک کنه» یه تکنیک prompting رایج و درسته. رو Opus 5 غلطه. مدل بدون این‌که ازش بخوای خودش رو verify می‌کنه، پس یه دستوری که ازش می‌خواد verify کنه، یا یه مرحله harness که یه pass verifier راه می‌ندازه، حالا باعث over-verification می‌شه: کار رو می‌کنه، بعد دوباره می‌کنه، بدون هیچ سودی token و latency می‌سوزونه. راهنمای خود Anthropic اینجا رُکه. prompt‌های verification رو پاک کن. این یه پاک کردنه، نه بازنویسی، و برداشتن داربست، over-verification رو بدون افت اندازه‌گیری‌پذیر توانایی کم می‌کنه.

همین غریزه رو subagentها هم دیده می‌شه. Opus 4.8 خیلی کم سراغ delegation می‌رفت و برای پخش شدن به یه هُل لازم داشت. Opus 5 راحت سراغ subagentها می‌ره، گاهی خیلی راحت، چون هرکدومشون دوباره context می‌سازن، دوباره explore می‌کنن، گزارش می‌دن، و بعد coordinator دوباره گزارش رو می‌خونه. اگه harnessـت از subagent پشتیبانی می‌کنه، هر راهنمای «بیشتر delegate کن» که برای 4.8 اضافه کردی باید در بیاد، و احتمالاً یه سقف مشخص روی تعداد spawn می‌خوای. جهت بین این دو مدل برعکس شد، که یه چیز واقعاً غیرعادیه که آدم باید تو یه migration نسخه نقطه‌ای درنظر بگیره.

بعدشم فقط بیشتر حرف می‌زنه. متن جواب پیش‌فرض بلندتره، و فایل‌هایی که رو دیسک می‌نویسه بلندترن. پایین آوردن effort output قابل‌دیدن رو به‌شکل قابل‌اتکایی کوتاه نمی‌کنه، پس اهرم اینجا یه دستور ساده «کوتاه بنویس» تو promptـه، نه یه پیچ. یه خط کوتاه «جواب‌ها رو متمرکز و مختصر نگه دار» تو تست‌های Anthropic طول قابل‌دیدن رو حدود یک‌پنجم کم کرد.

تغییرات کوچیک‌تری که بازم مهمن

چند تا چیز که راحت از قلم می‌افتن:

حداقل prompt cache به ۵۱۲ token افتاد، از ۱۰۲۴ روی 4.8. prompt‌هایی که به‌عنوان خیلی کوتاه برای cache شدن قلمشون گرفته بودی، حالا بدون تغییر کد cache entry می‌سازن. ارزش داره هر چیزی که فرض کردی cache‌شدنی نیست رو دوباره چک کنی.

Fast mode با حدود ۲٫۵ برابر throughput برای دو برابر قیمت اجرا می‌شه، و فقط رو Claude API هست. اگه Bedrock، Vertex یا Foundry تو ترکیبت هست، این اهرم اونجا در دسترس نیست، پس رو اون routeها بندازش کنار.

automatic fallback راحت‌تر شد. classifierهای safety مربوط به Opus 5 می‌تونن یه درخواست رو یکسره رد کنن: یه HTTP 200 معمولی با stop_reason: "refusal" می‌گیری، نه exception. اگه کدت content[0] رو بدون چک کردن اول stop_reason می‌خونه، رو یه refusal می‌شکنه. مود جدید fallbacks: "default" یه درخواست ردشده رو سمت سرور رو یه مدل fallback دوباره اجرا می‌کنه و بر اساس دسته refusal مسیریابی می‌کنه، پس خودت لیست مدل نگه نمی‌داری. برای یه workload نزدیک به امنیت که درخواست‌های بی‌ضرر گاهی یه classifier رو فعال می‌کنن، فعال کردن پیش‌فرض اون حرکت درسته.

rate limitها یه سطل جداست. Opus 5 از pool ترکیبی Opus 4.x برداشت نمی‌کنه، پس جابه‌جا کردن traffic نه رو سطل قدیمی جا باز می‌کنه نه سهمیه‌ش رو به ارث می‌بره. limitهای Opus 5 مربوط به tierت رو قبل از جابه‌جا کردن حجم چک کن.

داستان safety برای هرکسی که کار امنیتی می‌کنه یه تغییر واقعیه

این یکی مخصوصاً برای من مهمه، و احتمالاً برای یه تیکه از آدم‌هایی که اینو می‌خونن. Anthropic هم‌زمان alignment رو سفت کرد و classifierهای cybersecurity رو خیلی شل کرد. classifierهای cyber مربوط به Opus 5 حدود ۸۵٪ کم‌محدودکننده‌تر از Fable 5 توصیف می‌شن. رو Frontier-Bench، classifierهای safety حدود ۵٪ از فراخوانی‌های API رو flag کردن، در مقابل ۴۲٪ برای Fable 5.

مشخصاً، پیدا کردن آسیب‌پذیری تو source code حالا آزاده، در حالی که binary scanning، penetration testing و تولید exploit محدود می‌مونن. اگه کار دفاعی مجاز می‌کنی، code review برای آسیب‌پذیری، تحلیل مثل CTF، نرخ false-positiveـی که Fable 5 رو برای این کار خسته‌کننده کرده بود خیلی پایین اومده. آزادی مطلق نیست، و نرده‌های تولید exploit هنوز سرجاشونن، ولی اصطکاک روزمره برای این‌که یه سوال امنیتی مشروع رو جواب بگیری خیلی کمتره.

و این کنار دستاوردهای alignment میاد، نه در تبادل باهاشون. مقاومت در برابر prompt injection بهتر شد (۲٫۰٪ موفقیت مهاجم رو benchmark مربوط به Gray Swan، پایین از ۵٫۵٪ رو Opus 4.8)، و Anthropic این رو هم‌راستاترین مدل تا الانش می‌نامه. refusal کمتر رو کار امنیتی مشروع و مقاومت injection بهتر تو یه release، ترکیب خوبیه که آدم ببینه.

من واقعاً باهاش چیکار می‌کنم

هیچ چیز دراماتیکی، و همینه نکته‌ش. migration یه عوض کردن اسم مدله به‌علاوه یه checklist کوتاه:

۱. string مدل رو به claude-opus-5 عوض کن. ۲. هر call site که هیچ‌وقت thinking رو ست نکرده بگرد. max_tokens رو بالا ببر، یا thinking: {type: "disabled"} پاس بده اگه رفتار قدیمی بدون thinking رو می‌خوام. این همونیه که وگرنه آروم چیزها رو می‌بُرید. ۳. هر route که thinking خاموش رو با effort xhigh یا max قاطی می‌کنه پیدا کن و درستش کن، چون حالا 400 می‌ده. ۴. prompt‌های verification و هر pass verifier تو harness رو پاک کن. ۵. effort رو دوباره sweep کن. پیش‌فرض xhigh-از-روی-رفلکس که از 4.8 با خودم کشیدم احتمالاً زیادی بالاست؛ low و medium رو Opus 5 قوی‌تر از چیزی‌ان که حقشونه. ۶. یه خط «کوتاه بنویس» جایی که طول output مهمه اضافه کن، چون مدل به‌صورت پیش‌فرض بلندتر اجرا می‌شه.

benchmarkها تیترن و واقعاً خوبن. ولی داستان برای هرکسی که رو این مدل چیز می‌سازه اینه که یه مشت پیش‌فرض جابه‌جا شدن، و جوری جابه‌جا شدن که error نمی‌دن، فقط آروم output یا صورت‌حسابت رو عوض می‌کنن. اینان که ارزش یه بعدازظهر رو دارن قبل از این‌که roll out کنی.

---

منابع: Introducing Claude Opus 5 (Anthropic، بیست‌وچهارم ژوئیه ۲۰۲۶). عددهای benchmark و جزئیات API با مستندات توسعه‌دهنده Anthropic و پوشش خبری launch تطبیق داده شدن؛ اعشار دقیق رو به‌عنوان گزارش‌شده برخورد کن، نه تأییدشده مستقل.