نوشته ها

یک workflow سالم و خوب با AI در ۲۰۲۶ چه شکلیه

یک چیزی هست که کمتر کسی درباره‌اش حرف می‌زنه: AI coding tools می‌تونن به همون اندازه که کمک کنن، اگه باهاشون درست کار نکنی، اوضاع رو بدتر کنن. نه چون بد هستن — بلکه چون وقتی یه ابزار خیلی قوی داری و هنوز ندونی کِی ازش استفاده کنی، ممکنه در نهایت بیشتر وقتت صرف debug کردن چیزی بشه که خودت می‌تونستی سریع‌تر بنویسیش.

۲۰۲۶ از یه نظر نقطه‌ی عجیبیه. ابزارها از هر زمان دیگه‌ای بهترن، ولی noise هم از همیشه بیشتره. هر هفته یه agent جدید، یه model جدید، یه ادعای جدید که «این بار متفاوته». وسط این سروصدا، یه workflow سالم ربطی به اینکه از کدوم tool استفاده کنی نداره — ربط داره به اینکه چطور باهاشون فکر کنی.

اشتباه اول: context دادن به‌جای فکر کردن

آدم‌ها یه عادت دارن که بلافاصله وقتی به مشکل می‌خورن، می‌رن سراغ AI. این بد نیست — ولی مشکل اینه که اگه قبلش پنج دقیقه با خودت فکر نکرده باشی، مدل هم نمی‌دونه دقیقاً دنبال چی هستی. نتیجه یه جواب generic می‌شه که یا کامل نیست یا با context پروژه‌ات جور نیست.

یه قانون ساده: قبل از اینکه سراغ AI بری، یه جمله بنویس که مشکل رو توصیف کنه. فقط یه جمله. اگه نتونستی، یعنی هنوز نمی‌دونی مشکل چیه — و مدل هم نخواهد دونست.

اشتباه دوم: agent بدون context

agentها — Hermes، Claude Code، Codex — وقتی می‌دونن پروژه چیه، قبلاً چی شده، و چه محدودیت‌هایی وجود داره، خیلی بهتر کار می‌کنن. ولی بدون این context، حتی یه agent خوب هم می‌تونه چیزی بسازه که technically درسته ولی با معماری پروژه‌ات جور نیست.

راه‌حل‌هایی مثل skill file ها برای همین اومدن: به‌جای اینکه هر بار از اول توضیح بدی، یه بار درست توضیح می‌دی و می‌ذاریش جایی که agent هر وقت لازم بود بخونتش. این ساده‌ترین روشیه که workflow ات رو از «هر بار از صفر» به «agent می‌دونه کجاست» تبدیل می‌کنه.

اشتباه سوم: باور کردن خروجی بدون review

این شاید از همه‌شون خطرناک‌تره. مدل‌ها اشتباه می‌کنن — و اشتباهاتشون معمولاً خیلی مطمئن به نظر می‌رسن. کدی که مدل نوشته رو نخونده commit نکن. نه به‌خاطر اینکه کد بد باشه — بلکه چون review کردن کد همونی هست که باعث می‌شه تو بفهمی چی ساخته شده. اگه این رو skip کنی، چند هفته دیگه یه codebase داری که نمی‌دونی داخلش چیه.

این یه قانون نیست که هر خط رو خودت بنویسی. قانون اینه که هر خطی رو که merge می‌کنی، بدونی چیکار می‌کنه.

یه workflow که در عمل کار می‌کنه

یه الگوی ساده که در عمل جواب داده:

برای کارهای کوچیک (یه function، یه refactor کوچیک، یه bug): مستقیم از chat استفاده کن. context لازم نیست زیاد باشه، نتیجه سریعه، و راحت review می‌شه.

برای کارهای متوسط (یه feature جدید، یه سرویس): یه prompt با جزئیات کافی بنویس — معماری، محدودیت‌ها، output مورد انتظار. بعد خروجی رو بگیر و review کن. اگه چیزی جا افتاده یا جور نیست، iteration کن.

برای کارهای بزرگ و پیچیده: اینجاست که agent ها معنی پیدا می‌کنن. یه agent مثل Hermes یا Claude Code می‌تونه یه task چندمرحله‌ای رو مدیریت کنه — ولی فقط اگه بهش context کافی بدی، skill های مرتبط بهش دادی، و حواست به کارش باشه. «بذار agent همه چیز رو بسازه و من بعداً نگاه کنم» یه workflow نیست — یه روش برای ساختن چیزیه که نمی‌فهمیش.

درباره‌ی دسترسی و مرزها

یه چیزی که از تجربه‌ی مستقیم یاد گرفتم: به agent هایی که به filesystem دسترسی دارن، sudo ندید. نه به‌خاطر اینکه agent بد نیت داره — بلکه چون وقتی یه task پیچیده انجام می‌ده و اشتباه می‌کنه، sudo یعنی اشتباهش جبران‌ناپذیره. یه دیتابیس محلی پاک می‌شه. یه پوشه حذف می‌شه. این چیزیه که «بعید نیست» — اتفاق می‌افته.

محدود کردن دسترسی یه لایه‌ی safety net هست، نه بی‌اعتمادی به ابزار.

درباره‌ی مدل‌ها و هزینه

اکثر کارهای روزانه‌ی یه توسعه‌دهنده‌ی معمولی به بهترین و گران‌ترین مدل نیاز ندارن. توضیح یه مفهوم، بررسی یه کد، نوشتن یه test، refactor کوچیک — اینا رو مدل‌های ارزون‌تر هم خوب انجام می‌دن.

جاهایی که مدل قوی‌تر فرق می‌کنه: وقتی task پیچیده‌ست و نیاز به چندین مرحله reasoning داره، وقتی context بزرگه، یا وقتی agent باید خودش تصمیم بگیره چه مرحله‌ای بعدی باشه. برای بقیه، مدل ارزان‌تر کافیه — و ترکیب ابزارهایی مثل 9Router با agentها می‌تونه هزینه رو به حداقل برسونه.

یه جمله خلاصه

workflow سالم با AI یعنی تو هنوز توسعه‌دهنده‌ای — ابزار هم بیشتر شده. یعنی هنوز می‌فهمی چی می‌سازی، هنوز review می‌کنی، و هنوز تصمیم می‌گیری. AI سرعت رو بالا می‌بره — ولی اگه فقط سرعت بالا بره بدون اینکه بفهمی داری کجا می‌ری، سریع‌تر گم می‌شی.

Wayland در برابر X11: چرا همه دارن مهاجرت می‌کنن و آیا واقعاً ارزشش رو داره؟

یه حقیقت ساده از همون اول: اگه شش ماه پیش لینوکس نصب کردی روی یه ماشین معمولی، احتمالاً الان روی Wayland هستی — حتی اگه ندونی. Fedora 40+، Ubuntu 24.04+، Arch، GNOME 49، و KDE Plasma 6 همه به‌صورت پیش‌فرض به Wayland رفتن. این دیگه یه بحث «آینده‌ی Linux» نیست. این وضعیت الان هست.

سوال واقعی اینه که چرا این اتفاق افتاد، چه چیزی هنوز نشکسته، و چه کسی نباید عجله کنه.

X11 چه مشکلی داشت

X11 در ۱۹۸۴ طراحی شد — و معماریش دقیقاً همون‌قدر که از اون زمان انتظار داری، قدیمیه.

مدل کار اینه که یه X server مرکزی وجود داره. هر برنامه برای رندر کردن چیزی به صفحه، یه درخواست می‌فرسته به X server، X server اون رو به compositor می‌ده، compositor نهایی می‌کنه. مشکل اینه که این X server مرکزی همه چیز رو می‌بینه: هر کیبورد فشرده‌شده، هر حرکت ماوس، هر پنجره‌ای که بازه. هر اپلیکیشن هم می‌تونه از X server بخواد ورودی اپ‌های دیگه رو بخونه. یعنی keylogger نوشتن روی X11 یه کار ده خطیه.

اوایل ۲۰۲۵ سه آسیب‌پذیری بحرانی (CVE-2025-62229، CVE-2025-62230، CVE-2025-62231) توی X.Org پیدا شد — باگ‌هایی که بعضی‌هاشون از بیست سال پیش توی کد بودن. اینا isolated incident نبودن؛ نشونه‌ی یه codebase چهل‌ساله‌ان که maintenance-only شده. هیچ توسعه‌ی فعالی روی X.Org اتفاق نمی‌افته — فقط security patch.

مشکل معماری دیگه‌ای هم وجود داره: رندرینگ کند. هر frame باید از برنامه به X server و بعد به compositor بره — این double-buffering بی‌دلیل توی hardware مدرن کاملاً غیرضروریه و توی بعضی حالت‌ها باعث tearing می‌شه.

Wayland چطور متفاوته

Wayland یه «سرور» مرکزی نداره. هر اپلیکیشن مستقیم به یه off-screen buffer رندر می‌کنه، و compositor مستقیم با driver کار می‌کنه تا frame نهایی رو به مانیتور بفرسته. واسطه نیست.

نتیجه‌های عملی این معماری:

امنیت: هر اپلیکیشن فقط ورودی‌های خودش رو می‌بینه. keylogger نوشتن روی Wayland از طریق protocol عملاً غیرممکنه. البته XWayland — که X11 appها رو روی Wayland اجرا می‌کنه — همچنان این ایزوله‌سازی رو نداره، ولی native Wayland appها ندارن.

رندر تمیزتر: چون compositor مستقیم با GPU کار می‌کنه، screen tearing توی حالت‌های معمولی اتفاق نمی‌افته. توی سیستم‌های با refresh rate بالا یا HiDPI این فرق محسوسه.

npm 12 اومد — سه تغییری که ممکنه build‌ رو خراب کنه

اگه توی تیمت کسی هست که هنوز از 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

Hermes Agent: یک agent رایگان که میتونه کارای جالبی انجام بده

یه اعتراف صادقانه قبل از شروع: آنچه روی کاغذ درباره‌ی Hermes Agent نوشته شده — که «به‌طور خودکار یاد می‌گیره» — دقیقاً اون‌طوری که ادعا می‌شه کار نمی‌کنه. skill document می‌سازه، ولی به اون شکل خودکار و بی‌دردسری که تبلیغش می‌شه نیست. این رو از تجربه‌ی مستقیم می‌گم، نه از بنچمارک.

ولی اگه این انتظار رو کنار بذاری و بفهمی که Hermes واقعاً چی هست، یکی از بهترین agentهای open-source ای خواهد بود که امتحان کردی.

واقعیت: چقدر prompting می‌خواد

Hermes بدون توضیح درست کار نمی‌کنه. اگه prompt کوتاه و مبهم بدی، نتیجه متناسبه. ولی اگه یه prompt با جزئیات کافی بدی — دقیقاً مشخص کنی چی می‌خوای، چه محدودیت‌هایی داره، output چه شکلی باشه — آنچه در ادامه انجام می‌ده می‌تونه واقعاً چشم‌گیر باشه. کارهای طولانی، پیچیده، و چندمرحله‌ای که معمولاً agent‌های دیگه یا نصفه رها می‌کنن یا خراب تموم می‌کنن.

این یعنی Hermes «agent برای همه» نیست. agent‌ای است که با یه اپراتور حواس‌جمع، خوب کار می‌کنه.

ترکیب با 9Router: چرا مهمه

جذاب‌ترین بخش ماجرا اینجاست: Hermes با هر OpenAI-compatible endpoint ای کار می‌کنه. یعنی می‌تونی 9Router رو جلوش بذاری و از مدل‌های رایگان یا ارزون استفاده کنی — و Hermes همون کاری رو می‌کنه که با Claude یا GPT-4 انجام می‌داد.

عملاً می‌شه از agentی استفاده کرد که performance‌اش به agentهای گرون نزدیکه، با هزینه‌ای که نزدیک به صفره. این ترکیب رو امتحان کردم و کار می‌کنه.

skill ها: چیزی که واقعاً ارزش داره

یه چیز که در عمل خیلی کاربرد داشت، سیستم skill هست — نه اون چیزی که agent خودش می‌سازه، بلکه skill هایی که خودت با Claude می‌سازی و بهش می‌دی. می‌تونی یه workflow پیچیده رو یه بار به‌درستی توصیف کنی، بذاریش توی یه skill، و بعد هر بار که Hermes به اون task می‌رسه، از همون توصیف استفاده کنه. این‌طوری دیگه لازم نیست هر بار از اول توضیح بدی.

چیزی که کشف کردم: sudo ندید

یه هشدار جدی: دسترسی sudo بهش ندید.

نه به‌خاطر اینکه مشکل امنیتی عجیبی داره — بلکه چون agent وقتی روی یه task پیچیده کار می‌کنه، ممکنه اشتباه کنه. و اگه sudo داشته باشه، اشتباهش می‌تونه جبران‌ناپذیر باشه. از تجربه‌ی مستقیم: یه دیتابیس محلی پاک شد. بعیدترین اتفاق ممکن بود ولی افتاد.

9Router: وقتی rate limit دیگه نمی‌تونه جلوی کار کردن رو بگیره

یه اتفاق آشناست: وسط یه session طولانی با Claude Code یا Codex، یه پیام می‌بینی که quota تموم شده. نه اینکه کارت تموم شده — quota تموم شده. بعد یا باید صبر کنی تا reset بشه، یا دستی بری سراغ یه provider دیگه، یا tool رو ببندی و بری سراغ یه API key دیگه.

9Router برای همین مشکل ساخته شده. یه gateway محلی که بین ابزار AI تو و بیش از ۶۰ provider قرار می‌گیره، و وقتی یه provider به سقف رسید، خودکار به یه جایگزین می‌ره — بدون اینکه لازم باشه چیزی بزنی یا session رو قطع کنی.

ایده‌ی اصلی: سه tier، یه fallback خودکار

9Router روی یه مدل routing سه‌لایه کار می‌کنه:

Tier 1 — Subscription: اشتراک‌هایی که از قبل داری. Claude Code، OpenAI Codex، GitHub Copilot، Cursor. اگه اشتراک داری، 9Router اول از اینها استفاده می‌کنه.

Tier 2 — Cheap: مدل‌هایی که API key می‌خوان ولی ارزونن. GLM به ازای هر میلیون توکن ۰.۶۰ دلار، MiniMax M2.7 به ازای هر میلیون توکن ۰.۲۰ دلار، Kimi با ۹ دلار در ماه. وقتی Tier 1 تموم شد، اینجا میاد.

Tier 3 — FREE: iFlow، Qwen، Kiro، OpenCode. کاملاً رایگان و بدون محدودیت ثابت. آخرین سنگر.

وقتی quota یه provider در Tier 1 تموم می‌شه، 9Router خودکار به Tier 2 می‌ره. وقتی Tier 2 هم تموم شد، به Tier 3 می‌ره. از نظر tool تو — Cursor، Cline، Claude Code — هیچ اتفاقی نیفتاده. همون endpoint جواب می‌ده.

نصب و راه‌اندازی

npm install -g 9router
9router

همین. یه dashboard محلی باز می‌شه که می‌تونی providerها رو اضافه کنی — OAuth برای اشتراک‌ها، API key برای بقیه. بعد هر tool ای که داری رو به این endpoint اشاره بده:

http://localhost:20128/v1

Rust 1.97.0 منتشر شد

۹ جولای ۲۰۲۶، تیم 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 جدید اضافه شده:

Muse Spark 1.1: متا وارد بازار API پولی شد

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

متا سال‌ها روی 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 بزرگ و قیمت معقول داشته باشه، جای جالبیه.

TypeScript 7 Stable منتشر شد و حدودا ۱۰ برابر سریع تره

۸ جولای ۲۰۲۶، مایکروسافت نسخه‌ی 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

Next.js 16.3 Turbopack: وقتی dev server دیگه ۲۱ گیگ رم نمی‌خوره

اگه روی یه پروژه‌ی 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 که پروژه‌ی سنگین‌تریه، بهبود کمتره: از ۶۶ به ۴۶ ثانیه.

TypeScript 7 اومد — این بار کامپایلر با Go نوشته شده

اگه یه پروژه‌ی 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 شده بودن:

Next.js 16.3: AI Improvements وقتی فریمورک برای ایجنت ها طراحی می شه

یه چیز جالب داره توی فضای توسعه نرم‌افزار اتفاق می‌افته: یه بخش قابل‌توجه از کدی که توی 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‌ها دست‌نخورده می‌مونه.

Next.js 16.3: وقتی اپ سرور-محورت مثل SPA رفتار می‌کنه

یه انتقاد قدیمی به Next.js وجود داشته که هرچقدر هم منطقی باشه، همیشه کمی ناراحت‌کننده بود: وقتی روی یه لینک کلیک می‌کنی، چیزی نمی‌شه. صفحه فقط منتظر می‌مونه تا سرور جواب بده، بعد یهو همه چیز ظاهر می‌شه. این رفتار برای یه بلاگ یا سایت خبری کاملاً قابل قبوله، ولی برای یه اپ داشبورد یا پروداکتیو، حس می‌ده داری از سایت‌های دهه نود استفاده می‌کنی.

در حالی که SPAها از روز اول همین مشکل رو حل کرده بودن: کلیک می‌کنی، یه shell از صفحه‌ی بعدی بلافاصله نشون داده می‌شه — حتی اگه داده‌ها هنوز دارن لود می‌شن. این حس «instant» بودن چیزیه که خیلی از توسعه‌دهنده‌ها رو به سمت SPAها می‌کشه، حتی وقتی می‌دونن که مدل سرور-محور Next.js از نظر فنی برتری‌های زیادی داره.

۲۵ ژوئن ۲۰۲۶، تیم Next.js یه پیش‌نمایش از نسخه‌ی ۱۶.۳ منتشر کرد که مستقیماً همین مشکل رو هدف گرفته: Instant Navigations.

ایده‌ی اصلی چیه

وقتی یه route توی Next.js به داده‌ای از سرور await می‌کنه، سه گزینه داری:

Stream با <Suspense>: کاربر بلافاصله یه loading shell می‌بینه و داده‌ها بعداً stream می‌شن. navigation ایمدیت، داده‌ها دیرتر.

Cache با 'use cache': کاربر یه UI کش‌شده‌ی قبلی رو می‌بینه، تا زمانی که نسخه‌ی جدید آماده بشه. باز هم navigation ایمدیت.

Block با export const instant = false: بگی این route نباید instant باشه — مثلاً یه بلاگ که نمی‌خوای shell خالی صفحه‌ی پست رو نشون بده. navigation منتظر سرور می‌مونه.

دو گزینه‌ی اول navigation رو به حالت SPA-like در میارن. گزینه‌ی سوم اختیارى‌ه و بهت کنترل می‌ده.

برای فعال کردنش، یه flag توی next.config.ts اضافه می‌کنی:

const nextConfig: NextConfig = {
  cacheComponents: true,
};

این flag قراره در یه major version آینده به حالت default تبدیل بشه.

prefetching رو هم از اول طراحی کردن

متد QUERY در HTTP: وقتی GET و POST هیچ‌کدوم جواب نمی‌دن

یه سوال قدیمی توی طراحی API وجود داشت که همه باهاش کنار اومده بودن: وقتی می‌خوای یه query پیچیده بفرستی و چیزی رو بخوانی — نه تغییر بدی — چه متدی استفاده می‌کنی؟ GET بدنه نداره، POST هم از نظر پروتکل یعنی «دارم یه چیزی رو تغییر می‌دم». نتیجه؟ همه یه endpoint مثل POST /search می‌ساختن و ادامه می‌دادن.

ژوئن ۲۰۲۶، IETF این مشکل رو رسمی حل کرد. RFC 10008 تاریخ ۱۵ ژوئن ۲۰۲۶ منتشر شد و متد جدیدی به اسم QUERY رو برای HTTP تعریف می‌کنه. این اولین متد کاملاً جدید HTTP در حدود ۱۶ سال گذشته است.

مشکل واقعی چی بود

GET برای درخواست‌های read-only ایده‌آله، ولی یه محدودیت بزرگ دارد: همه چیز باید توی URL باشد. برای یه فیلتر ساده مثل ?city=Berlin&limit=50 کافیه، ولی وقتی query پیچیده می‌شود — مثلاً یه فیلتر تو در تو با چند شرط، یا یه کوئری SQL کامل — URL به سرعت به جایی می‌رسد که دیگر نمی‌توان باهاش کار کرد. RFC 9110 فقط توصیه می‌کند که پیاده‌سازی‌ها حداقل ۸۰۰۰ بایت URI را پشتیبانی کنند، و این یه کف است، نه یه تضمین. محدودیت واقعی را وقتی کشف می‌کنی که پشت یه پراکسی یا لود بالانسر قدیمی هستی — و test suite‌ات آن را نشان نمی‌دهد.

POST هم یه راه‌حل دیگر بود، ولی از نظر پروتکل HTTP مشکل داشت.POST نه safe هست و نه idempotent. وقتی connection وسط درخواست قطع می‌شود، نه client نه هیچ پراکسی‌ای نمی‌تواند بداند که آیا state روی سرور عوض شده یا نه. در نتیجه هیچ‌چیزی به‌طور خودکار retry نمی‌کنه. علاوه بر این، cache هم برای POST کار نمی‌کند — هر بار باید به origin برگردد.

یه مشکل ظریف‌تر هم بود که کمتر بهش توجه می‌شد: URL ها leak می‌کنند. request URI‌ها بیشتر از request body توی log‌ها ثبت می‌شوند. اگه query ات اطلاعات حساسی دارد، الان توی هر access log در طول مسیر است.

QUERY چطور این مشکل‌ها رو حل می‌کنه

QUERY دقیقاً همان چیزی است که GET و POST هیچ‌کدام نبودند: یه درخواست safe، idempotent و cacheable که بدنه هم دارد.

QUERY /contacts HTTP/1.1
Content-Type: application/json

{
  "filter": { "city": "Berlin" },
  "limit": 50
}

Fable 5 برگشت، Sonnet 5 اومد - و ما باید با یه پرامپت و نصفی کنار بیایم

۹ ژوئن، آنتروپیک 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ها رو برای پلن‌های مختلف افزایش داده، ولی در تستی که من انجام دادم در مدل رایگان جدید واقعا اینطور بنظر نیومد.

مدیریت متغیرهای محیطی در Next.js

وقتی روی یک پروژه بزرگ یا حتی یک وب‌سایت شخصی کار می‌کنید، اطلاعات حساسی مثل کلیدهای API (API Keys)، آدرس دیتابیس‌ها و رمزهای عبور وجود دارن که به هیچ وجه نباید به صورت مستقیم (Hard-code) داخل کدهای شما قرار بگیرن. قرار دادن این اطلاعات داخل کد، نه تنها امنیت پروژه رو به خطر می‌اندازه، بلکه فرآیند تغییر اون‌ها را در محیط‌های مختلف (مثل محیط توسعه و محیط پروداکشن) به یک چالش بزرگ تبدیل می‌کنه.
اینجاست که فایل‌های .env به کار میان. در این مقاله می‌خوایم بررسی کنیم که فریم‌ورک Next.js چطور کار با متغیرهای محیطی رو برای ما راحت کرده، این فایل‌ها چه اولویت‌هایی دارن و چطور می‌تونیم به بهینه‌ترین شکل ممکن از اون‌ها استفاده کنیم.
چطور فایل‌های .env زندگی ما رو راحت‌تر می‌کنن؟
به زبان ساده، متغیرهای محیطی به شما اجازه میدن تنظیمات پروژه رو از خودِ کد جدا کنید. Next.js به صورت پیش‌فرض و بدون نیاز به نصب هیچ پکیج اضافی (مثل dotenv)، از این فایل‌ها پشتیبانی می‌کنه.
شما می‌تونید چندین فایل .env برای سناریوهای مختلف داشته باشید، اما نکته مهم اینه که بدونید Next.js با چه ترتیبی و بر اساس چه اولویتی این فایل‌ها رو می‌خونه.
ترتیب اولویت فایل‌های .env در Next.js (از بیشترین به کمترین):
نکست‌جی‌اس برای جابجایی بین محیط‌های مختلف (توسعه، پروداکشن و تست) بسیار هوشمند عمل می‌کنه. ترتیب خونده شدن فایل‌ها به این صورت هستش:
فایل‌های اختصاصی محیط با پسوند .local: مثل .env.development.local یا .env.production.local. این فایل‌ها بالاترین اولویت رو دارن و معمولاً در سیستم هر برنامه‌نویس به صورت محلی ذخیره می‌شن و نباید به گیت‌هاب push بشن.
فایل .env.local: این فایل در تمامی محیط‌ها (به جز محیط تست) اولویت بسیار بالایی داره و برای تعریف متغیرهای محلی عمومی استفاده میشه.
فایل‌های اختصاصی محیط: شامل .env.development (وقتی دستور next dev رو می‌زنید)، .env.production (وقتی پروژه با next start بالا میاد) و . نکست‌جی‌اس بر اساس وضعیت پروژه، از این فایل‌ها رو انتخاب می‌کنه و بقیه رو کاملاً نادیده می‌گیره. پایین‌ترین اولویت رو داره. این فایل به عنوان یک نسخه‌ی پشتیبان (Fallback) عمل می‌کنه؛ یعنی اگر متغیری در فایل‌های بالایی پیدا نشه، نکست‌جی‌اس این فایل رو چک می‌کنه.

OpenAI از GPT-5.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 هم در پست رسمی‌اش صریح گفته که این رویکرد را راه‌حل بلندمدت نمی‌داند و آن را موقتی می‌خواند، اما معتقد است این مسیر سریع‌ترین راه برای رسیدن به انتشار عمومی در هفته‌های آینده است.