محافظ صفحه‌ی ⁦iPhone⁩ تاشو لو رفت و یه سری جزئیات تازه ازش بیرون اومد.

حاشیه‌های صفحه‌ی بیرونی متقارن نیستن — سمت چپ زاویه‌داره و سمت راست گرد شده. دوربین سلفی هم برعکس انتظار رفته گوشه‌ی راست.

جالب‌تر اینکه مارک گورمن گفته تو خودِ اپل، همه به این گوشی می‌گن ⁦iPhone Ultra.⁩

⁦#⁩آیفون_تاشو ⁦#iPhoneUltra⁩

«اگه ⁦opt-in⁩ بود، هیچ‌کس انتخابش نمی‌کرد» — این رو ⁦Mike Minton⁩، مدیر ارشد محصول ⁦Twitch⁩، توی یه پخش زنده گفت وقتی ازش پرسیدن چرا گزینه آموزش ⁦AI⁩ به صورت پیش‌فرض روشنه.

پلتفرم ⁦Twitch⁩ روز ۱۲ اوت اعلام کرد استریمرها می‌تونن جلوی استفاده ⁦Amazon⁩ از محتوای کانالشون برای آموزش ⁦AI⁩ رو بگیرن — اما این گزینه از اول روشنه و باید خودت بری خاموشش کنی.

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

برای خاموش کردن باید بری توی تنظیمات ⁦Security and Privacy⁩ حساب کاربریت و گزینه "⁦Training for Generative AI⁩" رو خاموش کنی. با این کار ⁦Amazon⁩ دیگه از استریم‌های زنده، ویدیوهای قبلی، کلیپ، هایلایت، لاگ چت و تصاویر کانالت برای آموزش ⁦AI⁩ استفاده نمی‌کنه.

واکنش جامعه استریمرها تند بوده — یه کامنت توی فروم پشتیبانی که خواسته این گزینه ⁦opt-in⁩ بشه، نزدیک ۱۴,۰۰۰ رأی مثبت گرفته.

پلتفرم ⁦Twitch⁩ متعلق به ⁦Amazon⁩ هست و مثل خیلی پلتفرم‌های دیگه — از سایت‌های عکس استاک تا شبکه‌های اجتماعی — محتوای کاربران رو بی‌سروصدا برای آموزش ⁦AI⁩ استفاده کرده، بعد که لو رفته یه گزینه ⁦opt-out⁩ اضافه کرده و اسمش رو «بهبود حریم خصوصی» گذاشته.

اما این بار یه چیز متفاوت بود: مدیر ارشد محصول آشکارا گفت که دیفالت ⁦opt-out⁩ انتخاب شده چون غیر از این داده کافی برای آموزش جمع نمی‌شد. خیلی کم پیش میاد یه مدیر ارشد این حرف رو صادقانه بزنه.

این مطلب مخصوص برنامه‌نویس‌ها و کسایی هست که با ⁦API⁩ کار می‌کنن.

شرکت ⁦OpenAI⁩ یه سطح جدید از سرویس ⁦API⁩ راه انداخته به اسم ⁦Ultrafast⁩ که مدل ⁦GPT-5.6 Sol⁩ رو با سرعت تا ۷۵۰ ⁦Token⁩ در ثانیه اجرا می‌کنه. برای مقایسه، حالت ⁦Standard⁩ همین مدل الان حدود ۵۳ ⁦Token⁩ در ثانیه داره — یعنی ⁦Ultrafast⁩ تقریباً ۱۴ برابر سریع‌تره.

برای ملموس‌تر شدن این عدد: یه مقاله ۱۰۰۰ کلمه‌ای که توی حالت ⁦Standard⁩ حدود ۱۸ ثانیه طول می‌کشه، توی ⁦Ultrafast⁩ زیر ۲ ثانیه آماده می‌شه.

این سرعت از یه مشارکت با ⁦Cerebras⁩ به دست اومده — استارتاپی که به جای خوشه‌ای از ⁦GPU⁩ های معمولی، از یه تراشه‌ی عظیم ۹۰۰ میلی‌متر مربعی استفاده می‌کنه که کل پردازش روی یه قطعه انجام می‌شه، نه روی چند تا چیپ کنار هم. ⁦Ultrafast⁩ اولین محصول تجاری این مشارکته.

شرکت ⁦OpenAI⁩ می‌گه هدف از ⁦Ultrafast⁩ اینه که برنامه‌نویس‌ها دیگه مجبور نباشن برای کارهای ⁦real-time⁩ از مدل‌های کوچیک‌تر و ضعیف‌تر استفاده کنن. کاربردهایی که خودشون مطرح کردن: پاسخ به حوادث امنیتی، خدمات مشتری، تحلیل بازارهای مالی، و پیشنهاد محصول توی فروشگاه‌های آنلاین — همه جاهایی که تأخیر زیاد باعث می‌شد از مدل‌های ⁦frontier⁩ فرار کنن.

دسترسی از ۱۳ اوت به صورت محدود برای بعضی مشتریان ⁦API⁩ باز شده و ظرفیت به تدریج گسترش پیدا می‌کنه. قیمت‌گذاری جداگانه‌ای هنوز اعلام نشده.

یه اشتباهِ رایج که تقریباً همه توش می‌افتن: وقتی ⁦AI⁩ یه جوابِ اشتباه یا ناکافی می‌ده، می‌مونن توی همون مکالمه و سعی می‌کنن درستش کنن. نتیجه؟ ده پیامِ رفت‌وبرگشت و در آخر یه خروجیِ نصفه‌نیمه.

مکالمه‌های ⁦AI⁩ یه نوع اینرسی دارن. هر چیزی که اوایلِ مکالمه شکل گرفته، بقیه‌اش رو تحت‌تأثیر قرار می‌ده. ⁦AI⁩ به اون تفسیرِ اولیه‌اش می‌چسبه و حتی وقتی درستش می‌کنی، زیرِ پوست همون رویکردِ اول باقی می‌مونه.

مثال واقعی: داری با ⁦Claude⁩ روی طراحیِ یه سیستمِ ارسالِ ایمیل کار می‌کنی. پنج پیام بعد می‌فهمی ⁦AI⁩ همه چیزو برای هزار کاربر طراحی کرده، ولی تو صد هزار کاربر داری. اگه توی همون مکالمه بگی «مقیاسم بزرگ‌تره»، ⁦AI⁩ راه‌حلِ قبلیشو ⁦patch⁩ می‌کنه — همون معماری رو بزرگ‌تر می‌دوزه، به جای اینکه از صفر یه چیزِ مناسب بسازه.

راه‌حل: مکالمه رو ببند. یه پنجره‌ی جدید باز کن. این بار با اطلاعاتِ کامل‌تری که از رفت‌وبرگشتِ قبلی یاد گرفتی شروع کن:

«می‌خوام یه سیستمِ ارسالِ ایمیل برای صد هزار کاربر طراحی کنم. مهم‌ترین محدودیتم اینه که [⁦X⁩].»

یه مکالمه‌ی تازه با یه ⁦Prompt⁩ دقیق‌تر، اکثرِ مواقع بهتر از پانزده پیام توی یه ⁦thread⁩ِ کج‌رفته کار می‌کنه.

قانونِ کلی اینه: اگه تا پیامِ سوم ⁦AI⁩ داره به سمتِ اشتباه می‌ره، بیا بیرون. چیزی که از اون مکالمه یاد گرفتی رو بردار، یه ⁦Prompt⁩ بهتر بنویس، از صفر شروع کن. ⚡

قیمت ⁦Switch 2⁩ از اول سپتامبر در آمریکا ۵۰ دلار گران‌تر می‌شه — از ۴۴۹.۹۹ دلار به ۴۹۹.۹۹ دلار. کانادا هم ۵۰ دلار کانادایی اضافه می‌شه و اروپا ۳۰ یورو. قیمت بازی‌ها و لوازم جانبی فعلاً تغییری نمی‌کنه.

دلیل این گرانی یه اتفاق عجیبه: ⁦AI⁩ داره حافظه‌ی دنیا رو می‌خوره. کارخانه‌های تولید تراشه‌های حافظه (⁦DRAM⁩ و ⁦NAND flash⁩) ظرفیت محدودی دارن. تقاضای عظیم دیتاسنترهای ⁦AI⁩ برای همین تراشه‌ها — برای آموزش مدل‌ها و اجرای اونا — اونقدر بالا رفته که سهم بخش مصرفی کم شده و قیمت‌ها رفته بالا. وقتی یه کارخونه داره تراشه می‌پزه، یا برای سرورهای ⁦AI⁩ می‌زنه یا برای کنسول‌ها — و الان ⁦AI⁩ خیلی بیشتر می‌خره.

شرکت ⁦Nintendo⁩ نگفته این وضعیت موقتیه. عبارتی که به کار برده — «تغییرات بازار که در میان‌مدت تا بلندمدت ادامه دارن» — یعنی انتظار ندارن اوضاع زود به حالت عادی برگرده. ظرفیت کارخانه‌های تراشه‌سازی هم به این زودی‌ها قابل گسترش نیست، یعنی این عدم‌توازن می‌تونه تا ۲۰۲۷ هم ادامه داشته باشه.

کنسول ⁦Nintendo⁩ هم اولین قربانی این جریان نیست؛ ⁦PlayStation 5⁩، ⁦Xbox Series X⁩ و ⁦Steam Deck OLED⁩ هم امسال به همین دلیل گران‌تر شدن. چون همه‌ی این دستگاه‌ها از همین تراشه‌ها استفاده می‌کنن، گزینه‌ی ارزون‌تری هم نیست که بشه به‌جاشون رفت. جالبه که صنعت بازی دهه‌هاست عادت داشته قیمت کنسول‌ها بعد از عرضه کم‌کم پایین بیاد — الان داریم برعکسشو می‌بینیم.

اگه خرید ⁦Switch 2⁩ تو برنامه‌ته، قبل از اول سپتامبر خریدنش قیمت فعلی رو قفل می‌کنه.

🔧 این پست فنیه — مخصوصِ کسایی که مدل ⁦AI⁩ رو روی سرور خودشون بالا می‌آرن (بک‌اند، ⁦DevOps⁩، ⁦MLOps⁩). اگه جزو این دسته نیستی، فقط چند خط اولش رو بخون؛ توضیح می‌ده پشت صحنه‌ی سرویس‌هایی مثل ⁦ChatGPT⁩ چه خبره.
━━━━━━━━━━

فرض کن یه مدل زبانی رو روی سرور خودت بالا آوردی — مثلاً با ⁦vLLM⁩ — و چند نفر همزمان دارن ازش استفاده می‌کنن. یه ⁦Nginx⁩ یا ⁦HAProxy⁩ هم جلوش گذاشتی که ترافیک رو پخش کنه. تا اینجا همه‌چی عادیه.

مشکل از جایی شروع می‌شه که این پروکسی‌ها فقط «تعداد درخواست» رو می‌شمرن. برای ⁦Nginx⁩، یه پیام ۱۰ کلمه‌ای با یه سند ۱۰ هزار توکنی دقیقاً یکیه: هر دو «یک درخواست» حساب می‌شن.

ولی ⁦GPU⁩ اینجوری حساب نمی‌کنه. چیزی که روی کارت گرافیک ته می‌کشه تعداد اتصال نیست، حافظه‌ی خودِ کارته — بخشی از اون که به ⁦KV-cache⁩ اختصاص داده می‌شه. مدل موقع نوشتن جواب، محاسبه‌های مربوط به توکن‌های قبلی رو اونجا نگه می‌داره تا مجبور نشه هر بار از اول حسابشون کنه. هرچی متن طولانی‌تر بشه، این بخش بیشتر پر می‌شه.

نتیجه اینه: یه‌دفعه چند درخواست سنگین با هم می‌رسن، ⁦KV-cache⁩ پر می‌شه، تأخیر می‌ره بالا و در بدترین حالت سرور با خطای ⁦OOM⁩ می‌خوابه — درحالی‌که پروکسیِ جلوش داره گزارش می‌ده همه‌چی سبزه.

یه ابزار متن‌باز به اسم ⁦TokenFlow Gateway⁩ دقیقاً برای همین ساخته شده. کاری که می‌کنه اینه: پروکسی رو از شمردنِ درخواست‌ها می‌ندازه و می‌بردش سراغ شمردنِ توکن‌ها.

▪️ قبل از فرستادن، وزن هر درخواست رو حساب می‌کنه — توکن ورودی به‌علاوه‌ی حداکثر خروجی؛ یعنی همون حافظه‌ای که ⁦GPU⁩ باید واقعاً کنار بذاره
▪️ به‌جای ⁦round-robin⁩، از روی آمار زنده‌ی ⁦KV-cache⁩ تصمیم می‌گیره: درخواست سنگین می‌ره سراغ آزادترین سرور، درخواست‌های سبک کنار هم روی سرورهای شلوغ‌تر جا می‌شن
▪️ وقتی هیچ سروری جا نداره، درخواست به‌جای اینکه ⁦GPU⁩ رو بخوابونه، توی یه صف اولویت‌دار روی ⁦Redis⁩ منتظر می‌مونه
▪️ جواب‌های تکراری رو کش می‌کنه، هم دقیق و هم معنایی — یعنی سؤال تکراری اصلاً به ⁦GPU⁩ نمی‌رسه
▪️ محدودیت مصرف رو بر اساس توکن در دقیقه می‌ذاره، نه فقط تعداد درخواست؛ همون مدلی که ⁦OpenAI⁩ و ⁦Anthropic⁩ روی ⁦API⁩ عمومی‌شون دارن، این بار روی سخت‌افزار خودت

چرا این مهمه؟ چون فاصله‌ی بین لود بالانسرِ کلاسیک و چیزی که سرویس‌دهیِ مدل واقعاً لازم داره، یکی از دست‌کم‌گرفته‌شده‌ترین گلوگاه‌های اجرای مدل‌های متن‌بازه. اگه همیشه برات سؤال بوده که سرویس‌های بزرگ چطور این حجم ترافیک رو مدیریت می‌کنن، جوابش تقریباً همینه.

یه نکته‌ی خوب: برای امتحان کردنش اصلاً ⁦GPU⁩ لازم نداری. خودِ پروژه دو تا سرور ⁦vLLM⁩ قلابی داخلش داره، پس با یه ⁦docker compose up⁩ کل سیستم بالا میاد و می‌تونی رفتارش رو زیر فشار ببینی.

چند تا نکته‌ی صادقانه هم هست:
▪️ تازه منتشر شده و هنوز جوونه — برای ⁦production⁩ با احتیاط و تست جلو برو
▪️ به ⁦Redis⁩ و ⁦PostgreSQL⁩ نیاز داره و نسخه‌ی سبکِ بدون اینا نداره
▪️ هر درخواست ۲ تا ۳ رفت‌وبرگشت اضافه به ⁦Redis⁩ می‌خوره؛ ناچیزه ولی صفر نیست
▪️ کش معنایی پیش‌فرض خاموشه و برای روشن‌کردنش به یه سرویس ⁦embedding⁩ جدا نیاز داری
▪️ مهم‌ترین تنظیمش ⁦capacityTokens⁩ هست که باید با سخت‌افزار خودت هماهنگ بشه

لایسنسش ⁦MIT⁩ هست و با ⁦TypeScript⁩ و ⁦Fastify⁩ نوشته شده.

اسم پروژه ⁦TokenFlow Gateway⁩ هست — کد و راهنمای راه‌اندازیش از دکمه‌ی پایین 👇

یه مدل جدید امروز معرفی شد که ادعا می‌کنه توی کدنویسی بهترین مدلِ متن‌بازه — ولی وزن‌هاش هنوز بیرون نیومده، و دلیلش شنیدنیه.

شرکت چینی ⁦Z.ai⁩ امروز از ⁦GLM-5.3⁩ رونمایی کرد. نکته‌ی جالبش اینه که مدلِ پایه‌ش هیچ فرقی با نسخه‌ی قبلی نداره؛ تمامِ پیشرفتش از مرحله‌ی آموزشِ بعد از ساخت (⁦post-training⁩) اومده، نه از بزرگ‌تر کردن مدل.

عددهایی که خودشون منتشر کردن:
▪️ توی ⁦Terminal-Bench⁩ نمره‌ش از ۴.۶ رسیده به ۲۸.۳
▪️ توی ⁦DeepSWE⁩ از ۴۶.۲ به ۶۶.۹
▪️ توی بنچمارک داخلیِ خودشون ۳۱.۴٪ گرفته، در برابر ۲۹.۵٪ برای ⁦Claude Opus 4.8⁩ — اونم با کمتر از نصفِ توکن (حدود ۵۰ هزار در برابر ۱۲۰ هزار). یعنی نتیجه‌ی بهتر با هزینه‌ی کمتر

ولی چند تا نکته که بهتره بدونی:
▪️ این عددها مالِ خودِ شرکته و هنوز هیچ آزمایشگاه مستقلی تأییدشون نکرده
▪️ توی همون بنچمارک، ⁦Claude Fable 5⁩ با حداکثر توان ۳۹.۵٪ گرفته — پس ⁦GLM-5.3⁩ بهترینِ مطلق نیست، بهترین بینِ متن‌بازهاست
▪️ وزن‌های مدل هنوز منتشر نشده. ⁦Z.ai⁩ می‌گه حدود دو هفته‌ی دیگه، بعد از ارزیابی امنیتی، آزادشون می‌کنه

و دلیلِ همون تأخیر جالبه: توانایی مدل توی پیدا کردنِ حفره‌های امنیتی سریع‌تر از چیزی که انتظار داشتن رشد کرده. خودِ شرکت می‌گه از نسخه‌ی قبلی تا حالا، مدل ۲٬۴۳۶ آسیب‌پذیری توی ۲۶۹ پروژه‌ی متن‌باز پیدا کرده که ۱٬۰۹۷ تاش بحرانی یا پرخطر بوده.

یه تغییر مهم هم برای برنامه‌نویس‌ها داره: روی ⁦API⁩ دیگه نمی‌شه حالت ⁦thinking⁩ رو خاموش کرد — یعنی اگه اپلیکیشنت با این حالت خاموش کار می‌کرد، باید بازنگریش کنی.

حالا دیگه لازم نیست بین تب‌های مرورگر جابجا بشی. ⁦ChatGPT⁩ یه قابلیت جدید اضافه کرده که باهاش می‌تونی فایل‌های ⁦Google Docs⁩، ⁦Google Sheets⁩، و ⁦Google Slides⁩ رو مستقیم داخل خود ⁦ChatGPT⁩ باز کنی و کنارشون کار کنی.

یعنی همزمان که داری با ⁦AI⁩ صحبت می‌کنی، سندت هم جلوی چشمته — بدون اینکه نیاز باشه تب عوض کنی یا بری ⁦Google Drive.⁩

این قابلیت داره برای کاربران ⁦Plus⁩، ⁦Pro⁩، ⁦Business⁩ و ⁦Enterprise⁩ منتشر می‌شه — هم در ⁦ChatGPT⁩ هم در ⁦ChatGPT Work.⁩ فعلاً فقط نسخه وب داره این امکان رو و حساب‌های رایگان شامل نمی‌شن.

گوگل تو آپدیت جدید ⁦Gemini⁩ یه گزینه اضافه کرده به اسم ⁦Media watermark⁩ — که اگه خاموشش کنی، اون نشان درخشش و واترمارک که گوشه پایین سمت راست تصاویر و ویدیوهایی که باهاش ساخته می‌شن قرار می‌گرفتن، حذف می‌شن.

یعنی دیگه هیچ نشونه ظاهری‌ای روی محتوا نمی‌مونه که بگه این با ⁦AI⁩ ساخته شده.

ولی یه چیز مهم: حذف این علامت‌های ظاهری به معنای پاک شدن کل ردپا نیست. اطلاعات نامرئی استاندارد و شناسه‌های مخصوص هنوز تو پس‌زمینه فایل‌ها باقی می‌مونن، و ابزارهای تشخیص ⁦AI⁩ همچنان می‌تونن بفهمن که این محتوا با ⁦Gemini⁩ تولید شده.

وقتی ⁦Few-shot⁩ استفاده می‌کنی، معمولاً چند نمونه‌ی «خوب» می‌دی و می‌گی شبیهشون بساز. این روش کار می‌کنه — ولی یه چیزِ مهم کم داره: مدل نمی‌دونه از چی باید دور بمونه.

نتیجه؟ خروجی‌هایی که از نظرِ سبک به نمونه‌هات شبیهن، ولی همون خطاهای کلیشه‌ای رو دارن.

راه‌حل اینه که یه نمونه‌ی «بد» هم بذاری — و دقیقاً بگی چرا بده. اسمش ⁦Contrastive Few-shot⁩ هست.

مثالِ واقعی: می‌خوای ⁦AI⁩ برات عنوانِ ⁦cold email⁩ بنویسه که گیرنده وادار بشه بازش کنه.

پرامپتِ معمولی:
«برام ۵ عنوانِ جذاب برای ⁦cold email⁩ بنویس.»

با ⁦Contrastive Few-shot⁩ 👇
──────────────────
بد (کلیشه‌ست، همه می‌فرستن، سریع دیلیت می‌شه):
«یه پیشنهادِ همکاریِ جذاب برای شما»

خوب (مستقیم، خاص، بدون اغراق):
«دیدم روی ⁦X⁩ کار می‌کنی — یه ایده دارم»

حالا ۵ تا عنوان مثلِ نمونه‌ی خوب بنویس.
──────────────────

این تکنیک به یه دلیلِ ساده جواب می‌ده: مدل از ⁦contrast⁩ یاد می‌گیره، نه فقط تقلید. وقتی می‌دونه دقیقاً چه ویژگی‌ای «بد» محسوب می‌شه، خروجیش محدودتر و دقیق‌تره ⚡

می‌تونی ازش برای هر چیزی استفاده کنی: تیترِ محتوا، کامنتِ کد، پیامِ رزومه، توضیحِ محصول. هر جایی که «کیفیت» مبهمه، یه مثالِ بدِ مشخص بهتر از ده تا توضیح عمل می‌کنه.

این هفته چند تا خبر جالب از دنیای ⁦AI⁩ رسید:

🔸 شرکت ⁦OpenAI⁩ از این ماه تبلیغ می‌ذاره توی ⁦ChatGPT⁩ برای کاربرای اروپایی — روی پلن‌های ⁦Free⁩ و ⁦Go.⁩ پلن‌های ⁦Plus⁩، ⁦Pro⁩، ⁦Enterprise⁩ و ⁦Education⁩ بدون تبلیغ می‌مونن.

🔸 مدل‌های ⁦AI⁩ شرکت ⁦Alibaba⁩ از مرز ۳ میلیارد دانلود رد شدن. سری ⁦Qwen⁩ از ⁦Meta⁩ و ⁦Google⁩ جلو زده. چینی‌ها تو حوزه ⁦open-weight⁩ جدی دارن بازار رو می‌گیرن.

🔸 شرکت ⁦OpenAI⁩ حالت ⁦Ultrafast⁩ رو برای مدل ⁦GPT-5.6 Sol⁩ باز کرد. روی سخت‌افزار ⁦Cerebras⁩ اجرا می‌شه و حدود ۷۵۰ ⁦Token⁩ در ثانیه خروجی می‌ده — تا ۱۴ برابر سریع‌تر از حالت استاندارد. یه قرارداد چندساله هم برای حدود ۷۵۰ مگاوات ظرفیت ⁦inference⁩ تا ۲۰۲۸ بسته شده.

🔸 شرکت ⁦DeepSeek⁩ مدل ⁦V4-Pro⁩ رو عمومی کرد، ولی قیمت ⁦API⁩ رو بالا برد. از ۱۶ آگوست قیمت ⁦peak⁩ و ⁦off-peak⁩ جدا می‌شه؛ ⁦off-peak⁩ نصفِ ⁦peak⁩ هست. برای ⁦V4-Pro⁩ تو حالت ⁦peak⁩، هر میلیون ⁦Token⁩ خروجی حدود ۳.۹۶ دلار — قبلاً خیلی ارزون‌تر بود.

🔸 شرکت ⁦SpaceX⁩ خرید ⁦Cursor⁩ رو رسمی کرد، حدود ۶۰ میلیارد دلار. این ابزار ⁦coding⁩ معروف حالا زیر نظر ⁦SpaceXAI⁩ هست. تیم ⁦Cursor⁩ می‌گه به بزرگ‌ترین ناوگان ⁦GPU⁩ دنیا دسترسی دارن تا مدل ارزون‌تر و قوی‌تر بسازن. ⚡

ابزار ⁦Marketing Studio⁩ توی سرویس ⁦Pollo AI⁩ اومد.

با این قابلیت جدید، از یک محصول می‌تونی ده‌ها تصویر متنوع بسازی — با صحنه‌ها، نورپردازی‌ها، سبک‌ها و مفهوم‌های مختلف. ⚡

فرض کن ۵۰۰۰ تیکت پشتیبانی داری و می‌خوای بدونی مردم بیشتر از چی ناراضی‌ان. اگه بخوای یک به ‌یک بخونیشون، هفته‌ها طول می‌کشه. اگه بریزیشون توی ⁦ChatGPT⁩، نه ⁦Context⁩ داره نه حافظه. ولی با ⁦Embedding⁩ می‌تونی این کار رو در چند دقیقه بکنی — بدون اینکه حتی یه بار به ⁦LLM⁩ وصل بشی.

به زبونِ ساده، ⁦Embedding⁩ یه تبدیله: هر جمله یا متن رو می‌گیره و تبدیل به یه بردار عددی می‌کنه. این بردار «معنا» رو کُدگذاری می‌کنه. جمله‌هایی که مفهوم نزدیکی دارن، بردارهای عددیِ نزدیکی هم دارن.

نکته‌ای که خیلی‌ها نمی‌دونن اینه: «لغو اشتراک می‌خوام» و «چطور پلنمو ببندم» هیچ کلمه مشترکی ندارن، ولی بردار ⁦Embedding⁩شون تقریباً یکیه. این یعنی مدل «مفهوم» رو می‌فهمه، نه فقط کلمات رو.

برمی‌گردیم به ۵۰۰۰ تیکت. کاری که می‌کنی:

اول همه رو ⁦embed⁩ می‌کنی (مثلاً با ⁦text-embedding-3-small⁩). بعد با ⁦k-means⁩ یا ⁦DBSCAN⁩ دسته‌بندیشون می‌کنی. نتیجه: ۱۵ تا ۲۰ دسته‌ی معناییِ واضح که نشون می‌ده کجای محصولت مشکل داره.

نه ⁦hallucination⁩ چون ⁦LLM⁩ توش نیست. نه هزینه‌ی سنگین چون مدل‌های ⁦Embedding⁩ ارزون‌ان. فقط ریاضیاتِ فضای برداری.

همین رویکرد رو می‌شه برای پیداکردنِ تیکت‌های تکراری، طبقه‌بندیِ خودکار محتوا، یا سرچِ معنایی روی پایگاه داده‌های بزرگ هم استفاده کرد. در واقع، ⁦RAG⁩ فقط یه اپلیکیشنِ ⁦Embedding⁩ هست، نه تنها اپلیکیشنش. 🔥

اگه با ⁦Codex⁩ کار می‌کنی و همیشه نگران تموم شدن ⁦context⁩ هستی، یه راه ساده وجود داره — پنجره‌ی ⁦context⁩ رو تا ۱,۰۰۰,۰۰۰ ⁦Token⁩ ببری بالا. فقط به یه مدل که اینو ساپورت کنه نیاز داری، مثل ⁦GPT-5.6 Sol⁩ که پنجره‌ی مستند ۱,۰۵۰,۰۰۰ توکنی داره.

کافیه فایل ~/.⁦codex/config.toml⁩ رو باز کنی و این سه خط رو بالای فایل، قبل از هر [⁦section⁩] اضافه یا ویرایش کنی:

‏⁦model⁩ = "⁦gpt-5.6-sol⁩"
‏⁦model⁩_⁦context⁩_⁦window⁩ = 1000000
‏⁦model⁩_⁦auto⁩_⁦compact⁩_⁦token⁩_⁦limit⁩ = 900000

اولی مدل رو انتخاب می‌کنه. دومی به ⁦Codex⁩ می‌گه بودجه‌ی ⁦context⁩ رو روی یک میلیون ⁦Token⁩ تنظیم کنه. سومی هم می‌گه از ۹۰۰,۰۰۰ ⁦Token⁩ به بعد فشرده‌سازی تاریخچه رو شروع کنه تا یه فضایی برای ادامه باقی بمونه.

بعد از ذخیره کردن، ⁦Codex⁩ رو ریستارت کن و یه ⁦session⁩ جدید شروع کن.

اگه فقط می‌خوای یه بار امتحان کنی بدون تغییر دائمی، از این دستور ⁦CLI⁩ استفاده کن:

‏⁦codex -m gpt-5.6-sol⁩ \
‏-⁦c model⁩_⁦context⁩_⁦window⁩=1000000 \
‏-⁦c model⁩_⁦auto⁩_⁦compact⁩_⁦token⁩_⁦limit⁩=900000

البته اینو بدون که تیم ⁦Codex⁩ مقدار ⁦default⁩ رو با دقت تنظیم کرده — این گزینه بیشتر برای کساییه که واقعاً به ⁦context⁩ بلند نیاز دارن.

سرعت حرکت «⁦Prima1⁩» از شرکت ⁦Xynova⁩ به‌قدریه که چشم انسان دیگه نمی‌تونه دنبالش کنه.

این دست رباتیک توی پکن رونمایی شد و تاندون‌ها رو کامل کنار گذاشته — به‌جاشون از درایو مستقیم استفاده می‌کنه. همین تغییر بود که سرعتش رو اینقدر بالا برد.

۲۲ درجه آزادی داره با حسگرهای لمسی پیشرفته، و می‌شه باهاش کنترل نیرو رو در حد میلی‌متر تنظیم کرد. برای تولیدات صنعتی این یه استاندارد جدیده.

شرکت ⁦Xynova⁩ حالا هر سه نسل تکنولوژی دست رباتیک رو پوشش می‌ده — تاندونی، هیبریدی، و درایو مستقیم. انحصار مهندسی دست‌های چابک صنعتی عملاً دست اینه. 🤖

شرکت ⁦Serve Robotics⁩ که ربات‌های تحویل پیاده‌رویی داره، یه معامله جدید با ⁦Grubhub⁩ امضا کرد.

با این معامله، ⁦Grubhub⁩ به عنوان چهارمین پلتفرم بزرگ تحویل غذا وارد شبکه ربات‌های این شرکت می‌شه — کنار ⁦DoorDash⁩ و ⁦Uber Eats.⁩ ربات‌ها در شیکاگو، لس‌آنجلس، و الکساندریای ویرجینیا شروع به کار می‌کنن. شیکاگو با بیشتر از ۱۰۰ رستوران، لس‌آنجلس با نزدیک به ۲۰۰ رستوران وارد می‌شن.

همزمان، ⁦Serve⁩ وارد دو شهر جدید هم شده: واشینگتن دی‌سی و سن‌خوزه — هر دو از طریق ⁦DoorDash.⁩ این دو شهر حدود ۸ میلیون نفر بیشتر رو به محدوده پوشش اضافه می‌کنن، و مجموع شهرهای فعال می‌شه: لس‌آنجلس، شیکاگو، آتلانتا، دالاس، میامی، و این دو تازه‌وارد.

یه تغییر دیگه هم توی مدل گسترش شرکت داره شکل می‌گیره. قراره اولین «میکرو دپو» در میامی راه‌اندازی بشه — یه مرکز کوچیک برای شارژ و نگهداری ربات‌ها که جای تاسیسات بزرگ رو می‌گیره و می‌شه سریع‌تر توی محله‌های پرتقاضا نصبش کرد.

کنار همه اینا، ⁦Serve⁩ چند چیز دیگه هم معرفی کرد: ابزاری به اسم ⁦Beacon⁩ که رستوران‌ها رو بدون پیچیدگی فنی به شبکه ربات‌ها وصل می‌کنه؛ یه فرمت تبلیغاتی تعاملی به اسم ⁦Characters⁩ که روی خود ربات‌ها اجرا می‌شه (اولین شخصیتش «⁦Chomp⁩» هست که با همکاری ⁦Grubhub⁩ ساخته شده)؛ و نسل جدید ربات بیمارستانی ⁦Moxi 2.0⁩ که زیرمجموعه‌شون ⁦Diligent Robotics⁩ داره در بیمارستان‌های آمریکا راه‌اندازیش می‌کنه.

اما اون چیزی که از همه اینا مهم‌تره، اضافه شدن یه منبع تقاضای جدیده — نه فقط شهرهای بیشتر. وقتی چهار پلتفرم سفارش بهت می‌دن، ربات‌هایی که الان داری رو می‌شه بیشتر استفاده کرد بدون اینکه به ازای هر بازار جدید، ربات اضافه لازم باشه — و این همون چیزیه که ⁦Serve⁩ می‌گه می‌خواد روش تمرکز کنه.

اگه دیروز با ⁦GitHub⁩ کار می‌کردی و حس می‌کردی همه چیز به هم ریخته، اشتباه نمی‌کردی — یه قطعی بزرگ بود که بیش از هفت ساعت طول کشید. این مطلب مخصوص برنامه‌نویس‌هاست.

ماجرا ساعت ۱۳:۴۰ ⁦UTC⁩ شروع شد، اول به نظر یه مشکل عملکردی معمولی می‌رسید. ولی تو کمتر از بیست دقیقه، سرویس بعد از سرویس افتاد: ⁦API⁩ در ۱۳:۴۱، ⁦Actions⁩ در ۱۳:۴۲، ⁦Webhooks⁩ در ۱۳:۴۴، ⁦Issues⁩ در ۱۳:۴۶، و ⁦Pull Requests⁩ تا ۱۳:۵۸. یعنی تقریباً همه چیزی که توی کار روزانه بهش نیاز داری.

نرخ خطا روی صفحات وب و ترافیک ⁦API⁩ به حدود ۲۰ درصد رسید، ولی روی دانلود مخازن و فایل‌های ⁦raw⁩ به حدود ۵۰ درصد. اینا همون درخواست‌هایی هستن که اسکریپت‌های نصب، ساخت ⁦Docker image⁩، و ⁦pipeline⁩ های ⁦CI/CD⁩ ازشون استفاده می‌کنن — یعنی خیلی از سیستم‌های خودکار هم تو این بازه خراب یا ناقص کار می‌کردن، بدون اینکه کسی متوجه بشه.

ساعت ۱۴:۲۴ احراز هویت هم درگیر شد: ⁦SAML⁩، ⁦OIDC⁩، ⁦SCIM⁩، و ⁦Team Sync.⁩ سازمان‌هایی که از ⁦single sign-on⁩ استفاده می‌کنن، جدا از مشکلات مخازن، با خطای ورود هم روبه‌رو شدن. هفت دقیقه بعد، ⁦GitHub Copilot⁩ هم با افت کیفیت سرویس روبه‌رو شد.

جالب اینکه ⁦Git operations⁩ — یعنی خودِ دستورات ⁦clone⁩، ⁦push⁩، و ⁦pull⁩ — اول تحت تأثیر نبودن. ولی از حدود ساعت ۱۷:۳۰ اونا هم افت کردن و حدود یه ساعت بعد بهتر شدن.

بعضی سرویس‌ها تا ۱۶:۵۹ بهبود پیدا کردن، ولی مشکلات ادامه داشت — ⁦API⁩ دوباره ساعت ۱۸:۴۸ افت کرد، و تا ۲۰:۴۵ هنوز خطاهای پراکنده‌ای تو احراز هویت ⁦Copilot⁩ گزارش می‌شد. دلیل اصلی این قطعی هنوز اعلام نشده.

شرکت ⁦Cursor⁩ پلتفرم هاستینگ کدشون رو با اسم ⁦Origin⁩ لانچ کرد — یه سرویس جدید برای نگهداری و مدیریت ریپوهای کد.

می‌گن ⁦Origin⁩ سریعه، استفاده ازش ساده‌ست، و ادغام عمیقی با محیط ⁦Cursor⁩ داره. برای شروع هم می‌شه ریپوهای موجودتو مستقیم از ⁦GitHub sync⁩ کرد و وارد سرویس شد.

تو آپدیت جدید ⁦macOS Tahoe⁩ یه چیز جالب لو رفت: اولین ویدیو از ⁦AirPods⁩ دوربین‌دار اپل.

این محصول با نام رمز ⁦B790⁩ شناخته می‌شه و احتمالاً سپتامبر، کنار خانواده ⁦iPhone⁩ ۱۸ معرفی می‌شه.

دوربینی که روی این ⁦AirPods⁩ تعبیه شده، اطلاعات محیط رو به قابلیت هوش دیداری اپل منتقل می‌کنه. یعنی می‌تونی با کمک ⁦Siri⁩ عنوان یه کتاب رو اسکن کنی و درباره محیط اطرافت سوال بپرسی.

‏⁦Claude Code⁩ حالا روی موبایل و وب برای همه پلن‌های پولی در دسترسه. ⚡

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

اگه ⁦GitLab⁩ رو روی سرور خودت نصب داری، این رو جدی بگیر.

یه آسیب‌پذیری بحرانی با شناسه ⁦CVE-2026-19478⁩ کشف شده که هر کسی — حتی بدون داشتن اکانت — می‌تونه از راه دور پروژه‌های عمومی ⁦GitLab⁩ رو حذف یا ویرایش کنه. نه پسورد لازمه، نه تعامل با یه کاربر دیگه، نه هیچ پیش‌نیازی. امتیاز ⁦CVSS⁩ این باگ ۹.۴ هست که در رده‌ی بحرانی قرار می‌گیره.

مشکل توی لایه‌ای از ⁦API⁩ هست که درخواست‌های ⁦GraphQL⁩ رو پردازش می‌کنه — می‌شه یه دستورالعملِ ساختگی توی ⁦GraphQL⁩ طراحی کرد که وقتی سرور پردازشش می‌کنه، کد مخرب با سطح دسترسی کافی اجرا می‌شه و داده‌های پروژه رو نابود می‌کنه.

همزمان یه باگ دومی هم پچ شد: ⁦CVE-2026-19650⁩ با امتیاز ۷.۱ — یه ضعف ⁦CSRF⁩ توی بخش ⁦multiplex query⁩ از ⁦GraphQL⁩ که اجرای ⁦mutation⁩ از طریق درخواست ⁦GET⁩ رو ممکن می‌کنه، ولی نیاز به تعامل کاربر داره و خطرش به مراتب کمتره.

نسخه‌های آسیب‌پذیر: از ۱۸.۲ تا ۱۸.۱۱.۱۰، از ۱۹.۰ تا ۱۹.۰.۷، از ۱۹.۱ تا ۱۹.۱.۵، و از ۱۹.۲ تا ۱۹.۲.۳.

بسته به شاخه‌ای که روشی، باید بری روی ۱۸.۱۱.۱۱، ۱۹.۰.۸، ۱۹.۱.۶، یا ۱۹.۲.۴. پچ از ۱۷ اوت ۲۰۲۶ آماده‌ست.

سرویس‌های ⁦GitLab.com⁩ و ⁦GitLab Dedicated⁩ قبلاً پچ شدن و مشکلی ندارن — فقط ادمین‌های نصب‌های ⁦self-managed⁩ باید عمل کنن.

یه چیزی که توی این ماجرا نگران‌کننده‌ست: این سومین آسیب‌پذیری بحرانی در لایه ⁦GraphQL⁩ پلتفرم ⁦GitLab⁩ در سال ۲۰۲۶ هست. این الگو نشون می‌ده که این بخش از ⁦API⁩ هنوز داره مرتب مشکل نشون می‌ده. فعلاً هیچ ⁦exploit⁩ عمومی تأییدشده‌ای وجود نداره و ⁦GitLab⁩ قراره جزئیات فنی کامل رو در نوامبر ۲۰۲۶ منتشر کنه — ولی تا اون موقع منتظر موندن گزینه خوبی نیست.