تا الان attribute #[Bind] فقط یه پارامتر environments برای شرطی کردن binding داشت. حالا #[BindWhen] یه closure میگیره که خود container رو دریافت میکنه، پس میتونی binding رو بر اساس config یا feature flag تصمیم بگیری:
use Illuminate\Container\Attributes\Bind;
use Illuminate\Container\Attributes\BindWhen;
#[BindWhen(BetaPaymentGateway::class, static function ($container) {
return $container->make('config')->get('features.payments.beta');
})]
#[Bind(FakePaymentGateway::class, environments: ['local', 'testing'])]
#[Bind(StripePaymentGateway::class)]
interface PaymentGatewayInterface {}
این attribute تکرارپذیره و شرط‌ها به ترتیب تعریف بررسی میشن، پس میشه چند تا شرط رو قبل از یه #[Bind] پیش‌فرض گذاشت. نکته‌ی مهم: چون از closure تو آرگومان attribute استفاده میکنه، به PHP 8.5 نیاز داره.
فیک کردن DNS lookup تو validation
قانون active_url و گزینه‌ی dns تو قانون ، واقعاً یه DNS query می‌زنن؛ یعنی هر تستی که این‌ها رو صدا بزنه، به شبکه وابسته میشه و ممکنه گاهی بی‌دلیل fail کنه. متد جدید این lookup رو دور می‌زنه ولی بقیه‌ی منطق validation دست‌نخورده میمونه:
publish کردن container حالا runtime های native پلتفرم رو ترجیح میده.
سی‌شارپ
از نظر زبانی، چهار تا ویژگی مهم اضافه شده:
break و continue با برچسب (labeled)؛ یعنی میشه مشخص کرد کدوم حلقه از چند تا حلقه‌ی تودرتو باید break یا continue بشه، بدون نیاز به flag های دستی.
الگوهای union (union pattern) حالا هم خود union و هم مقدار داخلیش رو match میکنن.
بهبود exhaustiveness checking برای type parameter هایی که به یه closed type محدود شدن.
تغییراتی تو «Unsafe Evolution»؛ شامل یه حالت سازگاری (compat mode) و رفتار nameof تو کد unsafe.
ASP.NET Core
بخش Blazor بیشترین تغییرات رو گرفته:
توقف خودکار circuit های Blazor موقع بی‌فعالیتی؛ که مصرف منابع سرور رو برای سشن‌های رهاشده کاهش میده.
یه ویژگی جدید به اسم CacheView برای کش کردن خروجی Blazor SSR.
چند تا analyzer جدید برای Blazor که مشکلات رایج رو زودتر گزارش میکنن.
QuickGrid حالا InitialItemIndex و ScrollToItemAsync رو پشتیبانی میکنه؛ یعنی کنترل بهتری رو موقعیت اسکرول و آیتم اولیه‌ی grid داری.
ابزار wasm-tools به Emscripten 6 آپدیت شده.
علاوه بر این، Razor حالا attribute های literal رو برای پارامترهای کامپوننت از نوع union قبول میکنه، validation localization به‌صورت built-in اضافه شده، کلاینت SignalR .NET حالا بعد از redirect هم میتونه auth رو refresh کنه، و OpenAPI پشتیبانی از Server-Sent Events تو نسخه‌ی OpenAPI 3.2 رو گرفته.
.NET MAUI
چند تا قابلیت جدید و کاربردی:
احراز هویت با passkey به‌صورت cross-platform؛ یعنی دیگه لازم نیست پیاده‌سازی جدا برای هر پلتفرم بنویسی.
XAML Incremental Hot Reload؛ که سرعت دیدن تغییرات UI موقع توسعه رو بهبود میده.
الگوهای route جدید برای Shell.
binding های RelativeSource که با AOT سازگارن.
پشتیبانی از backend های platform-specific شخص ثالث.
TabbedPage حالا رو پلتفرم‌های اپل از همون معماری handler استفاده میکنه که بقیه‌ی کنترل‌ها استفاده میکنن.
Entity Framework Core
بهبودهایی تو ترجمه‌ی کوئری LINQ، بهبود provider مربوط به Azure Cosmos DB، بهبود migration ها، و پشتیبانی از نوع Half رو SQLite اضافه شده.
اف‌شارپ
چهار تا بهبود کوچیک‌تر ولی مفید: binding های computation expression حالا داخل یه let ساده هم کار میکنن، attribute ها داخل ماژول‌ها و namespace های recursive درست resolve میشن، پیام تشخیصی واضح‌تری برای type abbreviation های generic اضافه شده، و یه باگ مربوط به محاسبه‌ی سایز StructLayout برای union های struct بدون داده رفع شده.
Windows Forms
تمرکز این بخش رو Dark Mode بوده؛ پنج تا pull request مستقیم به بهبود ظاهر تو حالت تاریک اختصاص داشته (شامل ToolTip، HelpProvider، LinkLabel، TabControl تودرتو، و آیکون‌های چک تو ToolStrip). علاوه بر این:
یه حالت اختیاری جدید به اسم VisualStylesMode برای شخصی‌سازی بیشتر ظاهر کنترل‌ها.
جلوگیری از فلاش سفید موقع باز شدن فرم‌ها تو dark mode، با تأخیر انداختن نمایش فرم تا زمانی که استایل‌ها اعمال بشن.
توقف رندر موقع تغییرات دسته‌ای (bulk) رو کنترل‌ها، مثل تغییر همزمان موقعیت و سایز.
ظاهر toggle-switch برای CheckBox و RadioButton.
رفع چند باگ پایداری، شامل یه کرش GDI+ تو SplitContainer و یه exception تو اسکرول ToolStrip.
این preview تو چه فضایی منتشر شده
نکته‌ی جالب اینه که واکنش جامعه‌ی توسعه‌دهنده‌ها به کل چرخه‌ی .NET 11 (نه فقط این preview) صرفاً مثبت نبوده. بعضی توسعه‌دهنده‌ها نسبت به افزایش پیچیدگی زبان سی‌شارپ و سرعت انتشار نسخه‌های بزرگ ابراز نگرانی کردن. همچنین، نقشه‌ی راه ASP.NET Core تو .NET 11 تمرکز زیادی رو «Agentic AI» گذاشته (از جمله پشتیبانی از Model Context Protocol تا اپلیکیشن‌های .NET بتونن به‌عنوان ابزار برای agent های هوش مصنوعی عمل کنن)؛ جهتی که بعضی توسعه‌دهنده‌ها معتقدن داره روی نیازهای اصلی و پایه‌ای framework سایه می‌ندازه.
چطور امتحانش کنیم
برای شروع، کافیه SDK نسخه‌ی .NET 11 رو نصب کنی. اگه رو ویندوز با Visual Studio کار میکنی، مایکروسافت توصیه میکنه از آخرین نسخه‌ی Visual Studio 2026 Insiders استفاده کنی؛ از Visual Studio Code هم با extension مربوط به C# Dev Kit میشه استفاده کرد. یادت باشه این هنوز preview است، نه نسخه‌ی نهایی، پس برای production حتماً صبر کن تا نسخه‌ی پایدار نوامبر منتشر بشه؛ ولی برای آشنایی زودهنگام با تغییرات و کاهش ریسک آپدیت آینده، امتحانش کردنش الان ارزش داره.
همین تأخیر تو انتشار وزن‌ها یعنی فعلاً هیچ بنچمارک یا تست مستقلی از سمت جامعه‌ی خارج از Zhipu وجود نداره؛ تمام اعداد و ادعاهای بالا (بهبود ۵۰ درصدی، رتبه‌ی اول بین مدل‌های متن‌باز) صرفاً بر اساس ارزیابی‌های داخلی خود شرکته و باید تا انتشار واقعی وزن‌ها، با احتیاط بهشون نگاه کرد.
دسترسی برای کاربران فعلی
همزمان با انتشار، Zhipu اعلام کرد که quota مصرف همه‌ی کاربران GLM Coding Plan، ساعت ۱۳:۰۰ همون روز ریست شده و کاربرها می‌تونن سهمیه‌ی جدیدشون رو تو بخش «Usage Statistics» ببینن.
جمع‌بندی
اگه قبلاً از GLM-5.2 برای کارهای کدنویسی استفاده می‌کردی، GLM-5.3 همین الان از طریق GLM Coding Plan در دسترسه و طبق ادعای شرکت، جهش محسوسی تو agent-based task ها داره. ولی اگه دنبال self-host کردن یا استفاده‌ی offline از این مدل هستی، باید حدود دو هفته صبر کنی تا وزن‌ها منتشر بشن؛ و بعد از انتشارشون هم ارزش داره منتظر بنچمارک‌های مستقل بمونی تا ببینی ادعاهای Zhipu چقدر تو عمل هم صدق میکنه.
email
Validator::fakeDnsLookups()
protected function setUp(): void
{
parent::setUp();
Validator::fakeDnsLookups();
}
پشتیبانی #[Delay] تو batch و bulk dispatch
جاب‌هایی که با attribute #[Delay] تأخیرشون رو مشخص میکردن، وقتی جدا dispatch می‌شدن درست کار میکردن، ولی Bus::batch() و Queue::bulk() فقط پراپرتی $delay رو می‌خوندن و این attribute رو نادیده می‌گرفتن. حالا هر دو مسیر یکسان رفتار میکنن.
حالا میشه چند تا اسم صف رو با کاما جدا کرد، دقیقاً همون رفتاری که تو queue:work و queue:listen از قبل بود.
Laravel 13.23 (27 جولای 2026)
درایور لاگ ماهانه
درایور daily برای اپ‌هایی که لاگ زیاد تولید میکنن مناسبه؛ ولی اپ‌های کوچیک‌تر با یه پوشه پر از فایل‌های تقریباً خالی مواجه می‌شدن. درایور جدید monthly دقیقاً بین single و daily قرار میگیره و یه فایل به ازای هر ماه تقویمی میسازه:
پیش‌فرض نگهداری برای daily هنوز ۱۴ فایله، ولی برای monthly فقط ۳ فایل.
پشتیبانی از SES tenant تو SES v2
اگه از Amazon SES tenants استفاده میکنی (که reputation و تنظیمات رو بین گروه‌های مختلف فرستنده ایزوله میکنه)، حالا میشه هدر X-SES-TENANT-NAME رو مستقیم از خود mailable ست کرد:
public function headers(): Headers
{
return new Headers(text: ['X-SES-TENANT-NAME' => 'tenant-id']);
}
کلوز ->using() برای تغییر ستون تو PostgreSQL
PostgreSQL بدون یه cast صریح، از تغییر نوع یه ستون به یه نوع ناسازگار امتناع میکنه. حالا میشه این cast رو مستقیم تو migration مشخص کرد:
Schema::table('currency_rates', function (Blueprint $table) {
$table->date('name')->using('name::date')->change();
});
این کلوز فقط برای PostgreSQL اعمال میشه؛ بقیه‌ی grammar ها نادیده‌اش می‌گیرن.
مقایسه‌ی timing-safe برای secret بای‌پس maintenance mode
مقایسه‌ی secret تو middleware و بوت‌استرپ maintenance mode از === به hash_equals() تغییر کرد؛ یه بهبود دفاع‌در-عمق، نه رفع یه باگ عملاً قابل سوءاستفاده.
Laravel 13.24 (4 آگوست 2026)
تشخیص رنگ غالب تصویر و پشتیبانی از HEIC
API تصویرسازی لاراول حالا میتونه رنگ غالب یه تصویر رو تشخیص بده، و از این رنگ به‌عنوان پس‌زمینه‌ی پیش‌فرض تو متدهای contain() و rotate() استفاده میکنه. علاوه بر این، ورودی AVIF و HEIC، خروجی toHeic()، و پشتیبانی از هر دو فرمت تو قانون validation تصویر هم اضافه شده.
متد modelKeys() روی Eloquent query builder
یه متد کمکی جدید برای گرفتن سریع کلیدهای مدل از یه کوئری، بدون نیاز به pluck('id') دستی.
قانون validation جدید array_keys
یه قانون جدید که کلیدهای غیرمنتظره‌ی یه آرایه رو رد میکنه، همراه با یه placeholder به اسم :unexpected تو پیام خطا.
رفع باگ کندی validation روی wildcard
قانون‌های تو دل الگوهای foo.*.bar تو آرایه‌های بزرگ، یه رفتار expansion درجه‌دومی (quadratic) داشتن که می‌تونست یه request رو بیش از یک دقیقه معطل کنه. این باگ حالا رفع شده.
Laravel 13.25 (11 آگوست 2026)
توقف همه‌ی صف‌ها با یه دستور
قبلاً باید هر صف رو جدا-جدا و بر اساس نام pause می‌کردی، که تو یه دیپلوی با دوجین worker پخش‌شده رو صف‌های مختلف، کار خسته‌کننده‌ای بود. حالا هر دو دستور یه فلگ --all می‌گیرن:
use Illuminate\Support\Facades\Queue;
Queue::pauseAll();
Queue::resumeAll();
این سوییچ سراسری کاملاً مستقل از pause های تکی عمل میکنه؛ یعنی resumeAll() فقط فلگ سراسری رو پاک میکنه و صف‌هایی که جدا pause کرده بودی، pause شده باقی می‌مونن. این طراحی عمدیه تا یه اسکریپت دیپلوی به‌طور تصادفی صفی که یکی عمداً نگه داشته رو دوباره فعال نکنه.
artisan dev با یه رابط ترمینال جدید
قبلاً artisan dev از پکیج concurrently استفاده میکرد که همه‌ی پردازش‌ها رو تو یه فید مشترک قاطی میکرد. حالا از یه رابط جدید به اسم @laravel/multiplex استفاده میکنه که هر پردازش تب جدا خودش رو داره، امکان جست‌وجو، ری‌استارت جدا، و ری‌استارت خودکار در صورت کرش رو میده:
php artisan dev --stream
php artisan dev --timestamps --no-restart
توجه داشته باش که این ویژگی فعلاً فقط رو مک و لینوکس کار میکنه (ویندوز به همون concurrently قدیمی برمیگرده) و حداقل نسخه‌ی Node.js لازم برای این مسیر جدید، نسخه‌ی ۲۲.۱۳ است.
برگردوندن مستقیم Image از یه route
کلاس Image حالا اینترفیس Responsable رو پیاده‌سازی میکنه، پس میشه مستقیم از یه route برگردوندش:
هدر Content-Type هم متناسب با فرمت خروجی pipeline تنظیم میشه، نه فرمت فایل اصلی. علاوه بر این، Image::fromStream() هم اضافه شده که یه instance رو مستقیم از یه stream resource میسازه.
withoutCookies() روی response ها
به‌جای زنجیره کردن withoutCookie() برای هر کوکی جدا، حالا یه فرم جمع هم هست:
قبلاً وقتی یه فیلد input و یه فایل آپلودی هم‌نام بودن، آرایه‌ی نهایی، شیء UploadedFile رو نگه می‌داشت. حالا این ترتیب برعکس شده و مقدار input برنده میشه؛ file() تحت تأثیر این تغییر قرار نمی‌گیره.
جمع‌بندی
اگه بخوایم این چهار نسخه رو تو یه جمله خلاصه کنیم: تمرکز اصلی روی صف‌ها (پشتیبانی کامل‌تر از #[Delay]، pause سراسری، رویدادهای observability بیشتر)، بهبودهای مربوط به تصویر (HEIC، رنگ غالب، برگردوندن مستقیم از route)، و صیقل دادن تجربه‌ی توسعه‌دهنده با artisan dev بوده. هیچ‌کدوم از این چهار نسخه breaking change جدی برای اپلیکیشن‌های معمولی نداشتن، پس آپدیت کردن نسبتاً بی‌دردسره؛ فقط اگه از #[BindWhen] استفاده میکنی، حواست به نیاز PHP 8.5 باشه.
نکته‌ی امنیتی
طبق اعلام گوگل، این مدل با guardrail های به‌روزشده برای جلوگیری از سوءاستفاده تو حوزه‌های شیمیایی، بیولوژیک، رادیولوژیک و هسته‌ای (CBRN) و حملات سایبری عرضه شده، همزمان با تلاش برای حفظ کاربردهای مفید و مجاز تو همین حوزه‌ها.
چرا این سرعت انتشار مهمه
نکته‌ای که تقریباً همه‌ی گزارش‌ها روش تأکید کردن، فاصله‌ی فقط سه‌هفته‌ای بین این نسخه و نسخه‌ی قبلیه؛ یه سرعتی که برای مدل‌های سطح enterprise غیرمعموله. در همین حال، مدل پرچمدار و بلندمدت‌منتظر گوگل، Gemini 3.5 Pro، همچنان تأخیر داره و گوگل هیچ تاریخ مشخصی براش اعلام نکرده. این انتشار سریع Flash، همزمان با رقابت شدید قیمتی و رقابت مدل‌های جدید از سمت اوپن‌ای‌آی، آنتروپیک، دیپ‌سیک و xAI اتفاق افتاده؛ چیزی که این روزها به‌عنوان یه «جنگ قیمتی» بین لب‌های بزرگ هوش مصنوعی توصیف میشه.
این پروژه رو کی هدایت میکنه
رهبری تیم Harness رو Cui Tianyi برعهده داره؛ کسی که مارس ۲۰۲۶ بعد از یه دوره کار تو Jane Street (شرکت معاملاتی کوانتیتیتیو معروف به جذب نیروهای فنی قوی از وال‌استریت) به دیپ‌سیک پیوست. تیم Harness از می ۲۰۲۶ کار جذب نیرو رو شروع کرد و تا اوایل آگوست به مرحله‌ی beta testing با توسعه‌دهنده‌های متن‌باز رسید؛ یعنی از اعلام اولیه تا انتشار عمومی، کمتر از سه ماه طول کشیده.
وضعیت فعلی: هنوز preview است
نکته‌ی مهمی که باید بهش توجه کرد، اینه که این نسخه (v0.1) صراحتاً یه developer preview است، نه یه نسخه‌ی پایدار برای production. طبق مستندات رسمی، پکیج ریشه هنوز عدد نسخه‌ی 0.1.0-rc.5 رو گزارش میده، مستندات به‌سرعت در حال تغییرن، و خود ریپازیتوری هم کاربران رو برای گزارش باگ به بخش Discussions هدایت میکنه، نه Issues. یعنی API ها و قراردادهای پلاگین ممکنه قبل از نسخه‌ی پایدار تغییر کنن.
برای شروع کار باهاش، کافیه دستور npx @deepseek-ai/dsh web رو تو ترمینال (با Node.js نصب‌شده) اجرا کنی؛ این دستور یه رابط وب رو رو آدرس http://127.0.0.1:3080 بالا میاره که ازش میشه کلید API مدل دلخواه رو تنظیم کرد.
جمع‌بندی
اگه داری زیرساخت agent میسازی یا دنبال یه جایگزین قابل self-host و کاملاً متن‌باز برای Claude Code هستی، ارزش امتحان کردن Harness رو داره؛ ترکیب یه معماری پلاگین‌محور شفاف، لایسنس کاملاً باز، و پشتوانه‌ی یه لب بزرگ مثل دیپ‌سیک، این پروژه رو به یکی از جدی‌ترین بازیگرهای این حوزه تبدیل کرده. ولی اگه دنبال یه ابزار پایدار برای کار تیمی روزمره‌ای، بهتره فعلاً صبر کنی تا از مرحله‌ی preview خارج بشه، چون تغییرات سریع تو API فعلیش میتونه هزینه‌ی نگهداری غیرمنتظره‌ای برات ایجاد کنه.
نسخه‌ی مک و ویندوز این اپ از جولای، همزمان با معرفی ChatGPT Work، در دسترس بود. اوپن‌ای‌آی تو اعلامیه‌ش گفته لینوکس یکی از پرتقاضاترین پلتفرم‌ها برای این اپ بوده و با این انتشار، ChatGPT و Codex حالا رو تمام سیستم‌عامل‌های دسکتاپ اصلی در دسترس هستن. جالبه که آنتروپیک تقریباً یه ماه زودتر از اوپن‌ای‌آی، اپ دسکتاپ Claude رو برای لینوکس منتشر کرده بود (که رو Ubuntu 22.04 به بعد و Debian 12 به بعد کار میکنه)، پس اوپن‌ای‌آی تو این مسیر یه‌کم عقب‌تر حرکت کرده.
نکاتی که قبل از نصب باید بدونی
چون این اپ هنوز تو مرحله‌ی preview عمومیه، احتمال باگ و مشکلات یکپارچگی وجود داره، پس برای کارهای حیاتی روش حساب باز نکن. اپ به‌صورت رایگان قابل دانلود و استفاده‌ست (با یه اکانت رایگان اوپن‌ای‌آی)، ولی طبیعتاً بعضی از قابلیت‌هاش نیاز به پلن پولی داره. یه نکته‌ی دیگه هم اینه که این اپ کلوزسورسه، برخلاف بعضی از client های غیررسمی که تو گیت‌هاب پیدا میکنی.
اگه میخوای امتحانش کنی، از صفحه‌ی openai.com/codex قابل دانلوده.
شرکت‌هایی که فعلاً به این مدل دسترسی دارن شامل چند تا از بزرگ‌ترین بازیگرهای حوزه‌ی مشاوره و امنیته: Accenture، IBM، Capgemini، Cognizant، EY، KPMG، PwC، NCC Group و SpecterOps، به‌علاوه‌ی چند تا فروشنده‌ی امنیتی مثل Palo Alto Networks، CrowdStrike، Cisco، Sophos، Akamai، Fortinet و کلادفلر. طبق اعلام اوپن‌ای‌آی، این شرکا قراره مدل رو داخل محصولات امنیتی موجود، سرویس‌های مدیریت‌شده، و کار مستقیم با مشتری‌ها ادغام کنن، نه اینکه مستقیم در اختیار کاربر نهایی بذارنش.
برای گرفتن دسترسی به هر کدوم از این سطوح هم، فرآیندی شامل تأیید هویت، اقدامات امنیتی حساب، مانیتورینگ مداوم، و اعلامیه‌های قانونی لازمه؛ حتی استفاده از کلید امنیتی سخت‌افزاری هم بخشی از این الزامات شده.
قیمت‌گذاری
طبق مستندات اوپن‌ای‌آی، GPT-5.6-Cyber قیمتش حدود ۱۲.۵۰ دلار به ازای هر میلیون توکن ورودی و ۷۵ دلار به ازای هر میلیون توکن خروجیه (با نرخ ۱.۲۵ دلار برای input کش‌شده)؛ که به‌طور محسوسی گرون‌تر از GPT-5.6 Sol تو همون جدول قیمت‌گذاری Daybreakه (۵ دلار ورودی، ۳۰ دلار خروجی برای context کوتاه).
چرا اوپن‌ای‌آی الان این کار رو کرده
طبق اعلام اوپن‌ای‌آی، دلیل اصلی این تصمیم اینه که مهاجمان به‌طور فزاینده‌ای از هوش مصنوعی برای حملات سایبری استفاده میکنن، حتی حملات کاملاً خودکار، و پنجره‌ی زمانی که مدافعان برای آماده شدن دارن داره کوچیک‌تر میشه. برنامه‌ی Daybreak دقیقاً برای این طراحی شده که به تیم‌های دفاعی همون سطح از قابلیت رو زودتر بده تا بتونن آسیب‌پذیری‌ها رو قبل از مهاجمان پیدا کنن.
یه نکته‌ی جالب اینه که این معرفی فقط چند روز بعد از این اتفاق افتاد که اوپن‌ای‌آی اعلام کرد انتشار مدل بعدیش (با نام کد Astra) رو به تعویق انداخته، چون تو تست‌های امنیتی به سطح خطرناکی از توانایی هک رسیده بود. طبق طبقه‌بندی Preparedness Framework خود اوپن‌ای‌آی، GPT-5.6-Cyber فقط به سطح «High» رسیده (نه سطح بحرانی که باعث تعویق Astra شد)، که نشون میده اوپن‌ای‌آی سعی داره بین دادن ابزار به مدافعان و کنترل ریسک انتشار عمومی، یه مرز مشخص بکشه.
یه نکته‌ی عملی هم برای کیف پول‌ها: خود مصرف توکن اضافه‌ای که classifier برای بررسی هر tool call مصرف میکنه، از این به بعد جزو usage limit پلن‌های Pro، Max و Team حساب نمی‌شه.
این یعنی چی برای کار روزمره
اگه از Claude Code برای کارهای طولانی و چندمرحله‌ای استفاده میکنی (مثلاً یه refactor بزرگ یا یه feature کامل)، این تغییر میتونه یعنی دیگه لازم نیست کنار ترمینال بشینی و هر چند ثانیه یه دکمه بزنی؛ میتونی چند تا task رو موازی شروع کنی و بعداً برگردی سراغ pull request های آماده. ولی اگه از اون دسته‌ای هستی که ترجیح می‌دی هر دستور رو دستی چک کنی (مخصوصاً روی پروژه‌های حساس یا production)، بهتره قبل از ۱۴ آگوست تنظیماتت رو چک کنی و mode دلخواهت رو صراحتاً پین کنی، چون در غیر این صورت این تغییر بی‌سروصدا برات اعمال میشه.
چرا این تغییر الان اتفاق افتاده
محدودیت نرخ پیام برای کاربران رایگان، سال‌ها یکی از اصلی‌ترین دلایلی بود که کاربران معمولی رو به سمت خرید اشتراک Plus سوق می‌داد. برداشتن این محدودیت برای متن، به‌طور مستقیم همون اصطکاکی رو کم میکنه که کاربران سنگین رایگان باهاش مواجه بودن. با توجه به اینکه چت متنی ساده، بخش اصلی استفاده‌ی اکثر کاربران ChatGPT رو تشکیل میده، این تصمیم میتونه باعث بشه کاربران بیشتری، بدون نیاز به خرید اشتراک، درگیر پلتفرم بمونن.
Build سریع‌تر
Type checking سریع‌تر
SSR سریع‌تر
درخواست‌های کمتر برای Prefetch
Cache بهتر برای فایل‌های استاتیک
یعنی حتی اگر هیچ‌کدام از قابلیت‌های جدید را استفاده نکنی، باز هم احتمالاً تفاوت را حس میکنی.
Turbopack حالا تا ۹۰٪ حافظه‌ی کمتری مصرف می‌کند
یکی از بزرگ‌ترین تغییرات Next.js 16.3 مربوط به Turbopack است.
تا قبل از این نسخه، یکی از شکایت‌های رایج درباره‌ی dev server پروژه‌های بزرگ، مصرف بالای حافظه بود.
روی یک پروژه‌ی کوچک شاید متوجه نشوی، اما وقتی پروژه چند صد Route، تعداد زیادی dependency و فایل‌های زیاد دارد، مصرف RAM می‌تواند خیلی سریع بالا برود.
در Next.js 16.3 دو قابلیت مهم به‌صورت پیش‌فرض فعال شده‌اند:
Disk Cache برای توسعه
Memory Eviction
ترکیب این دو باعث شده Turbopack بتواند بهتر تصمیم بگیرد چه چیزهایی را در حافظه نگه دارد و چه چیزهایی را از RAM خارج کند.
البته مثل همیشه این عددها را نباید کورکورانه برای همه‌ی پروژه‌ها انتظار داشت. نوع پروژه، تعداد Routeها، dependencyها و نحوه‌ی استفاده از Server Componentها تأثیر زیادی دارند.
اما جهت تغییر مشخص است: Turbopack دیگر فقط دنبال سریع‌تر شدن نیست، بلکه می‌خواهد در پروژه‌های واقعی منابع کمتری مصرف کند.
به نظر من این یکی از آن تغییراتی است که توسعه‌دهنده‌هایی که لپ‌تاپ معمولی دارند بیشتر از همه حسش می‌کنند.
چون سریع بودن فقط این نیست که یک build چند ثانیه زودتر تمام شود؛ اگر سیستم وسط کار شروع کند به swap کردن و کند شدن، آن سرعت روی کاغذ چندان کاربردی نیست.
Buildهای سریع‌تر با FileSystem Cache
همان Cacheای که از Next.js 16.1 برای dev معرفی شده بود، حالا وارد مرحله‌ی بعدی شده و برای next build هم فعال شده است.
ایده ساده است:
اگر قبلاً چیزی محاسبه شده و هنوز معتبر است، دوباره از صفر انجامش نده.
این موضوع مخصوصاً در CI مهم است.
در پروژه‌هایی که مرتب build می‌شوند، زمان زیادی صرف کارهای تکراری می‌شود. حالا Turbopack می‌تواند بخشی از این خروجی‌ها را ذخیره کند و در buildهای بعدی دوباره استفاده کند.
طبق تست‌های تیم Next.js، بعضی پروژه‌ها در CI تا ۵.۵ برابر build سریع‌تر داشته‌اند.
این تغییر برای تیم‌هایی که روزانه چندین deploy انجام می‌دهند، شاید از هر قابلیت ظاهری دیگری مهم‌تر باشد.
چون چند ثانیه در یک build شاید مهم نباشد، اما وقتی صدها بار تکرار می‌شود، تبدیل به زمان واقعی تیم می‌شود.
TypeScript 7 و Type Checking سریع‌تر
Next.js 16.3 همزمان با نسل جدید TypeScript آمده است.
TypeScript 7 یک تغییر مهم دارد: بخش‌هایی از آن با یک پیاده‌سازی Native بازنویسی شده که هدفش سرعت بالاتر در type checking است.
طبق اعلام تیم TypeScript، این نسخه می‌تواند در بعضی سناریوها چند برابر سریع‌تر باشد.
برای استفاده از آن در پروژه‌ی Next.js کافی است نسخه‌ی dependency را تغییر بدهی:
npm i -D typescript@^7
البته اینجا یک نکته وجود دارد.
سرعت بالاتر همیشه به معنی این نیست که همه‌ی پروژه‌ها دقیقاً همان نتیجه را می‌بینند. پروژه‌هایی با Type پیچیده، monorepoها یا dependencyهای سنگین ممکن است تفاوت بیشتری حس کنند.
اما برای پروژه‌هایی که TypeScript بخش بزرگی از زمان build را می‌گیرد، این تغییر ارزش بررسی دارد.
رندر سمت سرور سریع‌تر با Native Node.js Streams
یکی از تغییرات فنی جالب Next.js 16.3 در لایه‌ی رندرینگ App Router اتفاق افتاده است.
برای اینکه مرورگر بتواند محتوا را به‌صورت تدریجی دریافت کند، Next.js از Streamها استفاده می‌کند. این مدل باعث می‌شود لازم نباشد کاربر تا آماده شدن کل صفحه صبر کند و بخش‌های آماده‌شده زودتر ارسال شوند.
اما یک مشکل وجود داشت.
در محیط Node.js، Streamهای داخلی Node با Web Streams که در استانداردهای جدید وب استفاده می‌شوند، یکسان نیستند. در نتیجه بخشی از زمان و منابع صرف تبدیل بین این دو مدل میشد.
در Next.js 16.3 این مسیر تغییر کرده و در لایه‌ی رندرینگ App Router از Native Node.js Streams استفاده می‌شود.
نتیجه؟
کاهش overhead در SSR.
طبق بنچمارک‌های تیم Next.js، اپلیکیشن‌ها در شرایط بار بالا می‌توانند تا ۲۲٪ درخواست بیشتری را با همان شرایط پردازش کنند.
یعنی:
وضعیت
عنوان
توضیح
قبل
Web Streams
Baseline
بعد
Native Node.js Streams
+22% Requests
این تغییر شاید چیزی نباشد که هنگام توسعه‌ی روزمره فوراً ببینی، اما روی سرویس‌هایی که ترافیک بالا دارند، تفاوتش خودش را نشان می‌دهد.
این هم از آن دسته تغییراتی است که معمولاً کاربران متوجه وجودش نمی‌شوند؛ فقط متوجه می‌شوند سایت در فشار بالا بهتر دوام می‌آورد.
مستندات نسخه‌بندی‌شده برای AI Agentها
یکی از مسیرهایی که Next.js در نسخه‌های جدید جدی‌تر دنبال می‌کند، آماده کردن پروژه‌ها برای ابزارهای هوش مصنوعی است.
چند سال پیش اگر کسی می‌گفت فریمورک باید برای AI Agentها بهینه شود، احتمالاً خیلی‌ها تصور می‌کردند منظور فقط autocomplete داخل ادیتور است.
اما الان موضوع بزرگ‌تر شده.
Agentها قرار است کد بخوانند، تغییر بدهند، تست اجرا کنند و حتی تصمیم‌های معماری پیشنهاد کنند.
مشکل اینجاست که یک Agent بدون اطلاعات کافی درباره‌ی پروژه، ممکن است تصمیم‌هایی بگیرد که با ساختار پروژه هماهنگ نیست.
مثلاً:
از API اشتباه استفاده کند.
الگوی قدیمی پروژه را نادیده بگیرد.
قوانین داخلی تیم را رعایت نکند.
Next.js 16.3 با اضافه کردن پشتیبانی بهتر برای Versioned Docs این مسیر را ساده‌تر می‌کند.
ایده این است که Agent بتواند به اطلاعات دقیق‌تر و هماهنگ با نسخه‌ی مورد استفاده‌ی پروژه دسترسی داشته باشد.
یعنی اگر پروژه روی Next.js 16.3 است، Agent لازم نیست از اطلاعات مربوط به نسخه‌های قدیمی‌تر استفاده کند.
این تغییر شاید امروز برای همه ضروری نباشد، اما اگر با ابزارهایی مثل Cursor، Claude Code یا Agentهای مشابه کار میکنی، اهمیتش بیشتر می‌شود.
درخواست‌های Prefetch کمتر، کنترل بهتر روی شبکه
یکی از بخش‌هایی که در Next.js همیشه بین سرعت و مصرف منابع تعادل ایجاد میکرد، Prefetch بود.
Prefetch یعنی قبل از اینکه کاربر روی یک لینک کلیک کند، Next.js حدس بزند که احتمالاً کاربر به آن صفحه می‌رود و بخشی از اطلاعات را از قبل دریافت کند.
این کار باعث Navigation سریع‌تر می‌شود.
اما یک مشکل دارد.
اگر تعداد لینک‌ها زیاد باشد، ممکن است درخواست‌های زیادی ایجاد شود؛ حتی برای صفحاتی که کاربر هیچ‌وقت باز نمی‌کند.
در Next.js 16.3 رفتار Prefetch بهینه‌تر شده تا درخواست‌های غیرضروری کمتر شوند.
هدف این نیست که Prefetch حذف شود؛ چون هنوز یکی از دلایل اصلی حس سریع بودن Next.js است.
هدف این است که هوشمندتر عمل کند.
یعنی:
اطلاعات مهم زودتر آماده شوند.
درخواست‌های بی‌مصرف کمتر شوند.
فشار روی سرور و شبکه کاهش پیدا کند.
Cache بهتر برای Static Assetها
فایل‌های استاتیک مثل:
تصویرها
فایل‌های CSS
JavaScript bundleها
فونت‌ها
معمولاً باید مدت زیادی Cache شوند.
اما تنظیمات اشتباه Cache می‌تواند مشکل‌ساز شود.
اگر خیلی کوتاه باشد، کاربر مدام فایل‌های تکراری دانلود می‌کند.
اگر خیلی طولانی باشد، ممکن است نسخه‌ی قدیمی فایل نمایش داده شود.
Next.js 16.3 در این بخش رفتار Cache فایل‌های استاتیک را بهتر کرده تا استفاده از منابع شبکه منطقی‌تر شود.
این تغییر شاید در پروژه‌های کوچک دیده نشود، اما در سایت‌هایی که حجم زیادی Asset دارند، می‌تواند روی سرعت واقعی کاربران تأثیر بگذارد.
Custom Error Boundaries
مدیریت خطا در اپلیکیشن‌های بزرگ همیشه یک بخش مهم بوده است.
وقتی یک صفحه یا یک بخش از UI خراب می‌شود، اینکه کل برنامه از کار بیفتد تجربه‌ی خوبی نیست.
React و Next.js مدت‌ها امکان Error Boundary داشتند، اما Next.js 16.3 کنترل‌های بیشتری برای ساخت تجربه‌ی خطای بهتر ارائه می‌دهد.
هدف این است که بتوانی به جای نمایش یک صفحه‌ی خطای عمومی، رفتار دقیق‌تری برای بخش‌های مختلف برنامه داشته باشی.
مثلاً:
یک بخش از داشبورد خراب شود.
اما منوی اصلی همچنان کار کند.
کاربر بتواند دوباره تلاش کند.
این مدل در اپلیکیشن‌های بزرگ اهمیت زیادی دارد.
Built-in Glob Imports؛ وارد کردن فایل‌ها ساده‌تر می‌شود
یکی دیگر از تغییرات کوچک اما کاربردی، اضافه شدن قابلیت Glob Import داخلی است.
گاهی در پروژه‌ها لازم است تعداد زیادی فایل را بر اساس یک الگو وارد کنی.
مثلاً:
همه‌ی فایل‌های Markdown یک پوشه
همه‌ی کامپوننت‌های یک مسیر
همه‌ی فایل‌های ترجمه
قبلاً معمولاً برای این کار سراغ ابزارهای جانبی می‌رفتیم.
حالا Next.js پشتیبانی بهتری برای این سناریوها فراهم کرده است.
این قابلیت شاید به تنهایی دلیل آپدیت نباشد، اما در پروژه‌های Content-heavy یا سیستم‌های بزرگ مدیریت فایل، کار را راحت‌تر می‌کند.
Instant Navigation؛ نزدیک‌تر شدن Next.js به حس SPA
تا اینجا بیشتر درباره‌ی تغییرات زیرساختی صحبت کردیم.
اما بخشی که احتمالاً کاربران نهایی بیشتر حس می‌کنند، Navigation جدید است.
یکی از چالش‌های همیشگی Next.js این بوده:
چطور سرعت SPA را داشته باشیم، بدون اینکه مزیت‌های Server Components و Server Rendering را از دست بدهیم؟
Next.js 16.3 تلاش می‌کند این فاصله را کمتر کند.
Partial Prefetching
در نسخه‌های قبلی، Prefetch همیشه یک تعادل سخت داشت.
اگر زیاد Prefetch کنی:
درخواست زیاد می‌شود.
داده‌ی اضافی مصرف می‌شود.
اگر کم Prefetch کنی:
Navigation کندتر حس می‌شود.
Partial Prefetching راه وسط است.
به جای اینکه کل Route را از قبل آماده کند، فقط بخش‌هایی که برای شروع Navigation لازم هستند را دریافت می‌کند.
مثلاً Shell صفحه سریع آماده می‌شود و بخش‌های سنگین‌تر بعداً می‌رسند.
نتیجه چیزی شبیه اپلیکیشن‌های SPA است، اما با معماری Server-Driven.
Instant Insights؛ فهمیدن اینکه Navigation واقعاً چه اتفاقی می‌افتد
یکی از مشکلات توسعه‌دهنده‌ها با اپلیکیشن‌های مدرن این است که وقتی یک صفحه کند باز می‌شود، همیشه مشخص نیست مشکل دقیقاً کجاست.
آیا مشکل از:
دریافت داده از API است؟
Server Component زمان زیادی می‌برد؟
Bundle سمت کلاینت بزرگ است؟
Prefetch درست انجام نشده؟
Cache کار نکرده؟
در Next.js 16.3 ابزارهای بهتری برای مشاهده‌ی رفتار Navigation اضافه شده تا توسعه‌دهنده بتواند دقیق‌تر بفهمد هنگام جابه‌جایی بین صفحات چه اتفاقی می‌افتد.
این همان چیزی است که در پروژه‌های بزرگ اهمیت پیدا می‌کند.
در پروژه‌ی کوچک شاید بگویی:
«این صفحه فقط یک ثانیه دیرتر باز می‌شود.»
اما در یک محصول واقعی، همین یک ثانیه می‌تواند نتیجه‌ی چندین مشکل کوچک باشد که پیدا کردنشان بدون ابزار مناسب سخت است.
وقتی یک کاربر روی یک لینک کلیک می‌کند، اتفاقات زیادی پشت صحنه رخ می‌دهد.
Next.js باید:
Route را پیدا کند.
داده‌های لازم را آماده کند.
Cache را بررسی کند.
Server Componentها را پردازش کند.
نتیجه را به کلاینت برساند.
Navigation Inspector کمک می‌کند این مسیر واضح‌تر دیده شود.
این ابزار مخصوصاً برای زمانی کاربردی است که احساس میکنی یک Route باید سریع باشد، اما در عمل نیست.
به جای حدس زدن، می‌توانی ببینی زمان دقیق کجا مصرف شده.
این تغییر شاید برای همه‌ی توسعه‌دهنده‌ها روزانه استفاده نشود، اما برای Debug کردن پروژه‌های بزرگ ارزش زیادی دارد.
بهبود Incremental Static Regeneration (ISR)
ISR یکی از قابلیت‌هایی است که باعث شد Next.js در سال‌های اخیر بین سایت‌های محتوایی و اپلیکیشن‌های ترکیبی محبوب شود.
ایده ساده است:
صفحه را Static تولید کن، اما اجازه بده بعداً بدون Build کامل به‌روزرسانی شود.
مشکل همیشه این بوده که Cache و Revalidation در پروژه‌های بزرگ می‌تواند پیچیده شود.
Next.js 16.3 روی رفتار ISR هم بهبودهایی آورده تا مدیریت این سناریوها قابل پیش‌بینی‌تر شود.
این موضوع مخصوصاً برای سایت‌هایی که:
محتوای زیاد دارند.
تغییرات مداوم دارند.
ولی نمی‌خواهند هر تغییر باعث Build کامل شود.
مهم است.
تست راحت‌تر با Playwright Test Helper
تست کردن Navigation و رفتارهای سمت سرور همیشه کمی سخت‌تر از تست کردن کامپوننت‌های ساده بوده است.
چون باید رفتار واقعی مرورگر، شبکه، Route و Rendering را هم در نظر بگیری.
Next.js 16.3 یک helper جدید برای Playwright ارائه کرده تا نوشتن تست‌های مرتبط با اپلیکیشن‌های Next.js راحت‌تر شود.
این یعنی تست کردن مواردی مثل:
Navigation
Loading State
Error State
رفتارهای App Router
کمتر نیاز به کد تکراری دارد.
برای تیم‌هایی که تست E2E جدی دارند، این تغییر کوچک نیست.
بهبودهای AI؛ Next.js برای دوره‌ی Agentها آماده‌تر می‌شود
اگر بخش‌های مختلف Next.js 16.3 را کنار هم بگذاری، یکی از پیام‌های واضح این نسخه این است:
فریمورک‌ها دیگر فقط برای انسان‌ها نوشته نمی‌شوند.
بخش زیادی از کدنویسی آینده احتمالاً با کمک Agentها انجام می‌شود.
اما یک Agent خوب فقط با داشتن یک مدل زبانی ساخته نمی‌شود.
باید:
ساختار پروژه را بفهمد.
قوانین تیم را بداند.
بداند از چه الگوهایی استفاده کند.
بداند کدام API مربوط به کدام نسخه است.
برای همین Next.js روی چند بخش کار کرده است.
AGENTS.md؛ قراردادن قوانین پروژه برای Agentها
اگر با ابزارهای AI کار کرده باشی، احتمالاً این مشکل را دیده‌ای.
هر بار باید توضیح بدهی:
«در این پروژه از Server Component استفاده کن.»
«این پوشه را تغییر نده.»
«برای API از این الگو استفاده کن.»
«قبل از تغییر، تست‌ها را اجرا کن.»
فایل AGENTS.md قرار است همین اطلاعات را به شکل استاندارد در اختیار Agent قرار دهد.
در واقع یک فایل راهنما برای هوش مصنوعی پروژه است.
چیزی شبیه README، اما با مخاطب متفاوت.
README برای انسان‌هاست.
AGENTS.md برای Agentها.
Skills؛ اضافه کردن توانایی‌های مشخص به Agent
یک Agent عمومی همه چیز را نمی‌داند.
گاهی می‌خواهی یک Agent دقیقاً برای یک کار خاص آماده باشد.
مثلاً:
ساخت Componentهای UI
کار با Database
نوشتن تست
مدیریت API
Skills این امکان را می‌دهد که توانایی‌های مشخص‌تری تعریف شود.
این مدل باعث می‌شود Agent به جای اینکه هر بار از صفر تصمیم بگیرد، یک مسیر مشخص داشته باشد.
Versioned Docs برای جلوگیری از اشتباه Agentها
یکی از مشکلات رایج ابزارهای AI این است که ممکن است اطلاعات قدیمی استفاده کنند.
مثلاً یک Agent ممکن است کدی پیشنهاد دهد که برای Next.js 14 درست بوده، اما در Next.js 16 روش بهتری وجود داشته باشد.
Versioned Docs کمک می‌کند Agent اطلاعات هماهنگ با نسخه‌ی واقعی پروژه دریافت کند.
این موضوع در فریمورک‌هایی مثل Next.js که مرتب تغییر می‌کنند، اهمیت زیادی دارد.
قابلیت‌های آزمایشی Next.js 16.3
همه‌ی تغییرات این نسخه برای استفاده‌ی عمومی آماده نیستند.
چند قابلیت هنوز Experimental هستند.
React Compiler مبتنی بر Rust
React Compiler یکی از پروژه‌هایی است که هدفش بهینه‌سازی خودکار React است.
ایده این است که کامپایلر بتواند بخشی از بهینه‌سازی‌هایی را انجام دهد که قبلاً توسعه‌دهنده باید دستی انجام می‌داد.
چیزهایی مثل:
جلوگیری از Render اضافی
مدیریت بهتر Memoization
بهینه‌سازی محاسبات
نسخه‌ی Rust-based React Compiler تلاش می‌کند این فرآیند را سریع‌تر و مقیاس‌پذیرتر کند.
البته چون هنوز Experimental است، احتمالاً نباید همین فردا آن را روی Production فعال کرد.
اما مسیر آینده مشخص است.
React دارد بیشتر به سمت یک مدل Compiler-driven حرکت می‌کند.
Network Resilience؛ مقاوم‌تر شدن در برابر مشکلات شبکه
اپلیکیشن‌های واقعی همیشه در شرایط ایده‌آل اجرا نمی‌شوند.
کاربر ممکن است:
اینترنت ضعیف داشته باشد.
اتصال لحظه‌ای قطع شود.
درخواست‌ها timeout شوند.
Network Resilience تلاش می‌کند رفتار اپلیکیشن در این شرایط بهتر شود.
هدف این نیست که مشکل شبکه جادویی حل شود.
هدف این است که برنامه در برابر این اتفاق‌ها رفتار قابل پیش‌بینی‌تری داشته باشد.
آیا باید همین حالا به Next.js 16.3 آپدیت کنیم؟
مثل همیشه جواب به پروژه بستگی دارد.
اگر یک پروژه‌ی حساس Production داری که چند هفته است بدون مشکل کار می‌کند، بهتر است طبق روال معمول:
نسخه را در محیط تست بررسی کنی.
Build را چک کنی.
تست‌ها را اجرا کنی.
بعد منتشر کنی.
اما اگر:
پروژه‌ی بزرگی داری.
RAM زیادی در dev مصرف می‌شود.
CI Build طولانی است.
از App Router استفاده میکنی.
با ابزارهای AI کار میکنی.
Next.js 16.3 احتمالاً یکی از آن آپدیت‌هایی است که ارزش امتحان کردن دارد.
چیزی که این نسخه را جالب می‌کند این نیست که یک API عجیب اضافه کرده.
اتفاق مهم‌تر این است که تقریباً همه‌جا کمی بهتر شده.
Turbopack سبک‌تر شده.
Buildها سریع‌تر شده‌اند.
SSR بهینه‌تر شده.
Navigation روان‌تر شده.
و ابزارهای AI حالا بیشتر بخشی از اکوسیستم Next.js محسوب می‌شوند.
به نظر من Next.js 16.3 بیشتر از اینکه یک نسخه‌ی «با چند قابلیت جدید» باشد، یک قدم برای بالغ‌تر شدن فریمورک است.
قدم بعدی احتمالاً فقط سریع‌تر کردن اپلیکیشن نیست؛ بلکه ساختن محیطی است که انسان و Agent بتوانند کنار هم راحت‌تر محصول بسازند.
نکته‌ی مهم برای کسایی که از API استفاده میکنن
یه چیزی که قابل توجهه: این آپدیت فقط روی API عمومی V4-Flash اعمال شده، نه روی اپ و وبسایت دیپ‌سیک، و نه روی V4-Pro. یعنی اگه از طریق اپ چت دیپ‌سیک استفاده میکنی، رفتار مدل هنوز همون نسخه‌ی قبلیه. کسایی که مستقیم از API یا از سرویس‌هایی مثل Ollama یا OpenRouter استفاده میکنن، این تغییر رو به‌صورت خودکار و بی‌سروصدا دریافت کردن، بدون اینکه نیاز به تغییر کد یا endpoint داشته باشن.
اگه داری برای یه ابزار agentic (مثلاً یه coding assistant که چند مرحله tool call می‌زنه) مدل انتخاب میکنی، این آپدیت دلیل خوبیه که V4-Flash رو دوباره تست کنی، حتی اگه قبلاً بهش به چشم یه گزینه‌ی «سبک‌تر و کم‌قدرت‌تر» نسبت به V4-Pro نگاه می‌کردی. به نظر می‌رسه فعلاً این فرض دیگه لزوماً درست نیست.
Fast mode جدید برای Sol
همراه با این کاهش قیمت، OpenAI یک قابلیت جدید هم برای Sol معرفی کرده به اسم Fast mode، که به‌جای Priority Processing قبلی نشسته. این حالت تا ۲.۵ برابر سرعت پردازش استاندارد رو ارائه میده، ولی با دو برابر قیمت معمول. یعنی برای کاربردهایی که تأخیر (latency) بحرانیه — مثل agent هایی که باید بلادرنگ جواب بدن — یک گزینه‌ی صریح برای «سرعت در ازای هزینه‌ی بیشتر» وجود داره، به‌جای اینکه مجبور باشی کل ساختار قیمت‌گذاری رو حدس بزنی.
مقایسه با رقبا
نکته‌ای که گزارش رویترز بهش اشاره کرده جالبه: با قیمت جدید، Terra حالا حتی از Claude Sonnet 4.6 آنتروپیک هم ارزون‌تر تموم میشه — Sonnet 4.6 روی $3 ورودی و $15 خروجی قیمت‌گذاری شده، درحالی‌که Terra بعد از کاهش قیمت روی $2 و $12 قرار گرفته. این یعنی رقابت قیمتی بین لابراتوارهای بزرگ AI داره واقعی‌تر و ملموس‌تر میشه، نه فقط روی کاغذ.
چرا این برای دولوپرها مهمه
اگه داری یک pipeline خودکار میسازی که حجم بالایی از توکن مصرف میکنه — مثل پردازش batch داده، تولید محتوا، یا یک agent که مدام درخواست میفرسته — این کاهش قیمت مستقیماً روی صورت‌حساب ماهانه‌ات اثر میذاره، بدون اینکه مجبور باشی کدی رو تغییر بدی. تنها کاری که لازمه، اطمینان از اینکه مدل درستی (Luna برای کارهای سبک، Terra برای کارهای متوسط) رو برای هر بخش از workflow انتخاب کرده باشی، دقیقاً همون فلسفه‌ای که این چند وقت پشت تنظیمات effort در مدل‌های دیگه هم دیدیم: هزینه رو متناسب با واقعی‌بودن نیاز کار تنظیم کن، نه یک انتخاب یکسان برای همه‌چیز.
جمع‌بندی
این کاهش قیمت فقط یک تخفیف تجاری ساده نیست؛ نشونه‌ایه از اینکه رقابت بین مدل‌های AI داره وارد فاز جدیدی میشه که در اون کارایی و هزینه به‌اندازه‌ی هوش خام مهم شدن. برای کسی که روی این مدل‌ها پروژه میسازه، این خبر خوبیه: همون کیفیت، با هزینه‌ی کمتر. برای کل صنعت، این نشونه‌ی اینکه دوران بی‌حساب‌وکتاب مصرف توکن داره به سمت یک بازار بالغ‌تر و حساس‌تر به هزینه حرکت میکنه.
نکته‌ای که نباید نادیده گرفت
با همه‌ی این هیجان، این ابزار فعلاً پشت یک پولیوار جدیه: فقط مشترکین SuperGrok Heavy بهش دسترسی دارن، که رده‌ی بالای اشتراک Grok محسوب میشه. یعنی برخلاف تصوری که ممکنه از عبارت «بدون کدنویسی» به ذهن برسه، هنوز یک مانع (البته این‌بار مالی، نه فنی) سر راهه. همچنین چون این قابلیت هنوز در فاز early beta است، طبیعیه که محدودیت‌ها و باگ‌های اولیه‌ای هم داشته باشه که با گذر زمان رفع میشن.
جمع‌بندی
Build Mode نشون میده مسیر ابزارهای هوش مصنوعی داره از «چت‌کردن درباره‌ی کد» به‌سمت «تولید مستقیم محصول قابل‌استفاده» حرکت میکنه. برای کسی که ایده داره ولی مهارت فنی نداره، این یعنی فاصله‌ی بین فکر و محصول واقعی کوتاه‌تر شده. ولی برای کسی که دنبال یک ابزار توسعه‌ی جدی و قابل اتکاست، هنوز باید صبر کرد ببینه این نسخه‌ی beta، وقتی از پشت پولیوار بیرون بیاد و در دسترس عموم قرار بگیره، چقدر توی سناریوهای واقعی و پیچیده‌تر جواب میده.
دو تغییر جانبی که کمتر دیده شد
همراه با Opus 5، آنتروپیک دو تغییر دیگه هم روی پلتفرمش اعمال کرده که شاید برای دولوپرها حتی مهم‌تر از خود مدل باشه:
اول، امکان تغییر ابزارهای در دسترس مدل وسط یک مکالمه، بدون اینکه prompt cache باطل بشه. تا قبل از این، اگه توی یک کانورسیشن میخواستی لیست ابزارها رو عوض کنی، کش مکالمه از بین می‌رفت و هزینه‌ی پردازش دوباره بالا می‌رفت. حالا این محدودیت برداشته شده.
دوم، قابلیت fallback خودکار روی API. اگه یک درخواست توسط کلاسیفایرهای ایمنی روی Opus 5 یا Fable 5 پرچم بخوره، به‌جای اینکه درخواست رد بشه، میتونی تنظیم کنی که به‌صورت خودکار به بهترین مدل جایگزین در دسترس هدایت بشه. این یعنی کمتر پیش میاد یک اپلیکیشن production به‌خاطر یک ریجکشن مقطعی از کار بیفته.
زمینه‌ی رقابتی
این عرضه توی بحبوحه‌ی یک رقابت شدید بین‌المللی اتفاق افتاده. طبق گزارش BigGo Finance، چند روز قبل از Opus 5، مدل Kimi K3 معرفی شده بود، و علی‌بابا هم Qwen 3.8 Max Preview رو با ۲.۴ تریلیون پارامتر رونمایی کرده. Z.AI هم از GLM 5.5 —با بیش از یک تریلیون پارامتر و context window یک میلیون توکنی— برای عرضه در آگوست خبر داده. نکته‌ی مهم این مدل‌های چینی اینه که اغلب به‌صورت open-weight منتشر میشن، یعنی هرکسی میتونه دانلودشون کنه و شخصی‌سازی کنه؛ چیزی که آنتروپیک و OpenAI معمولاً ازش پرهیز میکنن.
جمع‌بندی: باید سوییچ کنیم؟
اگه الان روی Opus 4.8 کار میکنی، مهاجرت به Opus 5 هزینه‌ی اضافه‌ای نداره چون قیمت‌گذاری عوض نشده، و طبق ادعای آنتروپیک کیفیت بالاتر رفته. اگه پروژه‌ای داری که واقعاً به سقف مطلق هوش نیاز داره —مثل کاری که قراره روزها بدون نظارت جلو بره— همچنان باید سراغ Fable 5 بری. ولی برای اکثر کارهای روزمره، از تولید محتوا گرفته تا کدنویسی و اتوماسیون، Opus 5 دقیقاً همون رده‌ایه که آنتروپیک میخواد بشه پیش‌فرض همه: قوی به اندازه‌ی کافی، ولی نه به قیمتی که مجبورت کنه هر درخواست رو دو بار فکر کنی.
نکته‌ای که به نظرم برای کار خودمون توی این بلاگ مهمه: اگه داری pipeline ترجمه یا پردازش متن فارسی میسازی و هزینه برات مهمه، این مدل دقیقاً همون‌جاییه که باید نگاهش کنی. برای کارهایی که Pro واقعی لازم نیست ولی حجم بالاست، معمولاً Flash-Lite گزینه‌ی منطقی‌تریه تا اینکه بخوای برای هر درخواست پول یک مدل سنگین رو بدی.
Gemini 3.5 Flash Cyber: تخصصی و محدود
این یکی جالب‌ترین معرفیه، چون هدفش عمومی نیست. مدلی fine-tune شده روی پایه‌ی Flash، مخصوص پیدا کردن و patch کردن آسیب‌پذیری‌های امنیتی کد. فعلاً فقط در اختیار دولت‌ها و پارتنرهای منتخب گوگل قرار میگیره، نه توسعه‌دهنده‌ی عادی. این حرکت رو خیلی‌ها به رقابت گوگل با آنتروپیک در حوزه‌ی امنیت کد مرتبط میدونن، جایی که آنتروپیک با مدل‌های سری Mythos یک قدم جلوتر بوده.
چیزی که بین خط‌ها نوشته شده
گوگل همزمان با این عرضه گفته که pretraining نسل بعدی، یعنی Gemini 4، رو شروع کرده. یعنی درحالی که همه منتظر Pro هستن، تیم گوگل عملاً یک نسل جلوتر داره کار میکنه. این الگو رو قبلاً هم دیده بودیم — وقتی یک مدل میانی دیر میشه، شرکت‌ها به‌جای نگه داشتن کاربر توی خلأ، یک لایه‌ی سبک‌تر و ارزون‌تر رو زودتر میفرستن تا هم بازار رو نگه دارن هم فشار رقابتی رو کم کنن.
برای من به‌عنوان کسی که مدام بین مدل‌های مختلف API سوییچ میکنه، نکته‌ی عملی این خبر اینه: اگه الان روی 3.5 Flash کار میکنی، مهاجرت به 3.6 Flash احتمالاً بدون درد سره — قیمت پایین‌تره و بنچمارک‌ها بهتره. ولی اگه منتظر Pro بودی که یک جهش واقعی توی reasoning بدی، هنوز باید صبر کنی، و با توجه به سابقه‌ی این تأخیرها بعید نیست چند هفته‌ی دیگه هم طول بکشه.
