خبر

اگه توی تیمت کسی هست که هنوز از git+https://github.com/... توی package.json استفاده می‌کنه، یا یه package داری که موقع install یه native build می‌زنه، این مقاله برای اون آدمه. npm 12 توی جولای ۲۰۲۶ منتشر می‌شه — pre-release از ۱۹ ژوئن بیرون اومده — و سه breaking change داره که هر سه‌شون می‌تونن یه CI pipeline رو بی‌سروصدا خاموش کنن.

زمینه‌ی این تغییرات مهمه: یه سال حمله‌ی supply chain. سپتامبر ۲۰۲۵، اتکرها ۱۸ package معروف از جمله debug و chalk رو hijack کردن — packageهایی که هفته‌ای ۲.۶ میلیارد بار دانلود می‌شن. مارس ۲۰۲۶، کتابخونه‌ی Axios از طریق credential دزدیده‌شده compromise شد. ژوئن ۲۰۲۶، یه کِرم به اسم Miasma 57 package رو توی دو ساعت آلوده کرد. همه‌ی این حمله‌ها از یه مکانیزم استفاده کردن که npm از ده سال پیش داشت: هر package می‌تونست موقع install کد دلخواه اجرا کنه، بدون هیچ اجازه‌ی صریحی.

npm 12 این رو عوض می‌کنه.

تغییر اول: install scripts دیگه خودکار اجرا نمی‌شن

این مهم‌ترین و شکننده‌ترین تغییره. تا الان وقتی npm install می‌زدی، هر package ای می‌تونست preinstall، install، و postinstall اجرا کنه — بدون اینکه بدانی. از npm 12، این scriptها به‌طور پیش‌فرض block می‌شن مگه اینکه صریح approve‌شون کرده باشی.

چیزی که خیلی‌ها نمی‌دونن: این شامل native addon ها هم می‌شه. اگه یه package یه فایل binding.gyp داشته باشه، npm قبلاً به‌طور خودکار node-gyp rebuild رو می‌زد — حتی بدون هیچ install script صریحی. این همون مکانیزمی بود که Phantom Gyp attack ازش سوءاستفاده کرد: یه binding.gyp صد و پنجاه‌وهفت بایتی داخل یه package آلوده، و npm خودش کد مخرب رو compile و اجرا می‌کرد. npm 12 این رو هم block می‌کنه.

برای دیدن اینکه الان کدوم packageها script دارن:

npm approve-scripts --allow-scripts-pending

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

npm approve-scripts <package-name>

این approve به package.json commit می‌شه — یعنی می‌تونی توی PR review کنی و ببینی چه packageای اجرای script گرفته.

یه edge case مهم: npm rebuild هم subject to این block هست. اگه یه package توی allowlist نباشه، npm rebuild <package> بی‌سروصدا skip می‌کنه. راه‌حل:

npm approve-scripts <package>
npm rebuild <package>

تغییر دوم: Git dependency ها block می‌شن

اگه توی package.json ات چنین چیزی داری:

"some-lib": "git+https://github.com/org/repo.git"

از npm 12 این کار نمی‌کنه مگه اینکه --allow-git استفاده کنی.

این تغییر از فوریه ۲۰۲۶ اعلام شده بود. دلیلش اینه که یه Git dependency می‌تونه یه .npmrc داخل خودش داشته باشه که مسیر اجرایی git رو override کنه — حتی وقتی --ignore-scripts هم گذاشته باشی. خیلی از تیم‌ها فکر می‌کردن --ignore-scripts محافظشون می‌کنه، ولی این attack vector کاملاً جدا بود.

اگه از Git dependency برای یه package داخلی استفاده می‌کنی، بهترین راه اینه که به یه registry مایگریت کنی — GitHub Packages، Nexus، یا Artifactory. اضافه کردن --allow-git به هر CI script، مشکل رو حل نمی‌کنه، فقط جابه‌جاش می‌کنه.

تغییر سوم: remote URL ها block می‌شن

مشابه Git، اگه package ای داری که از یه URL مستقیم نصب می‌شه:

"internal-tool": "https://cdn.internal.com/packages/tool-1.2.3.tgz"

از npm 12 بدون --allow-remote کار نمی‌کنه.

remote URL ها unverifiable ان — npm نمی‌تونه تضمین کنه که اون tarball دستکاری نشده. حل درست اینه که به یه registry بری که integrity check داره.

چطور الان آماده بشی

npm 11.16.0 آخرین نسخه‌ی stable از 11.x هست. اگه upgrade کنی، همه‌ی این blocking ها به‌صورت warning نشون داده می‌شن — نه error. یعنی می‌تونی قبل از اینکه npm 12 بیاد ببینی چی می‌شکنه:

npm install -g npm@11.16.0
npm install   # warnings نشون می‌ده ولی نمی‌شکنه
npm approve-scripts --allow-scripts-pending   # لیست می‌ده

بعد از اینکه لیست گرفتی، packageهایی رو که بهشون اعتماد داری approve کن و package.json رو commit کن. یه چیزی که نباید بکنی: همه رو با یه flag blanket approve کنی فقط برای اینکه warning‌ها ساکت بشن — این کل هدف تغییر رو از بین می‌بره.

کدوم پروژه‌ها بیشترین ریسک رو دارن

پروژه‌هایی که به احتمال بالا مشکل پیدا می‌کنن:

هر پروژه‌ای که native addon دارد — یعنی packageهایی مثل bcrypt، sharp، canvas، node-sass، یا هر چیزی که به C/C++ compile وابسته‌ست. این packageها برای کار کردن به script اجرا شدن نیاز دارن.

هر پروژه‌ای که Git dependency دارد — معمولاً برای fork های داخلی یا patched نسخه‌ها.

هر پروژه‌ای که از HTTPS tarball برای package های داخلی استفاده می‌کنه.

اگه از هیچ‌کدوم از اینا استفاده نمی‌کنی، احتمالاً npm 12 برات transparent باشه.

یه نکته درباره‌ی پکیج نویس‌ها

اگه خودت package نگهداری می‌کنی که native build داره، بهترین راه اینه که prebuilt binary بشیپ کنی — با ابزارهایی مثل prebuild، prebuildify، یا node-pre-gyp. packageای که install-time compilation نداره، نمی‌تونه از این attack vector استفاده بشه. این یه بهبود بلندمدت هست که ارزش وقت گذاشتن داره.

این بزرگ‌ترین تغییر امنیتی npm در شانزده سال گذشته‌ست. ولی فقط یه تغییر configuration نیست — یه تغییر مدل اعتماده. ده سال بود که هر npm install به‌معنای دادن حق اجرای کد دلخواه به همه‌ی چیزی بود که توی dependency tree ات بود. این پیش‌فرض داشت تغییر می‌کرد — فقط کمی طول کشید.

۹ جولای ۲۰۲۶، تیم Rust نسخه‌ی ۱.۹۷.۰ رو منتشر کرد. این نسخه تغییرات زبانی بزرگی نداره، ولی سه چیزی که اضافه شده از اون دسته چیزهاییه که وقتی باهاشون کار می‌کنی، خوشحال می‌شی که هستن.

برای آپدیت:

rustup update stable

Symbol mangling v0 حالا پیش‌فرضه

این یکی یه تغییر زیرپوستیه که بیشتر وقت‌ها متوجهش نمی‌شی — تا وقتی که یه stack trace می‌گیری و یهو می‌بینی اسم functionها خوانا شدن.

وقتی Rust کد رو کامپایل می‌کنه، اسم هر item رو mangle می‌کنه تا با اسم‌های مشابه در crate‌های دیگه تداخل نداشته باشه. روش قدیمی از Itanium ABI که C++ هم ازش استفاده می‌کنه الهام گرفته بود — ولی مشکل داشت: generic parameterها فقط پشت یه hash پنهان می‌شدن، و بخش‌هایی از mangling از استاندارد Itanium منحرف شده بودن که همین باعث می‌شد demangler‌های خارجی درست کار نکنن.

روش جدید (v0) از Rust 1.59 به‌عنوان opt-in موجود بود، از نوامبر ۲۰۲۵ روی nightly پیش‌فرض شده بود، و حالا توی ۱.۹۷ به stable رسیده. نتیجه‌ی عملی: وقتی یه panic یا stack trace می‌بینی، اسم functionها همراه generic parameterهاشون نشون داده می‌شن، نه یه رشته‌ی hash‌شده‌ی نامفهوم.

روش قدیمی الان فقط روی nightly در دسترسه و برنامه اینه که در آینده کاملاً حذف بشه.

Cargo حالا warning‌ها رو مدیریت می‌کنه

تا قبل از این، رایج‌ترین راه برای deny کردن warning‌ها در CI این بود:

RUSTFLAGS=-Dwarnings cargo build

مشکل این روش اینه که -Dwarnings رو به هر invocation از rustc پاس می‌ده، و این build cache رو invalidate می‌کنه. یعنی هر بار که توی CI این flag رو داری، از کش استفاده نمی‌شه و همه چیز از صفر compile می‌شه.

از ۱.۹۷، Cargo خودش کنترل می‌کنه که warning‌ها چطور با موفقیت build تعامل داشته باشن. یه env var جدید اضافه شده:

# در CI: deny کردن warning‌ها
CARGO_BUILD_WARNINGS=deny cargo build

# موقع کار: خاموش کردن موقت warning‌ها
CARGO_BUILD_WARNINGS=allow cargo check

# حالت پیش‌فرض: نمایش بدون fail کردن
CARGO_BUILD_WARNINGS=warn cargo build

مزیت مهم اینه که این متغیر build cache رو invalidate نمی‌کنه. یعنی می‌تونی توی CI deny داشته باشی و همچنان از کش استفاده کنی. می‌شه با --keep-going هم ترکیبش کرد تا به‌جای توقف روی اولین خطا، همه‌ی خطاها و warning‌ها یکجا جمع بشن.

خروجی linker دیگه پنهان نمی‌شه

rustc وقتی کامپایل می‌کنه، یه linker رو از طرف کاربر صدا می‌زنه. تا الان اگه link موفق می‌شد، هر پیامی که linker داشت پنهان می‌شد. این رفتار گاهی مشکل‌ساز بود چون warning‌های واقعی linker — مثل deprecation warning برای یه optimization flag قدیمی — اصلاً دیده نمی‌شدن.

از ۱.۹۷، پیام‌های linker به‌صورت پیش‌فرض نمایش داده می‌شن:

warning: linker stderr: ignoring deprecated linker optimization setting '1'
  |
  = note: `#[warn(linker_messages)]` on by default

تیم Rust پیام‌هایی که false positive شناخته‌شده هستن رو فیلتر کرده تا نویز اضافه نداشته باشی. اگه یه پیام می‌بینی که فکر می‌کنی false positive هست، می‌تونی توی Cargo.toml آن را خاموش کنی:

[lints.rust]
linker_messages = "allow"

یه نکته مهم: این lint عمداً از گروه warnings جدا نگه داشته شده. یعنی CARGO_BUILD_WARNINGS=deny روی linker_messages تاثیر نمی‌ذاره — چون خروجی linker از پلتفرمی به پلتفرم دیگه فرق می‌کنه و نمی‌شه به‌طور قطعی همه‌شون رو deny کرد.

APIهای جدید stable شده

چند API مرتبط با bit manipulation اضافه شده که برای کدهای سطح‌پایین کاربردیه:

let x: u32 = 0b1010_1100;

// جدا کردن بیت بالایی
x.isolate_highest_one(); // => 0b1000_0000

// جدا کردن بیت پایینی
x.isolate_lowest_one(); // => 0b0000_0100

// مقدار بیت بالایی
x.highest_one(); // => 0b1000_0000

// مقدار بیت پایینی
x.lowest_one(); // => 0b0000_0100

// تعداد bitهای لازم برای نمایش مقدار
x.bit_width(); // => 8

همه‌ی این methodها روی NonZero<T> هم در دسترسن. char::is_control هم حالا توی context‌های const کار می‌کنه.

یه تغییر کوچیک برای کاربران WebAssembly

اگه با WebAssembly کار می‌کنی، یه breaking change هست که از نسخه‌ی ۱.۹۶ شروع شده: Rust دیگه به‌طور پیش‌فرض --allow-undefined به linker پاس نمی‌ده. یعنی symbolهای undefined الان linker error هستن، نه WebAssembly import‌های ضمنی. اگه intentional بود، باید صریح تعریفش کنی:

#[link(wasm_import_module = "env")]
unsafe extern "C" {
    fn my_extern_function();
}

این release از نظر حجم تغییرات زبانی یه نسخه‌ی آروم بود، ولی هر سه‌ی این تغییرها از اون دسته چیزهاییه که بعد از یه مدت کار کردن باهاشون، نفهمیدی چطور قبلاً بدونشون کار می‌کردی.

۹ جولای ۲۰۲۶، متا همزمان دو کار کرد: یه مدل جدید منتشر کرد و برای اولین‌بار پول گرفت. این دومی شاید مهم‌تر از اولی باشه.

متا سال‌ها روی open-source بود — Llama، Llama 2، Llama 3 — و هویتش رو روی این گذاشته بود که «ما مدل‌ها رو رایگان می‌دیم». Muse Spark 1.1 اولین مدل frontier متاست که پشت یه paid API قرار گرفته. این یعنی متا دیگه فقط یه تامین‌کننده‌ی مدل open-source نیست — داره مستقیم وارد همون بازاری می‌شه که Anthropic و OpenAI ازش پول در می‌آرن.

مدل چیه

Muse Spark 1.1 نسخه‌ی ارتقاءیافته‌ی Muse Spark اصلیه که اپریل ۲۰۲۶ منتشر شد — اولین مدل از Meta Superintelligence Labs، واحدی که Alexandr Wang (موسس Scale AI) رهبریش رو بر عهده داره. این مدل multimodal و reasoning-based هست و برای کارهای agentic طراحی شده: متن، تصویر، و ویدیو رو می‌فهمه، از ابزارها و سرویس‌های خارجی استفاده می‌کنه، کدنویسی و دیباگ می‌کنه، و می‌تونه وظایف چندمرحله‌ای رو با دخالت کمتر انسان انجام بده.

context window یه میلیون توکن داره، که برای کارهای agentic طولانی‌مدت عدد مهمیه. یه ویژگی هم که متا روش تاکید کرده اینه که مدل می‌تونه به‌جای اینکه sequential کار کنه، parallel subagent بزنه — یعنی چند بخش از یه task رو همزمان پیش ببره.

کجا قوی‌ترین، کجا عقب‌تر

متا روی benchmark‌هایی مثل MCP Atlas، JobBench، Humanity's Last Exam، و FinanceBench عملکرد خوبی نشون داده. MCP Atlas مخصوصاً مهمه چون tool-call success رو روی task typeهای مختلف می‌سنجه — و این دقیقاً همون چیزیه که برای ساختن agent واقعی اهمیت داره.

ولی متا خودش هم صادق بوده: روی benchmark‌های خالص کدنویسی و reasoning، Opus 4.8 از آنتروپیک و GPT-5.5 از OpenAI هنوز جلوترن. و Mythos 5 و Fable 5 آنتروپیک و GPT-5.6 سول از OpenAI هم کلاً در یه لیگ دیگه‌ان. Muse Spark 1.1 رو نه باید با بهترین مدل‌های موجود مقایسه کنی، نه باید دست کم بگیریش.

قیمت‌گذاری

هر یک‌میلیون توکن ورودی ۱.۲۵ دلار، خروجی ۴.۲۵ دلار. این عدد رو بذار کنار بقیه:

توکن ورودی‌های Claude Haiku 4.5 و GPT-5.6 Luna از Muse Spark ارزون‌ترن، ولی Sonnet 4.6 آنتروپیک و مدل‌های میانه‌ی OpenAI گرون‌ترن. یعنی Muse Spark 1.1 توی طیف mid-tier قیمتی قرار می‌گیره — نه ارزون‌ترین، نه گرون‌ترین. برای کسی که می‌خواد یه مدل agentic با context window بزرگ و قیمت معقول داشته باشه، جای جالبیه.

توسعه‌دهنده‌هایی که ثبت‌نام می‌کنن ۲۰ دلار اعتبار رایگان می‌گیرن.

نکته‌ای که توسعه‌دهنده‌ها باید بدونن

Meta Model API هم با OpenAI SDK سازگاره هم با Anthropic Messages format. یعنی اگه الان روی یکی از این دوتا کار می‌کنی، اشتکال‌پذیری به Muse Spark نیاز به rewrite نداره — فقط base URL رو به api.meta.ai/v1 تغییر بده، key بده، و اسم مدل رو muse-spark-1.1 بذار.

این یه تصمیم توزیع‌گر هوشمندانه‌ست. یعنی تیم‌ها می‌تونن Muse Spark رو A/B کنن با مدل فعلیشون بدون اینکه stack رو از نو بسازن.

این هفته برای متا

Muse Spark 1.1 تنها چیزی نبود که این هفته از متا اومد. دو روز قبلش Muse Image و Muse Video هم منتشر شدن — اولین مدل‌های تولید تصویر و ویدیوی Superintelligence Labs. ولی Muse Image یه جنجال هم به‌همراه آورد: اجازه داد کاربرا روی عکس‌های public اینستاگرامی که دیگران گذاشتن افکت AI اعمال کنن، بدون اینکه از صاحب عکس اجازه گرفته بشه. این تصمیم با اعتراض زیادی روبه‌رو شد.

وضعیت دسترسی

مدل الان توی «Thinking mode» در اپ Meta AI و سایت meta.ai در دسترسه — بدون نیاز به API. برای توسعه‌دهنده‌ها، Meta Model API به‌صورت public preview فعلاً فقط برای آمریکاییاست.

متا گفته این مدل در آینده جای Llama رو توی WhatsApp، Instagram، Facebook، و عینک‌های هوشمند متا هم می‌گیره. مارک زاکربرگ هم برای اولین‌بار از جولای ۲۰۲۳ روی X پست گذاشت که این مدل «strong agentic and coding model at a very low price» هست. سه سال سکوت روی یه پلتفرم برای اعلام یه مدل AI — این یه نشانه از اینه که داخل متا چقدر به این لانچ اهمیت می‌دن.

رقابت AI این هفته به‌طرز جالبی شلوغ بود. بازار داره به یه سمتی می‌ره که قیمت‌ها پایین‌تر، context windowها بزرگ‌تر، و تمرکز بیشتر روی کار agentic هست. Muse Spark 1.1 دقیقاً وسط همین جریانه.

۸ جولای ۲۰۲۶، مایکروسافت نسخه‌ی stable از TypeScript 7 رو منتشر کرد. بعد از حدود یه سال preview و beta و RC، حالا دیگه آزمایشی نیست.

اگه مقاله‌ی قبلی ما درباره‌ی RC رو خونده باشی، می‌دونی ماجرا از کجا شروع شد: مایکروسافت کامپایلر TypeScript رو که از ابتدا با JavaScript نوشته شده بود، با Go بازنویسی کرد. ولی «بازنویسی» دقیقاً کلمه‌ی درستی نیست — این یه port بود. ساختار کد، الگوریتم‌ها، و data structureها حفظ شدن، فقط زبان پیاده‌سازی عوض شد. نتیجه اینه که semantics تایپ‌چک دقیقاً همونه، ولی سرعتش حالا چیز دیگه‌ایه.

اعداد واقعی روی پروژه‌های واقعی

مایکروسافت همراه با اعلام stable، benchmark روی چند codebase واقعی منتشر کرده. روی VS Code با ۲.۳ میلیون خط کد، تایپ‌چک از ۱۲۵ ثانیه به ۱۰.۶ ثانیه رسیده — نزدیک ۱۲ برابر. روی Sentry با ۱.۹ میلیون خط، ۱۵.۷ ثانیه. روی Bluesky با ۶۲۸ هزار خط، ۲.۸ ثانیه. روی Playwright با ۵۲۸ هزار خط، ۱.۴۷ ثانیه.

عدد کلی که مایکروسافت می‌گه «اغلب بین ۸ تا ۱۲ برابر» هست — نه ۱۰ برابر ثابت. این بستگی داره به اندازه‌ی پروژه و ساختار dependency graph.

دلیل این سرعت دو چیز بود: اول، Go binary به‌جای JavaScript interpreted اجرا می‌شه. دوم، کامپایلر جدید می‌تونه از shared memory parallelism استفاده کنه. به‌صورت پیش‌فرض با ۴ worker تایپ‌چک می‌کنه — می‌تونی با flag --checkers این عدد رو تنظیم کنی. worker بیشتر یعنی سریع‌تر، ولی رم بیشتر هم می‌خواد.

برای چی این‌قدر طول کشید؟

وقتی مارس ۲۰۲۵ Anders Hejlsberg این پروژه رو اعلام کرد، خیلی‌ها انتظار نداشتن که اینقدر زود stable بشه. در واقع beta اپریل ۲۰۲۶ اومد، RC ژوئن ۲۰۲۶، و stable جولای ۲۰۲۶ — تقریباً ۱۵ ماه از اعلام تا stable. دلیل این سرعت نسبی اینه که از صفر طراحی نشد؛ port بود نه rewrite.

مایکروسافت بیش از یه سال با تیم‌های داخلی و شرکت‌هایی مثل Bloomberg، Canva، Figma، Google، Notion، Slack، Vercel و VoidZero روی preview buildها کار کرد. نتیجه اینه که از روز اول stable، این مدل‌ها روی codebaseهای میلیون‌خطی تایید شده.

نصب

npm install -D typescript@latest

همین. دیگه خبری از @typescript/native-preview یا tsgo نیست — اون package برای دوران beta بود. از این به بعد همه چیز از همون typescript package معمولی میاد و با همون tsc اجرا می‌شه.

برای چک کردن نسخه:

npx tsc --version  # باید TypeScript 7.x.x باشه

چی ممکنه بشکنه

TypeScript 7 با TypeScript 6 از نظر تایپ‌چک compatible هست — یعنی کدی که با ۶ compile می‌شد باید با ۷ هم compile بشه. با این حال، چند تغییر هست که باید بدانی:

--target es5 و format‌های output مثل AMD، UMD و SystemJS حذف شدن. moduleResolution: "node10" (همون قدیمی‌ترها که node می‌نوشتن) هم نیست. rootDir حالا به‌صورت پیش‌فرض ./ هست نه root پروژه، و types به‌صورت پیش‌فرض آرایه‌ی خالیه.

اگه مستقیم از TypeScript 5 یا قدیمی‌تر upgrade می‌کنی — نه ۶ — احتمال مشکل بیشتره چون این deprecationها توی ۶ warning بودن و حالا توی ۷ hard error شدن. توصیه اینه که اگه روی ۵ هستی، اول به ۶ بری و بعد به ۷.

یه چیز مهم که هنوز نیست

API برنامه‌نویسی TypeScript — همونی که ابزارهایی مثل typescript-eslint، ts-morph، و custom transformerها ازش استفاده می‌کنن — توی ۷.۰ پایدار نیست. مایکروسافت گفته این API توی نسخه‌ی ۷.۱ که چند ماه دیگه میاد آماده می‌شه.

یعنی اگه workflow‌ات به این ابزارها وابسته‌ست، فعلاً باید یه سری چیزها رو pinned روی TypeScript 6 نگه داری:

npm install -D @typescript/typescript6   # aliased package برای linting

مایکروسافت یه compatibility package برای این کار منتشر کرده تا بتونی هم ۶ هم ۷ رو side-by-side داشته باشی.

editor

برای VS Code، TypeScript Native Preview extension که قبلاً جداگانه نصب می‌کردی دیگه لازم نیست — همون typescript package که توی پروژه نصبه، editor هم ازش استفاده می‌کنه. فقط یه بار VS Code رو restart کن.

اگه روی editor دیگه‌ای کار می‌کنی (Neovim، Zed، Cursor)، language server protocol یکیه — هر clientی که از tsserver استفاده می‌کنه خودش سریع‌تر می‌شه بدون اینکه config خاصی بخواد.

نظر شخصی

این نوع تغییرات نادره. معمولاً «مهم‌ترین release در سال‌های اخیر» یه عبارت overused هست، ولی اینجا واقعاً صدق می‌کنه — نه به‌خاطر یه feature جدید، بلکه به‌خاطر اینکه یه چیزی که همه باهاش کنار اومده بودن (کامپایلر کند) یهو یه مقیاس کامل فرق کرده. اگه روی پروژه‌ی بزرگی کار می‌کنی که تایپ‌چک CI بیشتر از یه دقیقه طول می‌کشه، آپدیت کردن به ۷ احتمالاً صرفه‌جویانه‌ترین کاریه که می‌تونی این هفته انجام بدی.

این موضوع واقعا من رو به شخصه آزار میداد. من سیستمم بد  نیست ولی تاپ ناچم نیست و خب لود شدن تایپ اسکریپت برام انقدر کند بود که واقعا ازاردهنده بود. هنوز بررسیش نکردم ولی خب I have a lot of hope

اگه روی یه پروژه‌ی Next.js بزرگ کار کردی و یه نقطه‌ای رسیدی که Task Manager رو باز کردی و دیدی dev server تنهایی داره ۸ گیگ رم می‌خوره، می‌دونی این احساس چیه. Turbopack از اول با این طراحی اومد که همه‌چیز رو cache کنه تا compile سریع‌تر باشه — ولی قیمتش این بود که هرچقدر بیشتر توی پروژه می‌چرخیدی، حافظه بیشتری می‌خورد و هیچ‌وقت هم آزاد نمی‌کرد.

نسخه‌ی ۱۶.۳ این trade-off رو عوض کرده.

مصرف حافظه: ۹۰ درصد کمتر

تیم Turbopack سه ماه روی این کار کرد. نتیجه چیه؟ روی codebase داشبورد vercel.com، بعد از compile کردن ۵۰ route، مصرف حافظه از ۲۱.۵ گیگابایت به ۲ گیگابایت رسیده — یعنی ۹۰ درصد کمتر. روی سایت nextjs.org هم از ۴۶۰۰ مگابایت به ۸۴۰ مگابایت، یعنی حدود ۸۲ درصد کاهش.

چطور؟ با یه مکانیزم جدید به اسم memory eviction. ایده ساده‌ست: به‌جای اینکه نتایج cache شده برای همیشه توی RAM نگه داشته بشن، حالا Turbopack می‌تونه اونایی که دیگه فعال استفاده نمی‌شن رو بریزه روی دیسک و از حافظه پاک کنه. این feature روی filesystem cache که از نسخه‌ی ۱۶.۱ اضافه شده بود تکیه می‌کنه، و توی ۱۶.۳ هر دو به‌صورت پیش‌فرض فعال هستن.

اگه بخوای غیرفعالش کنی یا رفتارش رو debug کنی:

const nextConfig = {
  experimental: {
    turbopackMemoryEviction: false,
  },
};

یه چیز مهم: عدد دقیق کاهش حافظه برای هر پروژه فرق می‌کنه. بستگی داره به اینکه route graph پروژه‌ات چقدر بزرگه و توی یه session چقدر ازش استفاده کردی.

filesystem cache برای build

تا الان، filesystem cache فقط توی next dev کار می‌کرد. از ۱۶.۳، همین cache برای next build هم در دسترسه.

اعداد رو ببین: روی nextjs.org، build با cache از ۲۱ ثانیه به ۹.۲ ثانیه رسیده — ۲.۳ برابر سریع‌تر. روی vercel.com/geist که یه design system بزرگه، از ۳۰ ثانیه به ۵.۵ ثانیه — یعنی ۵.۵ برابر. روی vercel.com/home که پروژه‌ی سنگین‌تریه، بهبود کمتره: از ۶۶ به ۴۶ ثانیه.

فعال کردنش یه flag می‌خواد:

const nextConfig = {
  experimental: {
    turbopackFileSystemCacheForBuild: true,
  },
};

برای CI هم می‌شه از این استفاده کرد: کافیه پوشه‌ی .next رو بین runها کش کنی. وقتی Turbopack اون دایرکتوری رو اول build پیدا کنه، از کار قبلی استفاده می‌کنه به‌جای اینکه همه‌چیز رو از صفر compile کنه.

React Compiler با Rust

React Compiler از نسخه‌ی ۱۶.۰ توی Next.js stable بوده، ولی تا الان فقط به‌عنوان یه Babel transform اجرا می‌شد. مشکل اینجا بود که Babel روی پروژه‌های بزرگ سنگین می‌شد و build رو کند می‌کرد.

تیم React یه پورت native از این compiler با Rust نوشته، و تیم Turbopack سریع این رو integrate کرده. نتایج اولیه روی پروژه‌هایی مثل v0 نشون می‌ده که compile time بین ۲۰ تا ۵۰ درصد بهتر می‌شه. فعلاً experimental هست:

const nextConfig = {
  reactCompiler: true,
  experimental: {
    turbopackRustReactCompiler: true,
  },
};

import.meta.glob

Turbopack حالا از API ای که Vite معروفش کرده پشتیبانی می‌کنه:

const posts = import.meta.glob('./posts/*.mdx');

این به‌جای اینکه مجبور بشی اسم همه‌ی فایل‌ها رو hardcode کنی، هر فایلی که با pattern مطابقت داشته باشه رو import می‌کنه. نتیجه یه object هست که key‌هاش path فایل‌هاست:

for (const path in posts) {
  const post = await posts[path]();
}

می‌تونی با eager: true همه‌شون رو بلافاصله import کنی، یا فقط چند export خاص رو بگیری، یا pattern‌های منفی بگذاری. file watcher هم بهش وصله — اگه فایلی اضافه یا حذف شد، خودش recompile می‌کنه.

یه نکته: این feature فقط روی Turbopack کار می‌کنه. اگه هنوز با --webpack build می‌گیری، اینجا نیست.

HMR سریع‌تر و runtime کوچیک‌تر

دو بهبود دیگه که کمتر headline می‌گیرن ولی در عمل احساس می‌شن: اول اینکه HMR subscription tracking بهتر شده — با یکی کردن چند subscription در جاهایی که قبلاً جداگانه بودن، dev server cold start روی اپ‌های پیچیده بیش از ۱۵ درصد سریع‌تر شده. دوم اینکه runtime code ای که Turbopack به هر route اضافه می‌کنه کوچیک‌تر شده — چون حالا فقط کدی که واقعاً استفاده می‌شه (مثل WebAssembly loader یا worker support) شیپ می‌شه، نه همه‌چیز یکجا.

یه feature کوچیک‌تر هم برای monorepoها اومده: با turbopackLocalPostcssConfig: true می‌تونی per-package پیکربندی PostCSS داشته باشی به‌جای اینکه همه از root config بخوننن.

اگه الان روی Next.js 16.x هستی، این آپدیت شاید مهم‌ترین چیزیه که از نظر DX روزانه حسش می‌کنی — نه یه feature جدید، بلکه اینکه وقتی ساعت‌ها روی پروژه کار می‌کنی، IDE و dev server با هم دیگه دعوا نمی‌کنن سر رم.

اگه یه پروژه‌ی TypeScript بزرگ داری و تایپ‌چک هر بار چند دقیقه طول می‌کشه، این خبر برات جالبه: مایکروسافت ۱۸ ژوئن ۲۰۲۶ نسخه‌ی Release Candidate از TypeScript 7 رو منتشر کرد. نسخه‌ی stable هم قراره تا اواخر جولای ۲۰۲۶ بیاد.

چیزی که این نسخه رو از همه‌ی نسخه‌های قبلی متمایز می‌کنه اینه که کامپایلر دیگه با JavaScript نوشته نشده — حالا با Go نوشته شده. این پروژه از مارس ۲۰۲۵ با اعلام Anders Hejlsberg شروع شد، حدود پانزده ماه در فضای عمومی توسعه پیدا کرد، و حالا به مرحله‌ای رسیده که مایکروسافت می‌گه آماده‌ی استفاده‌ی روزانه است.

چرا Go؟

سوال منطقیه. TypeScript خودش یه زبان strongly-typed هست، چرا کامپایلرش رو با Go بنویسن نه Rust یا حتی TypeScript خودش؟

دلیل اصلی اینه که Go برای این نوع workload — یعنی parse کردن فایل‌های موازی، مدیریت حافظه‌ی مشترک، و پیاده‌سازی یه language service همزمان — tooling و runtime بهتری داره. Rust هم می‌تونست کار کنه، ولی تیم تصمیم گرفت با Go برگشت سریع‌تری داشته باشه.

نکته‌ی مهم‌تر اینه که این یه port هست نه یه rewrite از صفر. تیم TypeScript ساختار کد، الگوریتم‌ها، و data structureهای کامپایلر رو حفظ کرده — فقط زبان پیاده‌سازی عوض شده. این یعنی semantics تایپ‌چک دقیقاً همونه. در آزمون‌هایی که مایکروسافت انجام داده، از حدود ۲۰ هزار تست‌کیس کامپایلر، TypeScript 7 در همه جز ۷۴ مورد دقیقاً همون خطاهای TypeScript 6 رو برمی‌گردونه.

چقدر سریع‌تره؟

عدد رسمی که مایکروسافت داده «اغلب حدود ۱۰ برابر سریع‌تر از TypeScript 6» هست. این یه میانگین روی پروژه‌های مختلفه، نه یه عدد ثابت. روی codebase خود VS Code که حدود ۱.۵ میلیون خط هست، تایپ‌چک از ۷۷.۸ ثانیه به ۷.۵ ثانیه رسیده — حدود ۱۰.۴ برابر. زمان لود پروژه توی editor هم از ۹.۶ ثانیه به ۱.۲ ثانیه رسیده، و مصرف حافظه هم تقریباً نصف شده.

دو چیز این سرعت رو ممکن کرده: اول، Go binary به‌جای کد JavaScript interpreted اجرا می‌شه. دوم، مایکروسافت ساختار language service رو بازطراحی کرده تا از shared-memory parallelism استفاده کنه — چیزی که با runtime تک‌thread قبلی اصلاً ممکن نبود.

چی تغییر کرده که ممکنه کدت رو بشکنه

TypeScript 7 یه سری breaking change داره که اکثرشون از نسخه‌ی ۶ که «bridge release» بود، deprecated شده بودن:

پشتیبانی از --target es5 حذف شده. اگه هنوز برای مرورگرهای قدیمی build می‌گیری، باید از ابزارهای دیگه‌ای مثل Babel استفاده کنی. فرمت‌های output مثل AMD، UMD و SystemJS هم حذف شدن. moduleResolution: "node10" (که قبلاً به اسم node هم شناخته می‌شد) حذف شده و باید به bundler یا node16 تغییر پیدا کنه. --baseUrl و --paths هم رفتار قبلی‌شون رو ندارن و باید با paths توی tsconfig.json جایگزین بشن.

یه تغییر مهم دیگه اینه که rootDir حالا به‌صورت پیش‌فرض به ./src اشاره می‌کنه نه root پروژه.

مایکروسافت می‌گه ۹۵ درصد پروژه‌های TypeScript 6 بدون تغییر compile می‌شن. ولی اون ۵ درصد رو باید جدی بگیری — خصوصاً اگه پروژه‌ی قدیمیه یا config پیچیده داره.

API programmatic هنوز آماده نیست

یه محدودیت مهم که باید بدانی: API برنامه‌نویسی TypeScript — همونی که ابزارهایی مثل ts-jest، ts-node، و eslint-plugin-typescript ازش استفاده می‌کنن — هنوز در TypeScript 7 پایدار نیست. مایکروسافت گفته این API توی نسخه‌ی ۷.۱ که چند ماه بعد از ۷.۰ stable میاد آماده می‌شه.

یعنی اگه از این ابزارها استفاده می‌کنی، باید صبر کنی یا با احتیاط تست کنی.

چطور الان امتحانش کنی

npm install -D typescript@rc

همین. بعد از این:

npx tsc --version   # باید v7.0.0-rc باشه
npx tsc --noEmit    # تایپ‌چک کل پروژه

tsc داخل typescript@rc همون باینری Go هست. اسم tsgo که توی preview‌های ۲۰۲۵ استفاده می‌شد، حالا فقط برای nightly channel مانده.

برای rollback هم typescript@6 رو کنار داشته باش:

npm install -D typescript@6   # نسخه‌ی قبلی

آیا الان باید به پروداکشن ببریش؟

RC هست، نه stable. مایکروسافت می‌گه «highly stable» هست و بیش از یه سال pre-release testing داشته، ولی هنوز GA نشده.

برای سرویس‌های داخلی و pipeline های CI که فقط type-check می‌کنن و emit نمی‌کنن، همین الان می‌ارزه امتحانش کنی. اگه از API برنامه‌نویسی استفاده می‌کنی یا workflow پیچیده‌ای داری، صبر کن stable بیاد — که طبق برنامه اواخر جولای ۲۰۲۶ هست.

این بزرگ‌ترین تغییر توی TypeScript از همون اول بود. نه یه feature جدید، نه یه syntax تازه — یه تغییر بنیادی توی اینکه کامپایلر اصلاً چطور کار می‌کنه. و از اون نوع تغییراتیه که اکثر توسعه‌دهنده‌ها بدون اینکه بدونن چی عوض شده، فقط حس می‌کنن IDE یهو خیلی سریع‌تر شده.

یه چیز جالب داره توی فضای توسعه نرم‌افزار اتفاق می‌افته: یه بخش قابل‌توجه از کدی که توی Next.js نوشته می‌شه دیگه توسط انسان‌ها تایپ نمی‌شه. Claude Code، Cursor، Codex — این‌ها دارن به ابزارهای اصلی خیلی از تیم‌ها تبدیل می‌شن. تیم Next.js یه سوال جالب پرسیده: اگه فریم‌ورک می‌دونست که اکثر کدش رو یه agent می‌نویسه، چی فرق می‌کرد؟

۲۶ ژوئن ۲۰۲۶، Next.js 16.3 یه پست مجزا فقط برای بهبودهای AI-محور منتشر کرد — چیزی که قبلاً سابقه نداشت. این مقاله رو مرور می‌کنه.

AGENTS.md: agent بخونه، نه training data رو

توی نسخه‌ی ۱۶.۲، Next.js شروع کرد به bundled کردن مستنداتش داخل پروژه. ایده ساده بود: agent‌ها اغلب از training data خودشون استفاده می‌کنن، که ممکنه چند نسخه عقب‌تر باشه. اگه داک‌های نسخه‌ی فعلی رو داخل node_modules بگذاری و از طریق AGENTS.md بهش اشاره کنی، agent مجبور می‌شه نسخه‌ی درست رو بخونه.

توی ۱۶.۳، next dev به‌طور خودکار این pointer رو می‌نویسه و به‌روز نگه می‌داره. پروژه‌های قدیمی‌تر می‌تونن با یه codemod یه‌بار این کار رو بکنن:

npx @next/codemod@canary agents-md

بلوکی که next dev به AGENTS.md اضافه می‌کنه صریحه:

<!-- BEGIN:nextjs-agent-rules -->
# This is NOT the Next.js you know
This version has breaking changes — APIs, conventions, and file structure
may all differ from your training data. Read the relevant guide in
`node_modules/next/dist/docs/` before writing any code.
<!-- END:nextjs-agent-rules -->

این بلوک فقط وقتی next dev یه AI coding agent رو توی environment تشخیص بده نوشته می‌شه، و هر چیزی بیرون از marker‌ها دست‌نخورده می‌مونه.

Skills: وقتی داک کافی نیست

Skills برای workflow‌های چندمرحله‌ای‌اند — جایی که داک‌ها تنها نمی‌تونن agent رو از اول تا آخر هدایت کنن. سه Skill جدید اضافه شده:

next-dev-loop: به agent دسترسی به dev loop کامل می‌ده — مرورگر، console، network، و درخت React. بعد از هر ویرایش می‌تونه ببینه صفحه هنوز کار می‌کنه یا نه.

npx skills add vercel/next.js --skill next-dev-loop

next-cache-components-adoption: Cache Components رو توی پروژه فعال می‌کنه و یه feature در یه زمان پیش می‌ره. دو mode داره: incremental که یه PR مکانیکی می‌سازه و بقیه رو می‌ذاره برای بعد، و direct که همه‌ی route‌ها رو یه‌جا روی یه branch تغییر می‌ده.

next-cache-components-optimizer: یه route رو برای instant navigation بهینه می‌کنه با یه حلقه‌ی observe-fix-iterate روی static shell. قبل و بعد از هر تغییر screenshot می‌گیره؛ اگه تصاویر یکسان باشن، تغییر rollback می‌شه.

Agent Browser با React introspection

next-browser که توی ۱۶.۲ اضافه شده بود حالا merge شده توی agent-browser — یه CLI همه‌منظوره که فراتر از Next.js هم کار می‌کنه.

نسخه‌ی ۰.۲۷ یه چیز مهم اضافه کرده: React DevTools introspection. Agent‌ها الان می‌تونن درخت کامپوننت رو لیست کنن، یه کامپوننت خاص رو inspect کنن، re-renderها رو profile کنن، و ببینن چی یه render رو نگه داشته.

Actionable errors: خطا با دستورالعمل

وقتی Cache Components فعاله، یه await روی سرور یه انتخابه. Instant Insights این انتخاب رو به‌عنوان یه error با سه fix مشخص نشون می‌ده: Stream با <Suspense>، Cache با "use cache"، یا Block با export const instant = false.

اما مهم‌تر از خود error، یه دکمه‌ی «Copy prompt» اضافه شده. این دکمه fix انتخاب‌شده رو بسته‌بندی می‌کنه توی یه پرامپت آماده برای agent: شناسایی کد مشکل‌دار، خوندن داک مربوط، اعمال pattern، و تایید نتیجه توی مرورگر از طریق next-dev-loop.

همین fix menu توی terminal هم هست. next build و next dev هر دو خطاها رو با گزینه‌های labeled و لینک به بخش مربوطه از داک‌ها output می‌کنن — یعنی agent‌هایی که dev overlay ندارن و فقط terminal رو می‌خونن همون اطلاعات رو می‌گیرن.

هر error یه صفحه‌ی مجزا روی nextjs.org/docs/messages داره که برای خوندن توسط agent‌ها نوشته شده. هر صفحه همون ساختار رو داره: Patterns، Trade-offs، و Gotchas — یه چیزی که agent‌ها توی اولین تلاش احتمالاً بهش توجه نمی‌کنن.

MCP server: کوچیک‌تر و متمرکزتر

MCP server قبلاً یه knowledge base داخلی داشت. با اینکه bundled docs الان همون کار رو می‌کنه، اون ابزارها حذف شدن. در عوض، دو ابزار جدید اضافه شده: get_compilation_issues برای کل پروژه، و compile_route برای یه route خاص. agent‌ها اغلب next build می‌زدن فقط برای چک کردن compilation — این ابزارها همون سوال رو از dev server در حال اجرا جواب می‌دن، خیلی سریع‌تر.

Docs as Markdown

یه چیز ساده ولی کاربردی: به هر URL از داک‌های Next.js یه .md اضافه کن تا نسخه‌ی Markdown صفحه رو بگیری. همین برای صفحه‌های error هم کار می‌کنه.

ایندکس کامل روی /docs/llms.txt هست، و /docs/llms-full.txt همه‌ی صفحات رو توی یه فایل bundle می‌کنه — طبق convention استاندارد llms.txt.

یه قدم به سمت agent-first development

اگه بخوای خیلی ساده بگی چی اضافه شده: Next.js داره سعی می‌کنه agent‌ها رو مثل یه نوع developer جدید در نظر بگیره — با نیازهای متفاوت. Agent به داک‌های به‌روز نیاز داره نه training data قدیمی، به خطاهای actionable نیاز داره نه فقط error message، و به یه feedback loop نیاز داره که بتونه بعد از هر تغییر runtime رو چک کنه.

فعلاً هنوز preview هست. اگه می‌خوای همین الان امتحان کنی:

npm install next@preview

و بعد ببین کدوم بخش از workflow توسعه‌ات واقعاً بهتر می‌شه — یا نمی‌شه.

۹ ژوئن، آنتروپیک Fable 5 رو با سروصدا لانچ کرد. سه روز بعد، همه‌ی دسترسی‌ها قطع شد. اگه اون روزها پای Claude بودی و یهو دیدی مدل پیش‌فرضت دوباره همون Sonnet قدیمیه، تخیلات نبود — دولت آمریکا دخالت کرده بود.

۱۲ ژوئن، وزارت بازرگانی آمریکا یک دستورالعمل کنترل صادرات اعمال کرد که به‌خاطرش آنتروپیک مجبور شد دسترسی به Fable 5 و Mythos 5 رو برای همه قطع کند. دلیل رسمی این بود که شرکت نمی‌توانست در لحظه تشخیص دهد کاربر اهل کجاست، پس به‌جای محدودیت جغرافیایی، کل سرویس رو خواباند. بعداً مشخص شد محققی در آمازون روشی برای دور زدن safeguardهای Fable 5 پیدا کرده که مدل رو به پیدا کردن آسیب‌پذیری و نوشتن کد اکسپلویت وادار می‌کرده. آنتروپیک بلافاصله یه کلاسیفایر جدید آماده کرد تا این حفره رو ببندد، و بعد از ۱۸ روز توقف، ۳۰ ژوئن وزارت بازرگانی آمریکا محدودیت رو برداشت.

از اول جولای، Fable 5 برگشته — این‌بار با دسترسی جهانی و safeguardهای تقویت‌شده.

این ۱۸ روز برای کاربران معمولی یعنی چی بود

بذار صادق باشیم: اگه از نسخه‌ی رایگان یا Pro استفاده می‌کردی، احتمالاً اصلاً Fable 5 رو لمس نکردی. مدل از همان ابتدا فقط تا ۲۲ ژوئن روی پلن‌های Pro، Max و Team رایگان بود، و بعدش به کردیت نیاز داشت. یعنی پنجره‌ی دسترسی رایگان برای اکثر کاربران از اول هم کوتاه بود.

و همین‌جا بود که Sonnet 5 وارد شد — نه به‌عنوان جایگزین Fable، بلکه به‌عنوان چیزی که قرار بود برای بیشتر کاربران مدل روزمره باشد. آنتروپیک Sonnet 5 رو همزمان با اعلام بازگشت Fable معرفی کرد، و از همان روز اول به‌عنوان مدل پیش‌فرض برای پلن‌های Free و Pro تعریف شد.

ولی اگه روی نسخه‌ی رایگان یا حتی High توی پلن پولی امتحانش کردی، احتمالاً همون چیزی رو دیدی که من دیدم: با یه پرامپت و نصفه جواب برنمی‌گردوند. نه یه مکالمه‌ی طولانی، نه یه کار سنگین — یه سوال معمولی. محدودیت نرخ Sonnet 5 فعلاً خیلی سریع‌تر از نسخه‌های قبلی فعال می‌شود، مخصوصاً توی ساعت‌های شلوغ. آنتروپیک گفته که rate limitها رو برای پلن‌های مختلف افزایش داده، ولی در تستی که من انجام دادم در مدل رایگان جدید واقعا اینطور بنظر نیومد.

Sonnet 5 واقعاً چقدر فرق دارد

ادعای اصلی آنتروپیک این است که Sonnet 5 به عملکرد Opus 4.8 نزدیک است، ولی با قیمت خیلی پایین‌تر. در API، نرخ تعارفی تا پایان اوت ۲۰۲۶ برای هر یک‌میلیون توکن ورودی دو دلار و خروجی ده دلار است، بعدش به سه و پانزده دلار می‌رسد. Opus 4.8 روی همین مقیاس پنج و بیست‌وپنج دلار است. از نظر اعداد، Sonnet 5 روی بنچمارک‌های BrowseComp و OSWorld-Verified خیلی به Opus 4.8 نزدیک‌تر از Sonnet 4.6 است.

تفاوت اصلی در agentic قابلیت‌هاست: برنامه‌ریزی چندمرحله‌ای، کنترل مرورگر و ترمینال، و چک‌کردن خودکار خروجی بدون این‌که لازم باشد توی پرامپت بگویی «جوابت رو بررسی کن». اینا قابلیت‌هایی بودند که قبلاً بیشتر مختص مدل‌های Opus بود. از نظر امنیت سایبری هم آنتروپیک می‌گوید Sonnet 5 هیچ‌وقت روی داده‌های تخصصی امنیتی آموزش ندیده، و در تست‌هایی که با موزیلا انجام شده، روی آسیب‌پذیری‌های شناخته‌شده‌ی فایرفاکس هیچ اکسپلویت کاملی تولید نکرده. به همین خاطر هم دولت آمریکا سراغش نیامده.

Fable 5 الان چه وضعیتی دارد

Fable 5 برگشته، ولی نه به همان شکلی که اول لانچ شده بود. دسترسی رایگان روی پلن‌های Pro و Max تموم شده — حالا به کردیت نیاز دارد. Anthropic گفته هدفش این است که در آینده Fable رو دوباره به‌عنوان بخشی از پلن‌های اشتراکی برگرداند، ولی زمان مشخصی نداده.

Mythos 5 هنوز محدود است. آنتروپیک دسترسی رو برای یه سری سازمان‌های آمریکایی تاییدشده برقرار کرده و داره فهرست Project Glasswing رو گسترش می‌دهد، ولی برای عموم در دسترس نیست و ظاهراً تا مدتی هم نخواهد بود.

یه چیز جالب توی این ماجرا این بود که آنتروپیک، آمازون، مایکروسافت و گوگل با هم یه چارچوب مشترک برای رتبه‌بندی شدت jailbreakها پیشنهاد دادند. این نشان می‌دهد که وقتی مدل‌ها به این سطح از توانایی می‌رسند، بحث‌های امنیتی دیگر فقط داخلی نیست — صنعت داره سعی می‌کند یه زبان مشترک برای این مکالمات پیدا کند.

یه نکته‌ی مهم که باید بدانی: Fable 5 فعلاً فقط از طریق API در دسترس است. اگه انتظار داری توی claude.ai یا Claude Code بروی و از منوی مدل‌ها انتخابش کنی، ناامید می‌شوی. آنتروپیک گفته که قصد دارد Fable رو دوباره به پلن‌های اشتراکی برگرداند، ولی نه الان و نه با زمانبندی مشخص.

یه نظر شخصی که شاید ارزش داشته باشه بشنوی

وسط همه‌ی این سروصداها، یه چیزی هست که کمتر کسی می‌گوید: Sonnet 4.6 هنوز خیلی خوبه. اگه کارت کد نوشتن، توضیح مفاهیم، خلاصه‌سازی، یا همین کارهای روزمره‌ی برنامه‌نویسیه، Sonnet 4.6 تقریباً همه‌شان رو راه می‌اندازد — و مهم‌تر از اون، رایگانه یا خیلی ارزون‌تر.

Sonnet 5 و Fable 5 قابلیت‌های واقعی دارند، مخصوصاً توی کارهای agentic طولانی‌مدت که مدل باید خودش چندین مرحله رو مدیریت کند. ولی برای اکثر کارهای روزانه‌ای که یه توسعه‌دهنده‌ی معمولی باهاشون طرفه، این فاصله‌ای که بین نسخه‌ها هست توی عمل خیلی کمتر از اعداد بنچمارک‌هاست. قبل از اینکه بروی کردیت بخری یا پلن رو ارتقا بدی، ارزش داره یه هفته با همان Sonnet 4.6 کار کنی و ببینی کجا واقعاً به دیوار می‌خوری — اگه اصلاً بخوری.

تا همین چند روز پیش، GPT-5.5 تازه‌ترین مدل OpenAI بود. حالا نسل بعدی رسیده، اما این‌بار ماجرا فقط سر یک عدد جدید نیست؛ یک تغییر نام‌گذاری و یک محدودیت دسترسی غیرمعمول هم همراهش آمده که شاید جالب‌تر از خود مدل باشد.

OpenAI روز جمعه (۲۶ ژوئن ۲۰۲۶) پیش‌نمایش خانواده‌ی GPT-5.6 را منتشر کرد: سه مدل با نام‌های Sol، Terra و Luna. این اولین‌باری است که OpenAI به‌جای فقط افزایش عدد نسخه، یک نام‌گذاری ماندگار هم برایش گذاشته. طبق توضیح خودشان، از این به بعد عدد نشان‌دهنده‌ی نسل مدل است، و Sol/Terra/Luna رده‌های قابلیت هستند که می‌توانند هرکدام با سرعت خودشان پیش بروند. Sol پرچم‌دار و قوی‌ترین عضو خانواده است، Terra برای کارهای روزمره با تعادل بین قیمت و توان طراحی شده (و طبق ادعای OpenAI عملکردی نزدیک به GPT-5.5 دارد ولی دو برابر ارزان‌تر است)، و Luna ارزان‌ترین و سریع‌ترین گزینه است.

از نظر قابلیت، جایی که بیشترین پیشرفت دیده می‌شود کدنویسی، زیست‌شناسی محاسباتی، و امنیت سایبری است. روی Terminal-Bench 2.1 که گردش‌کارهای پیچیده‌ی خط‌فرمان را می‌سنجد، Sol رکورد جدیدی ثبت کرده. در حوزه‌ی ژنومیک هم روی بنچمارک GeneBench v1 نتیجه‌ی بهتری نسبت به GPT-5.5 گرفته، آن‌هم با مصرف توکن کمتر. یک حالت استدلال جدید به اسم max هم اضافه شده که زمان فکر کردن مدل را به حداکثر می‌رساند، و یک حالت ultra که کار را بین چند ساب‌ایجنت تقسیم می‌کند تا کارهای پیچیده سریع‌تر پیش بروند.

اما نکته‌ای که این مدل را از همه‌ی نسخه‌های قبلی متفاوت می‌کند، توانایی‌اش در امنیت سایبری است؛ و دقیقاً همین چیزی است که باعث محدودیت دسترسی شده.

چرا فقط ۲۰ شرکت می‌توانند استفاده کنند

OpenAI می‌گوید Sol قوی‌ترین مدلشان تا الان در کارهای امنیتی طولانی‌مدت مثل پیدا کردن آسیب‌پذیری و exploit‌نویسی است؛ روی بنچمارک ExploitBench، با حدود یک‌سوم توکن خروجی، عملکردی نزدیک به مدل Mythos Preview آنتروپیک دارد. این سطح از توانایی، در عمل یعنی مدل می‌تواند هم به تیم‌های امنیتی برای پیدا کردن و رفع باگ کمک کند، و هم در دست اشتباه، ابزار حمله باشد.

طبق گزارش Axios، دولت آمریکا از OpenAI خواسته که عرضه‌ی این مدل را محدود کند، دقیقاً همان‌طور که پیش‌تر برای مدل‌های Fable 5 و Mythos 5 آنتروپیک هم اتفاق افتاده بود. در نتیجه، فعلاً فقط حدود ۲۰ شرکت که مشارکتشان مورد تایید دولت بوده، به‌صورت پیش‌نمایش محدود به این مدل دسترسی دارند. خود OpenAI هم در پست رسمی‌اش صریح گفته که این رویکرد را راه‌حل بلندمدت نمی‌داند و آن را موقتی می‌خواند، اما معتقد است این مسیر سریع‌ترین راه برای رسیدن به انتشار عمومی در هفته‌های آینده است.

نکته‌ی فنی‌تر این‌جاست: OpenAI می‌گوید Sol از آستانه‌ی «بحرانی سایبری» تعریف‌شده در Preparedness Framework خودشان رد نشده. در آزمایش‌هایی روی Chromium و Firefox، مدل توانسته باگ و قطعات پایه‌ی یک exploit را پیدا کند، اما نتوانسته به‌طور خودکار یک زنجیره‌ی کامل و قابل‌اجرا بسازد. با این حال، خودشان هم تاکید کرده‌اند که هیچ بنچمارکی نمی‌تواند همه‌ی روش‌های استفاده‌ی واقعی را پیش‌بینی کند؛ برای همین کنار قابلیت بالاتر، سیستم ایمنی چندلایه هم گذاشته‌اند: محدودیت‌های آموزش‌دیده در خود مدل، کلاسیفایرهای بررسی لحظه‌ای خروجی، و بازبینی در سطح حساب کاربری برای رفتارهای مشکوک تکرارشونده.

قیمت و زمان‌بندی

برخلاف رفتار همیشگی OpenAI که مدل جدید را معمولاً مستقیم برای همه باز می‌کند، این‌بار فقط از طریق API و Codex، و فقط برای همان گروه محدود تایید‌شده در دسترس است. خودشان گفته‌اند قصد دارند به‌زودی آن را برای کاربران ChatGPT، Codex و API به‌طور عمومی منتشر کنند.

قیمت‌گذاری هم بر اساس هر یک‌میلیون توکن مشخص شده: Sol پنج دلار ورودی و سی دلار خروجی، Terra دو و نیم دلار ورودی و پانزده دلار خروجی، و Luna یک دلار ورودی و شش دلار خروجی. یک تغییر کوچک ولی کاربردی هم در کشینگ پرامپت آمده: حالا می‌توان نقطه‌ی cache مشخص کرد و حداقل عمر کش به سی دقیقه رسیده، با این تفاوت که نوشتن در کش این‌بار ۱.۲۵ برابر نرخ معمولی ورودی هزینه دارد.

اگر شایعات و گزارش‌های قبل از انتشار رسمی را هم در نظر بگیری (که در روزهای منتهی به این پیش‌نمایش زیاد بودند)، رقابت اصلی روی همین نکته است: آنتروپیک به‌خاطر همان نوع محدودیت دولتی، فعلاً مدل Mythos-tier خودش را در دسترس عموم ندارد، و OpenAI به‌وضوح می‌خواهد از این فاصله استفاده کند. این‌که این محدودیت چقدر طول می‌کشد و چه زمانی Sol، Terra و Luna واقعاً به دست همه می‌رسند، چیزی است که باید منتظرش ماند.

شرکت اپیک گیمز (Epic Games) به طور رسمی از نسل بعدی موتور بازی‌سازی خود یعنی Unreal Engine 6 رونمایی کرد که قرار است مرزهای بین بازی‌های سنتی و جهان‌های ابری را کاملاً از بین ببرد.

اپیک گیمز در جریان کنفرانس اخیر خود (State of Unreal)، با معرفی نقشه راه Unreal Engine 6 (UE6)، بمب خبری بزرگی را در میان جامعه توسعه‌دهندگان و گیمرها منفجر کرد. اگر فکر می‌کنید این آپدیت هم فقط قرار است گرافیک بازی‌ها را کمی واقع‌گرایانه‌تر کند، سخت در اشتباهید؛ ورق در حال برگشتن است!

اپیک این‌بار تمرکز خود را از «چگونه ساختن بازی‌ها» به «چگونه منتشر کردن و مدیریت آن‌ها» تغییر داده است. هسته اصلی این تغییر، ادغام موتور قدرتمند Unreal Engine 5 و ابزار بازی‌سازی فورتنایت یعنی UEFN در یک پلتفرم واحد و یکپارچه است. یعنی شما یک‌بار بازی را می‌سازید و می‌توانید آن را هم‌زمان روی کنسول‌ها، کامپیوتر، موبایل و حتی به عنوان یک مینی‌گیم یا دنیای مجزا درون خود بازی فورتنایت (Fortnite) عرضه کنید!

تغییرات کلیدی و انقلابی در نسل ششم

• کوچ بزرگ به زبان برنامه‌نویسی ورس (Verse): اپیک گیمز به مرور زمان زبان سنتی $C++$ و سیستم محبوب Blueprints را کنار می‌گذارد تا زبان جدید Verse را جایگزین کند. این زبان اختصاصی اجازه می‌دهد هزاران نفر به طور هم‌زمان و بدون تداخل، روی یک دنیای زنده و آنلاین کار کنند.

• اقتصاد و دارایی‌های مشترک (Interoperability): شاید عجیب‌ترین بخش خبر این باشد که در UE6، کدهای برنامه‌نویسی و آیتم‌های درون بازی (مثل اسکین‌ها) قابلیت جابه‌جایی بین بازی‌های مختلف را دارند! اپیک تایید کرده که در اولین قدم، بازیکنان می‌توانند اسکین‌های فورتنایت خود را به بازی‌های ساخته‌شده با UE6 ببرند و برعکس.

• تزریق هوش مصنوعی مولد به رگ‌های موتور: با پشتیبانی از پروتکل MCP (مخفف Model Context Protocol)، توسعه‌دهندگان می‌توانند از هوش مصنوعی‌های محبوبی مثل Claude و Gemini مستقیماً درون ابزار توسعه استفاده کنند تا کارهای تکراری و زمان‌بر حذف شوند و سرعت ساخت بازی‌ها چند برابر شود.

• پشتیبانی باورنکردنی از سخت‌افزارهای ضعیف‌تر: در حاشیه این رویداد، نسخه جدید UE 5.8 نیز منتشر شد که به عنوان پل پیش‌درآمدی برای UE6 عمل می‌کند. فناوری نورپردازی Lumen حالا بهینه‌سازی شده تا بازی‌های سنگین بتوانند روی سخت‌افزارهای ضعیف‌تری مثل کنسول Nintendo Switch 2 یا پی‌سی‌های اقتصادی با نرخ 60 فریم بر ثانیه اجرا شوند.

این موضوع چه سودی برای ما (گیمرها) دارد؟

برای کاربر نهایی، این یعنی پایان دوران انتظار ۴ یا ۵ ساله برای ساخت بازی‌های بزرگ (AAA). بازی‌ها با کمک هوش مصنوعی و کدهای بهینه‌تر بسیار سریع‌تر ساخته می‌شوند، آپدیت‌ها فورا و بدون دانلودهای حجیم روی سرورها اعمال می‌شوند و از همه جذاب‌تر، پول و زمانی که برای خرید آیتم در یک بازی صرف کرده‌اید، در بازی‌های دیگرِ این اکوسیستم هم ارزش خواهد داشت.

تحلیل کوتاه (Peer Insight)

معرفی Unreal Engine 6 نشان می‌دهد که نگاه «تیم سوئینی» (مدیرعامل اپیک) به آینده صنعت گیم، فراتر از فروش بازی‌های مجزای خطی است. اپیک با این حرکت عملاً در حال ساخت زیرساختِ یک مِتاورس واقعی و کاربردی است؛ جایی که فورتنایت دیگر فقط یک بازی بتل‌رویال نیست، بلکه سیستم‌عاملِ بازی‌های آینده است. این انحصار و یکپارچگیِ بی‌نظیر، زنگ خطر بزرگی را برای رقبایی مثل موتور بازی‌سازی Unity به صدا درمی‌آورد.

نسخه دسترسی زودهنگام (Early Access) این موتور قدرتمند برای اواخر سال ۲۰۲۷ برنامه‌ریزی شده است، بنابراین تا دیدن اولین بازی‌های تماماً ساختِ UE6 هنوز چند سالی فاصله داریم.

دولت آمریکا به دلیل نگرانی‌های امنیتی، دستور توقف فوری و کامل دسترسی به مدل‌های قدرتمند Fable 5 و Mythos 5 شرکت آنتروپیک (Anthropic) را صادر کرد؛ تصمیمی که با مخالفت شدید این کمپانی روبه‌رو شده است.

داستان از روز گذشته و دقیقاً در ساعت ۵:۲۱ عصر به‌وقت شرقی آمریکا شروع شد؛ زمانی که یک دستور ناگهانی و شوکه‌کننده از سمت دولت ایالات متحده به دفتر شرکت آنتروپیک رسید. واشنگتن با استناد به اختیارات کنترل صادرات و امنیت ملی، دستور داده که دسترسی تمام کاربران خارجی (چه داخل آمریکا و چه خارج از آن) و حتی کارمندان غیرآمریکایی خودِ شرکت آنتروپیک به دو مدل پیشرفته Fable 5 و Mythos 5 قطع شود. نتیجه؟ آنتروپیک برای پایبندی به قانون مجبور شد این دو مدل را به‌طور کامل برای همه کاربران در سراسر جهان غیرفعال کند.

ماجرا چیست؟ داستان یک جیلبریک (Jailbreak) جنجالی بر اساس اطلاعات منتشر شده، به نظر می‌رسد دولت آمریکا مدعی شده که یک روش نفوذ یا همان «جیلبریک» پیدا کرده که می‌تواند لایه‌های امنیتی Fable 5 را دور بزند. اما آنتروپیک اصلاً با این تصمیم موافق نیست! این شرکت می‌گوید چیزی که دولت به عنوان نقطه ضعف پیدا کرده، صرفاً یک باگ جزیی و محدود است؛ در واقع سیستم فقط یک سری کد را خوانده و باگ‌های نرم‌افزاری آن را اصلاح کرده است؛ کاری که مدل‌های رقیب مثل GPT-5.5 شرکت OpenAI نیز هر روز برای متخصصان امنیت شبکه‌ انجام می‌دهند و هیچ قابلیت خطرناکی محسوب نمی‌شود.

سود و زیان این اتفاق برای کاربر نهایی چیست؟ اگر از کاربران خدمات آنتروپیک هستید، این تصمیم مستقیماً روی کار شما تاثیر می‌گذارد:

• قطعی سرویس: متأسفانه در حال حاضر دسترسی شما به قوی‌ترین و جدیدترین مدل‌های این شرکت یعنی Fable 5 و Mythos 5 کاملاً قطع شده است.

• سایر مدل‌ها امن هستند: خبر خوب این است که دسترسی به بقیه مدل‌های قدیمی‌تر و استاندارد آنتروپیک (مثل نسخه‌های مختلف کلاود) هیچ تغییری نکرده و مثل قبل کار می‌کنند.

• پافشاری بر حریم خصوصی: آنتروپیک پیش از این برای بررسی همین حملات، سیاست ذخیره ۳۰ روزه داده‌های کاربران را وضع کرده بود که صدای خیلی‌ها را درآورد؛ حالا مشخص شد این کار برای دفاع چندلایه در برابر چنین روزهایی بوده است.

ویژگی‌های امنیتی Fable 5 از زبان آنتروپیک

آنتروپیک سفت و سخت پای لایه‌های امنیتی محصولش ایستاده و می‌گوید قبل از عرضه، هزاران ساعت تست نفوذ (Red-Teaming) با همکاری دولت آمریکا و سازمان امنیت هوش مصنوعی بریتانیا (UK AISI) انجام داده است. ویژگی‌های این سیستم عبارت بودند از:

• سخت‌گیری شدید: لایه‌های حفاظتی این مدل آن‌قدر قوی طراحی شده بودند که بسیاری از کاربران عادی از محدودیت‌های زیاد آن شکایت داشتند.

• نبود جیلبریک همه‌جانبه: تا این لحظه هیچ هکر یا تستر امنیتی نتوانسته یک «جیلبریک جهانی» (Universal Jailbreak) پیدا کند که تمام قفل‌های سیستم را یک‌جا باز کند.

• استراتژی دفاع چندلایه (Defense in Depth): آنتروپیک معتقد است هوش مصنوعی بی‌نقص وجود ندارد؛ بنابراین استراتژی آن‌ها سخت کردن و گران کردن فرآیند هک برای نفوذگرها بوده، نه ادعای امنیت ۱۰۰ درصدی.

تحلیل کوتاه

این اقدام دولت آمریکا یک زنگ خطر جدی و یک نقطه عطف در تاریخ هوش مصنوعی است. تا پیش از این، دولت‌ها بیشتر در حد توصیه و بیانیه با شرکت‌های بزرگ فناوری تعامل می‌کردند، اما این «احضار و توقیف» ناگهانی نشان می‌دهد که کاخ سفید تعارفی با حوزه فناوری ندارد. نکته نگران‌کننده اینجاست: همان‌طور که آنتروپیک اشاره کرده، اگر استاندارد دولت برای توقیف یک مدل، پیدا شدن یک باگ یا جیلبریک جزیی و محدود باشد، از این به بعد باید منتظر توقف پی‌درپی و زنجیره‌ای تمام مدل‌های پیشرو (Frontier Models) در دنیا باشیم؛ اتفاقی که می‌تواند چرخ توسعه هوش مصنوعی را به شدت کند، یا حتی متوقف کند. آنتروپیک اعلام کرده که این یک سوءتفاهم بزرگ است و در حال رایزنی برای بازگرداندن این دو مدل است، اما بازی قدرت میان رگولاتورها و توسعه‌دهندگان تازه وارد فاز جدی خود شده است.

در دنیای هوش مصنوعی، معمولاً شرکت‌ها تلاش می‌کنند مدل‌های قدرتمندتری بسازند و هرچه سریع‌تر آن‌ها را در اختیار کاربران بگذارند. اما گاهی اوقات یک مدل آن‌قدر پیشرفته می‌شود که حتی سازنده‌اش درباره انتشار عمومی آن دچار تردید می‌شود.

این دقیقاً همان اتفاقی است که برای خانواده Claude Mythos افتاد.

در ۹ ژوئن ۲۰۲۶، Anthropic از دو مدل جدید به نام‌های Claude Fable 5 و Claude Mythos 5 رونمایی کرد. این معرفی، اوج یک فرآیند چند ماهه بود که از آوریل همان سال آغاز شده بود — زمانی که Anthropic برای اولین بار ثابت کرد مدل‌های هوش مصنوعی می‌توانند به مرزهایی برسند که انتشار بی‌قید و شرط آن‌ها دیگر گزینه‌ای مطمئن نیست.

در این مقاله، با تکیه بر اعلامیه رسمی Anthropic، تمام جوانب این دو مدل را بررسی می‌کنیم.

پیش‌زمینه: داستان Mythos Preview

برای درک Fable 5 و Mythos 5، باید به آوریل ۲۰۲۶ برگردیم.

در آن ماه، Anthropic اولین مدل از خانواده Mythos-class خود را با نام Claude Mythos Preview معرفی کرد. اما برخلاف تمام مدل‌های قبلی، این مدل به صورت عمومی منتشر نشد. دلیل آن چیز غیرمنتظره‌ای بود: Mythos Preview توانسته بود آسیب‌پذیری‌هایی در سیستم‌عامل‌ها و مرورگرهای اصلی شناسایی کند — بدون اینکه اصلاً برای این هدف طراحی شده باشد.

به بیان دیگر، این مدل توانایی‌هایی داشت که در دست افراد نادرست می‌توانست به ابزاری خطرناک تبدیل شود.

Anthropic در پاسخ به این وضعیت، پروژه‌ای به نام Project Glasswing راه‌اندازی کرد: یک برنامه همکاری کنترل‌شده با سازمان‌های منتخب، از جمله Apple، Google، Amazon، Microsoft، Cisco، JPMorgan Chase و دولت ایالات متحده. هدف این پروژه استفاده از توانایی‌های Mythos برای تقویت امنیت زیرساخت‌های حیاتی بود — نه بهره‌برداری از آن برای حمله.

چند هفته بعد، Anthropic دسترسی را به حدود ۱۵۰ سازمان در بیش از پانزده کشور گسترش داد. و حالا، با معرفی Fable 5، برای اولین بار این فناوری در اختیار عموم قرار گرفته است.

Claude Fable 5 چیست؟

Claude Fable 5 اولین مدل Mythos-class است که برای همه کاربران در دسترس قرار گرفته. Anthropic درباره آن صریح است: «توانایی‌های Fable 5 از هر مدلی که تا به حال به صورت عمومی عرضه کرده‌ایم فراتر می‌رود.»

اما این قدرت بیشتر با یک مکانیزم امنیتی همراه شده است. Fable 5 از سیستمی به نام classifier استفاده می‌کند — مجموعه‌ای از مدل‌های هوش مصنوعی جداگانه که درخواست‌های بالقوه مخرب را شناسایی می‌کنند. هر بار که این سیستم یک درخواست را مشکل‌دار تشخیص دهد، پاسخ به‌طور خودکار توسط Claude Opus 4.8 داده می‌شود — به جای اینکه درخواست کاملاً رد شود. این رویکرد هوشمندانه‌ای است؛ چرا که کاربر یک پاسخ مفید دریافت می‌کند، اما از توانایی‌های پیشرفته‌تری که می‌توانند مورد سوءاستفاده قرار بگیرند، محافظت می‌شود.

این fallback در کمتر از ۵ درصد جلسات اتفاق می‌افتد. برای بقیه کاربران، عملکرد Fable 5 عملاً برابر با Mythos 5 است.

سه حوزه اصلی تحت پوشش classifier قرار دارند:

امنیت سایبری. Mythos-class در شناسایی و بهره‌برداری از آسیب‌پذیری‌های نرم‌افزاری فوق‌العاده عمل می‌کند. classifier های Fable 5 نه‌تنها بهره‌برداری از آسیب‌پذیری، بلکه طیف گسترده‌تری از وظایف تهاجمی سایبری — شامل شناسایی، حرکت جانبی و فرار از سیستم‌های دفاعی — را پوشش می‌دهند. یک آزمون خارجی با بیش از ۱۰۰۰ ساعت تست انجام شد و هیچ jailbreak جهانی پیدا نشد.

زیست‌شناسی و شیمی. Mythos 5 در پیش‌بینی خواص ویروس‌های پیچیده، عملکردی بهتر از مدل‌های اختصاصی پروتئین داشت — بدون اینکه برای این کار آموزش دیده باشد. این توانایی dual-use است: در دست محققان، ابزاری ارزشمند برای توسعه درمان‌های ژنی است؛ در دست افراد نادرست، می‌تواند خطرناک باشد. به همین دلیل، اکثر درخواست‌های مرتبط با زیست‌شناسی و شیمی فعلاً به Opus 4.8 ارجاع داده می‌شوند.

Distillation. این classifier از تلاش‌های مقیاس‌بزرگ برای استخراج توانایی‌های Claude و استفاده از آن‌ها برای آموزش مدل‌های رقیب جلوگیری می‌کند.

Claude Mythos 5 چیست؟

Claude Mythos 5 همان مدل پایه‌ای است که Fable 5 بر آن بنا شده، اما با یک تفاوت کلیدی: محدودیت‌های سایبری آن برداشته شده است.

نام‌گذاری این دو مدل نیز بامعناست. «Fable» از ریشه لاتین fabula به معنای «آنچه گفته می‌شود» می‌آید — هم‌ریشه با کلمه یونانی mythos. تنها چیزی که این دو مدل را از هم جدا می‌کند، وجود یا عدم وجود همان safeguardها است.

Mythos 5 در حال حاضر تنها برای شرکای Project Glasswing — شامل سازمان‌های امنیت سایبری و ارائه‌دهندگان زیرساخت‌های حیاتی — در دسترس است. Anthropic قصد دارد به زودی دسترسی را به محققان زیست‌پزشکی تأییدشده نیز گسترش دهد، با این تفاوت که برای آن‌ها safeguardهای زیست‌شناسی برداشته می‌شود، اما محدودیت‌های سایبری همچنان باقی می‌ماند.

قابلیت‌های اصلی این مدل‌ها

Fable 5 و Mythos 5 در چند حوزه به صورت خاص برجسته هستند.

برنامه‌نویسی. شرکت Stripe گزارش داده که Fable 5 یک migration در پایگاه کد ۵۰ میلیون خطی Ruby را در یک روز انجام داد — کاری که یک تیم کامل بیش از دو ماه نیاز داشت. در بنچمارک FrontierCode که کیفیت کد تولیدی در محیط‌های واقعی را ارزیابی می‌کند، Fable 5 بالاترین امتیاز را در بین مدل‌های frontier کسب کرد.

وظایف طولانی‌مدت. این مدل‌ها می‌توانند ساعت‌ها روی یک پروژه کار کنند، پیشرفت خود را ارزیابی کنند و مسیر را در صورت نیاز اصلاح کنند. هر دو مدل از پنجره context یک میلیون توکن با خروجی تا ۱۲۸ هزار توکن در هر درخواست پشتیبانی می‌کنند. آزمایش با بازی Slay the Spire نشان داد که استفاده از حافظه مبتنی بر فایل، عملکرد Fable 5 را سه برابر بیشتر از Opus 4.8 بهبود می‌دهد.

پردازش تصویر. Fable 5 جدیدترین مدل state-of-the-art در حوزه بینایی است. این مدل توانست بازی Pokémon FireRed را تنها با تماشای اسکرین‌شات‌های خام و بدون هیچ ابزار کمکی به پایان برساند — کاری که مدل‌های قبلی Claude حتی با harness های پیچیده هم به سختی از پس آن برمی‌آمدند.

تحقیقات علمی. Mythos 5 فرآیند طراحی دارو را تا ۱۰ برابر سریع‌تر کرده و در ۹ مورد از ۱۴ هدف پروتئینی مورد مطالعه، کاندیداهای قوی شناسایی کرده است. همچنین اولین مدل Anthropic است که به طور مستمر فرضیه‌های علمی نوآورانه تولید می‌کند؛ یکی از این فرضیه‌ها درباره یک پروتئین باکتریایی بعداً توسط یک آزمایشگاه مستقل تأیید شد.

تحلیل مالی و کاری. در Finance Benchmark شرکت Hebbia برای استدلال در سطح ارشد، Fable 5 بالاترین امتیاز را در بین تمام مدل‌های آزمایش‌شده کسب کرد. شرکت IMC نیز گزارش داد که این مدل در تقریباً تمام معیارهای ارزیابی تحلیل معاملاتی نتایج عالی داشت.

سیاست جدید نگهداری داده

یکی از تغییرات مهمی که با این مدل‌ها همراه شده، الزام نگهداری ۳۰ روزه داده برای تمام ترافیک روی مدل‌های Mythos-class است.

Anthropic تأکید می‌کند که این داده‌ها برای آموزش مدل‌های جدید استفاده نمی‌شوند و تمام دسترسی‌های انسانی به آن‌ها ثبت می‌شود. هدف اصلی شناسایی jailbreak های پیچیده‌ای است که ممکن است در طول زمان و در چند مکالمه مختلف طراحی شده باشند — حملاتی که بررسی تک‌به‌تک جلسات قادر به شناسایی آن‌ها نیست.

قیمت‌گذاری و دسترسی

هر دو مدل با قیمت یکسان عرضه شده‌اند: ۱۰ دلار به ازای هر میلیون توکن ورودی و ۵۰ دلار به ازای هر میلیون توکن خروجی. این قیمت کمتر از نصف قیمت Claude Mythos Preview است.

از نظر دسترسی:

Claude Fable 5 از ۹ ژوئن ۲۰۲۶ از طریق Claude API و پلن‌های Enterprise مصرفی کاملاً در دسترس است. برای کاربران اشتراکی (Pro، Max، Team و Enterprise)، این مدل تا ۲۲ ژوئن بدون هزینه اضافه در دسترس است. از ۲۳ ژوئن، استفاده از آن نیاز به usage credit خواهد داشت. Anthropic اعلام کرده که به محض کافی شدن ظرفیت، Fable 5 را دوباره به‌عنوان بخش استاندارد پلن‌های اشتراکی اضافه خواهد کرد.

Claude Mythos 5 فعلاً تنها در اختیار شرکای Project Glasswing است و به زودی برای محققان زیست‌پزشکی تأییدشده نیز باز خواهد شد.

جمع‌بندی

Claude Fable 5 و Mythos 5 را می‌توان مهم‌ترین معرفی Anthropic در سال ۲۰۲۶ دانست — نه فقط به خاطر قدرت بیشتر، بلکه به خاطر رویکردی که پشت آن‌هاست.

برای اولین بار، یک شرکت هوش مصنوعی به جای اینکه یک مدل را به خاطر نگرانی‌های امنیتی کنار بگذارد یا بدون هیچ محدودیتی آن را منتشر کند، مسیر سومی را انتخاب کرد: انتشار با safeguardهای دقیق، ارجاع هوشمند به جای رد کردن، آزمون‌های امنیتی گسترده، و گسترش تدریجی دسترسی بر اساس اعتماد.

این الگو نشان‌دهنده بلوغ صنعتی است — و احتمالاً در مدل‌های آینده نیز استاندارد خواهد شد.

منبع: اعلامیه رسمی Anthropic، ۹ ژوئن ۲۰۲۶

هوش مصنوعی زمانی واقعاً هوشمند به نظر می‌رسد که بتواند شما را به خاطر بسپارد. یکی از بزرگ‌ترین مشکلات چت‌بات‌ها در سال‌های اخیر این بود که هر گفتگو را تقریباً از صفر آغاز می‌کردند و درک عمیقی از تاریخچه تعاملات کاربران نداشتند. حالا OpenAI با معرفی سیستم جدیدی به نام Dreaming قصد دارد این مشکل را برای همیشه حل کند.

در این مقاله بررسی می‌کنیم که Dreaming چیست، چگونه کار می‌کند، چه تفاوتی با سیستم حافظه قبلی ChatGPT دارد و چرا می‌تواند آینده دستیارهای هوش مصنوعی را متحول کند.

Dreaming چیست؟

Dreaming نسل جدید سیستم حافظه ChatGPT است که توسط OpenAI توسعه یافته است. این فناوری به ChatGPT اجازه می‌دهد به جای ذخیره چند یادداشت ساده درباره کاربر، یک تصویر پویا و به‌روز از علایق، پروژه‌ها، ترجیحات و نیازهای او ایجاد کند.

در نسخه‌های اولیه حافظه، ChatGPT تنها اطلاعاتی را ذخیره می‌کرد که کاربر مستقیماً از آن می‌خواست به خاطر بسپارد. اما Dreaming به صورت هوشمند تاریخچه گفتگوها را تحلیل می‌کند و اطلاعات مهم را در پس‌زمینه پردازش و سازماندهی می‌کند.

چرا سیستم حافظه قبلی کافی نبود؟

حافظه اولیه ChatGPT در سال 2024 معرفی شد و عملکردی شبیه به یک دفترچه یادداشت داشت. برای مثال اگر به ChatGPT می‌گفتید:

«یادم باشد ماه آینده به سنگاپور سفر می‌کنم.»

این موضوع ذخیره می‌شد و در گفتگوهای آینده قابل استفاده بود.

اما این روش چند مشکل اساسی داشت:

• بسیاری از اطلاعات مهم هرگز ذخیره نمی‌شدند.

• حافظه به مرور زمان قدیمی و غیرمرتبط می‌شد.

• تغییر شرایط کاربر به خوبی در حافظه منعکس نمی‌شد.

• سیستم توانایی تحلیل ارتباط میان اطلاعات مختلف را نداشت.

Dreaming چگونه کار می‌کند؟

برخلاف سیستم قدیمی، Dreaming صرفاً اطلاعات را ذخیره نمی‌کند؛ بلکه آن‌ها را به صورت مداوم بازبینی، خلاصه‌سازی و بازسازی می‌کند.

OpenAI توضیح می‌دهد که این سیستم از یک فرآیند پس‌زمینه برای ترکیب اطلاعات به دست آمده از گفتگوهای مختلف استفاده می‌کند تا یک حافظه یکپارچه و به‌روز از هر کاربر بسازد.

به زبان ساده:

1. ChatGPT گفتگوهای قبلی را تحلیل می‌کند.

2. اطلاعات مهم و پایدار را استخراج می‌کند.

3. موارد قدیمی یا منقضی شده را به‌روزرسانی می‌کند.

4. هنگام پاسخ‌گویی، فقط اطلاعات مرتبط را وارد مکالمه می‌کند.

این فرآیند باعث می‌شود حافظه ChatGPT بیشتر شبیه حافظه انسان عمل کند تا یک پایگاه داده ساده.

مهم‌ترین مزایای Dreaming

1. حفظ بهتر اطلاعات مهم

دیگر لازم نیست بارها و بارها اطلاعات یکسان را تکرار کنید.

اگر ChatGPT بداند که شما:

• برنامه‌نویس هستید

• به توسعه Full Stack علاقه دارید

• روی پروژه خاصی کار می‌کنید

می‌تواند در گفتگوهای بعدی پاسخ‌های دقیق‌تر و شخصی‌سازی‌شده‌تری ارائه دهد.

2. جلوگیری از قدیمی شدن حافظه

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

برای مثال اگر ChatGPT بداند شما در ماه جولای به سنگاپور سفر می‌کنید، پس از پایان سفر این اطلاعات به‌روزرسانی می‌شود و دیگر تصور نمی‌کند همچنان در آن کشور حضور دارید.

3. شخصی‌سازی بسیار بهتر

Dreaming باعث می‌شود ChatGPT:

• سبک نوشتاری شما را بهتر بشناسد

• علایق شما را درک کند

• پیشنهادهای مرتبط‌تری ارائه دهد

• در پروژه‌های بلندمدت عملکرد بهتری داشته باشد

این موضوع به‌خصوص برای توسعه‌دهندگان، تولیدکنندگان محتوا، دانشجویان و مدیران پروژه اهمیت زیادی دارد.

4. مقیاس‌پذیری بیشتر

OpenAI اعلام کرده معماری جدید Dreaming نسبت به نسخه‌های قبلی بسیار بهینه‌تر شده و هزینه پردازشی آن تا حدود 5 برابر کاهش یافته است. این موضوع امکان ارائه حافظه پیشرفته را برای تعداد بسیار بیشتری از کاربران فراهم می‌کند.

آیا کاربران روی حافظه کنترل دارند؟

بله.

OpenAI تأکید کرده است که کاربران همچنان می‌توانند:

• حافظه را مشاهده کنند

• اطلاعات ذخیره‌شده را حذف کنند

• حافظه را ویرایش کنند

• قابلیت Memory را غیرفعال کنند

• از Temporary Chat برای گفتگوهای بدون ذخیره‌سازی استفاده کنند.

آیا Dreaming نگرانی‌های حریم خصوصی ایجاد می‌کند؟

هر سیستم حافظه هوشمند طبیعتاً سوالاتی درباره حریم خصوصی ایجاد می‌کند.

هرچند OpenAI ابزارهای متعددی برای مدیریت حافظه در اختیار کاربران قرار داده است، اما برخی کاربران نسبت به خلاصه‌سازی خودکار اطلاعات شخصی و نحوه تفسیر آن‌ها توسط سیستم نگرانی‌هایی مطرح کرده‌اند. در برخی بحث‌های جامعه OpenAI نیز کاربران درباره نحوه تبدیل اطلاعات دقیق به خلاصه‌های کلی‌تر اظهار نظر کرده‌اند.

به همین دلیل آگاهی از تنظیمات Memory و مدیریت دوره‌ای اطلاعات ذخیره‌شده اهمیت زیادی خواهد داشت.

آینده ChatGPT با Dreaming

Dreaming فقط یک قابلیت جدید نیست؛ بلکه زیرساختی برای نسل آینده دستیارهای هوش مصنوعی محسوب می‌شود.

هدف OpenAI ساخت سیستمی است که بتواند در طول ماه‌ها و حتی سال‌ها همراه کاربران باشد، پروژه‌های آن‌ها را بشناسد، ترجیحاتشان را درک کند و با گذشت زمان مفیدتر شود.

اگر این مسیر موفق باشد، ChatGPT از یک چت‌بات ساده به یک دستیار دیجیتال واقعی تبدیل خواهد شد که نه‌تنها به سوالات پاسخ می‌دهد، بلکه شما، اهداف شما و شیوه کاری شما را نیز می‌شناسد.

جمع‌بندی

معرفی Dreaming یکی از مهم‌ترین به‌روزرسانی‌های تاریخ ChatGPT محسوب می‌شود. این فناوری با استفاده از حافظه پویا و خودبه‌روزرسان، مشکل فراموشی، کهنه شدن اطلاعات و شخصی‌سازی محدود را تا حد زیادی برطرف می‌کند.

در دنیایی که هوش مصنوعی به سمت دستیارهای دائمی و همراه حرکت می‌کند، حافظه هوشمند دیگر یک قابلیت جانبی نیست؛ بلکه یکی از مهم‌ترین ارکان تجربه کاربری خواهد بود. Dreaming دقیقاً در همین مسیر قرار گرفته است و می‌تواند آینده تعامل انسان و هوش مصنوعی را متحول کند.