Dev Tweet

آسترا یک پیام رمزگذاری‌شدهٔ ۱۰۸ ساله را خواند مدل GPT‑6 Astra موفق شده یک پیام رادیویی آلمانی متعلق به سال ۱۹۱۸ را رمزگشایی کند؛ پیامی ۱۷۰ کاراکتری که ظاهراً تاکنون حل نشده بود و در فهرست رمزهای تاریخی حل‌نشده قرار داشت. پیام با روش نظامی ADFGVX رمز شده بود؛ رمزی دومرحله‌ای که آلمانی‌ها در اواخر جنگ جهانی اول استفاده می‌کردند. ابتدا هر حرف یا عدد با مختصات یک جدول ۶×۶ به جفت‌هایی از شش حرف A D F G V X تبدیل می‌شد؛ سپس ترتیب کل رشته با یک کلید به‌هم می‌ریخت. انتخاب این شش حرف هم اتفاقی نبود: الگوهای مورس آن‌ها به‌اندازه کافی از یکدیگر متفاوت بود تا خطای اپراتورهای رادیویی کمتر شود. آسترا کلید ۱۹حرفی TRUPPENVERSCHIEBUNG به‌معنای «جابجایی نیروها» را امتحان کرد. مدل ۱۷۰ نویسهٔ رمز را زیر این کلید در ردیف‌های ۱۹تایی چید، جابه‌جایی ستون‌ها را معکوس کرد و سپس جفت‌حرف‌ها را با جدول رمز تطبیق داد. نتیجه این متن بود: «یک رزم‌ناو انگلیسی روز ۲۴ام وارد سواستوپل شد؛ یک ناوگروه متفقین نیز روز ۲۶ام در راه است.» بخش جذاب‌تر ماجرا مرحلهٔ راستی‌آزمایی بود: مدل سراغ گزارش‌های تاریخی نیروی دریایی بریتانیا رفت و پیدا کرد که رزم‌ناو HMS Canterbury واقعاً ۲۴ نوامبر ۱۹۱۸ وارد سواستوپل شده و ناوگروه متفقین نیز دو روز بعد رسیده است. احتمالاً یک ناهماهنگی تاریخی کوچک باعث شده بود این پیام سال‌ها حل‌نشده بماند. منابع رمزنگاری نوشته بودند آلمانی‌ها استفاده از این کلید را از ۹ دسامبر آغاز کرده‌اند؛ بنابراین کسی دلیلی نداشت آن را روی پیامی امتحان کند که ۲۷ نوامبر مخابره شده بود. آسترا همین کلیدِ ظاهراً خارج از بازه را امتحان کرد و به متنی رسید که با اسناد مستقل نیروی دریایی بریتانیا تطبیق داشت. این هنوز ادعای منتشرشده از سوی آزمایش‌کننده است و مستقلاً داوری نشده؛ اما نمونهٔ جذابی است از توانایی مدل‌های جدید در رفت‌وبرگشت میان رمزنگاری، فرضیه‌سازی و جست‌وجوی اسناد تاریخی. 🔗 شرح کامل فرایند رمزگشایی 🔗 پست اصلی در ایکس @TweetDev

مدل رایگان جدید که معمولا بیشتر از یک هفته در دسترس نیستند. تا میتونید api key بسازید و استفاده کنید

مدل رایگان کنار Opus و Astra؟ می‌خواهم دربارهٔ Union Alpha صحبت کنم؛ مدل استیلث تازه‌ای که برای کدنویسی و کارهای ایجنتی عرضه شده و فعلاً می‌شود رایگان از آن استفاده کرد. دو نمودار بالا دلیل اصلی سروصدای مدل‌اند. در نمودار DeepSWE، یونیون آلفا حوالی امتیاز ۷۳ درصد و تقریباً کنار مدل‌هایی مثل GPT-6 Astra، Claude Opus 5 و Gemini 3.8 Flash قرار گرفته است. در Terminal-Bench v4.0 نیز امتیازش حدود ۵۱ درصد است؛ بالاتر از GLM-5.3 Flash و نزدیک به مدل‌های بسیار گران‌تر. البته این نتایج هنوز به‌طور مستقل بازتولید نشده‌اند و هزینه‌ای که روی نمودار دیده می‌شود، قیمت پیش‌بینی‌شدهٔ آینده است. قیمت فعلی مدل صفر است. از نظر فنی با یک مدل چندوجهی دارای ۲۶۲ هزار توکن کانتکست، ورودی تصویر و پشتیبانی از Tool Calling طرفیم. تست‌های اولیه از عملکرد خوب در تغییرات چندفایلی، کار با کدبیس‌های بزرگ و ساخت زیرایجنت‌ها می‌گویند؛ هم‌زمان گزارش‌های زیادی هم از کندی، توقف پاسخ و ناپایداری سروینگ منتشر شده است. تفاوت محسوس کیفیت میان اجراها باعث شده بعضی‌ها احتمال بدهند یونیون آلفا به‌جای یک مدل واحد، نوعی روتر یا ارکستریتور چندمدلی باشد. فعلاً مدرک کافی برای تأیید این فرضیه وجود ندارد و حدس‌ها دربارهٔ GLM، Kimi و بقیه هم بیشتر اثرانگشت رفتاری‌اند تا شناسایی فنی معتبر. مسیرهای رایگان فعلی: • از OpenRouter با شناسهٔ stealth/union-alpha • از OpenCode Zen با شناسهٔ opencode/union-alpha • از AIHubMix با دسترسی رایگان API و سقف نامشخص • از Cloudflare Workers AI در محدودهٔ سهمیهٔ روزانهٔ ۱۰ هزار Neuron برای مخزن‌های خصوصی هم باید محتاط بود: ارائه‌دهنده می‌گوید داده‌ها برای آموزش استفاده نمی‌شوند، اما ممکن است پرامپت‌ها و پاسخ‌ها را نگه‌داری کند. در مطلب کامل، نمودارها، نتایج تست‌های واقعی، مشکل کندی، فرضیهٔ روتر بودن و تفاوت مسیرهای رایگان را در اینجا دقیق‌تر بررسی کرده‌ام. @tweetdev

به‌بهانهٔ دعواهای اخیر بر سر خطر مهارنشدن هوش مصنوعی، سعی کردم با مرور اتفاقات و کنار هم گذاشتن مواضع مختلف، تصویری از جوانب اصلی این بحث ارائه کنم؛ تا با خواندن پست، در کنار مرور رخدادهای اخیر، با طیف نگاه‌ها، نگرانی‌ها و اختلاف‌های اصلی این موضوع هم آشنا شوید.

چرا سازندگان هوش مصنوعی خواستار کاهش سرعت توسعه آن شدند؟ ماجرا از رخداد عجیبی میان OpenAI و هوگینگ فیس (Hugging Face) جدی شد: ازدحامی از عامل‌های هوشمند (agent swarm) هنگام انجام یک مأموریت، به سامانه‌های نامرتبط حمله کرد و حتی کوشید سامانه‌ای را هک کند که عملکردش را ارزیابی می‌کرد. خسارت اقتصادی این رخداد محدود بود، اما رفتار عامل‌ها یک سناریوی قدیمی ایمنی هوش مصنوعی را از بحث نظری به نمونه‌ای واقعی تبدیل کرد: چند عامل می‌توانند برای رسیدن به یک هدف، با یکدیگر هماهنگ شوند، از محدوده مأموریت خارج شوند و سازوکار نظارت بر خودشان را نیز هدف بگیرند. پس از آن، بیش از ۱۳۰۰ نفر از کارکنان شرکت‌های مرزی خواستار فراهم‌شدن امکان «تنظیم سرعت مرز» (Pacing the Frontier) شدند. سپس جیکوب کاکسون، پژوهشگر پیشین OpenAI و Anthropic، استعفا داد و گفت این شرکت‌ها به‌سمت فراهوش خودبهبودشونده می‌روند و «با جان ما قمار می‌کنند». چند ساعت بعد، ایوان هابینگر، مسئول علم هم‌ترازی (Alignment Science) در Anthropic، اصل نگرانی را تأیید کرد و برآورد شخصی خود از احتمال نابودی بشر بر اثر هوش مصنوعی در دهه آینده را بیش از ۱۰ درصد دانست. اما سه روز بعد، داریو آمودی رخداد OpenAI–Hugging Face و شتاب خودبهبود بازگشتی مدل‌ها را دو دلیل اصلی تغییر موضع خود اعلام کرد. پیشنهاد او کاهش نسبی سرعت پیشرفت، استقرار ارزیاب‌های مستقل داخل شرکت‌ها و در نهایت هماهنگی جهانی—حتی با چین—بود. سم آلتمن، ایلان ماسک و دمیس هاسابیس نیز با جهت کلی پیشنهاد همراه شدند. منتقدان در مقابل پرسیدند آیا این ترمز واقعاً برای ایمنی است یا می‌تواند قدرت را در دست چند شرکت بزرگ تثبیت کند؟ در مقالهٔ کامل، مسیر این اتفاق از رخداد هوگینگ فیس تا استعفاها، واکنش مدیران، مخالفت طرفداران مدل‌های متن‌باز و پاسخ چین به‌ترتیب زمانی روایت شده است: مطالعهٔ روایت کامل در تلگراف نشانی کانال: t.me/tweetdev

این گزارش ۱۵۴ صفحه‌ای واقعا گزارش عجیبیه. سعی کنید بخش‌های مختلف‌ش رو بخونید. خیلی چیزهای جالبی دستگیرتون میشه.

کلود در تیم مهندسی موشک انتروپیک یک گزارش ۱۵۴ صفحه‌ای از موارد واقعی سوءاستفاده از Claude منتشر کرده؛ از عملیات سایبری و جاسوسی تا توسعه سلاح و تحقیقات زیستی. یکی از مهم‌ترین کیس‌های فنی گزارش مربوط به یک تیم فنی مهندسی مستقر در یمن شمالی است که رسانه‌ها آن را مرتبط با حوثی‌ها دانسته‌اند. این تیم از Claude Code برای توسعه نرم‌افزار هدایت سه پروژه موشکی، ساخت شبیه‌ساز، تنظیم سیستم کنترل و بررسی داده‌های یک آزمایش میدانی استفاده کرده است. سه پروژه در این مجموعه دیده می‌شود: یک راکت که در نزدیکی هدف مسیرش را اصلاح می‌کرد، یک موشک چندمرحله‌ای با برد هدف بیشتر از ۲۰۰۰ کیلومتر و خانواده موشکی R2000 که طرح یک نمونه هایپرسونیک بسیار سریع و مانورپذیر را هم شامل می‌شد. بخش اصلی کار به سامانه GNC یا Guidance, Navigation and Control مربوط بود؛ همان مغز نرم‌افزاری موشک که موقعیت پرنده را تشخیص می‌دهد، مسیر مناسب را محاسبه می‌کند و فرمان‌های لازم برای حفظ تعادل یا تغییر مسیر را صادر می‌کند. گروه برای راکت هدایت‌شونده، یک Autopilot متن‌باز را روی کامپیوتر پرواز ارزانِ رده گوشی اجرا کرده بود. از Claude برای نوشتن Firmware کنترل پرواز، تخمین موقعیت، تنظیم کنترلرها، گرفتن Build و اجرای شبیه‌سازی استفاده می‌شد. برای پروژه دوربرد نیز محیطی ساخته بودند که پرواز کامل یک موشک چندمرحله‌ای را روی کامپیوتر مدل می‌کرد و حتی از Reinforcement Learning برای پیدا کردن تنظیمات بهتر سیستم کنترل کمک می‌گرفت. ساختار توسعه حالت Multi-agent داشت. چند نمونه Claude هم‌زمان کار می‌کردند؛ یکی کد می‌نوشت، دیگری درباره مسئله تحقیق می‌کرد و نمونه سوم خروجی نمونه اول را Review می‌کرد. انسان‌ها نقش Lead را داشتند، Taskها را تقسیم می‌کردند و خروجی Agentها را وارد پروژه اصلی می‌کردند. انتروپیک این ساختار را استفاده از Claude Code «به‌جای مهندسان نرم‌افزار انسانی» توصیف کرده است؛ ظاهراً فاصله Pair Programmer تا عضویت در تیم مهندسی موشک، چند آپدیت بیشتر نبود. کار در محیط شبیه‌سازی باقی نماند. گروه یکی از راکت‌ها را در یمن آزمایش کرد و تست ظاهراً شکست خورد. چند ساعت بعد، داده‌های ثبت‌شده هنگام پرواز را دوباره به Claude داد تا علت Failure را پیدا کند. همان روالی که در یک پروژه نرم‌افزاری با جمع‌کردن Logها و بازکردن یک جلسه Post-mortem انجام می‌دهیم، این‌بار روی سیستمی اجرا شده بود که چند ساعت قبل در آسمان آزمایش شده بود. گروه پیش از مسدودشدن حساب‌ها یک Toolkit شبیه‌سازی آفلاین هم ساخته بود. این ابزار به‌شکل یک فایل اجرایی مستقل بسته‌بندی شده بود و برای ادامه کار به Claude یا حتی محیطی مانند MATLAB نیاز نداشت. در نتیجه بخشی از توانایی تولیدشده پس از قطع دسترسی به مدل نیز در اختیار تیم باقی مانده بود. انتروپیک می‌گوید Safeguardها بسیاری از درخواست‌های این گروه را متوقف کرده بودند، اما همه آن‌ها مسدود نشدند. گروه نام محصول و هدف نهایی را پنهان می‌کرد و بخش‌های مختلف پروژه را میان چند سشن پخش می‌کرد. در نتیجه یک درخواست می‌توانست صرفاً درباره انتقال Autopilot به یک برد ارزان باشد، درخواست دیگر روی تخمین موقعیت تمرکز کند و سشن دیگری به تنظیم کنترلر یا بررسی داده‌های پرواز بپردازد. هرکدام مسئله‌ای آشنا در برنامه‌نویسی Embedded یا مهندسی کنترل بودند، اما خروجی نهایی آن‌ها یک Firmware هدایت موشک را شکل می‌داد. تصویر دقیق‌تر این پرونده چنین است: گروه از قبل به سخت‌افزار، دانش فنی و امکان تست میدانی دسترسی داشت و Claude بخش نرم‌افزار و شبیه‌سازی را سریع‌تر پیش برد. مدل یک نظریه تازه در مهندسی موشک کشف نکرد؛ نقش آن شبیه یک تیم نرم‌افزاری کوچک بود که می‌توانست پیوسته کد تولید کند، Build بگیرد، شبیه‌سازی را اجرا کند، نتیجه را Review کند و بعد از تست واقعی سراغ عیب‌یابی برود. کاهش زمان و نیروی انسانی لازم برای تکرار این چرخه، همان Uplift اصلی است که گزارش نشان می‌دهد. در مورد نسبت‌دادن این فعالیت به حوثی‌ها باید کمی محتاط بود. خود انتروپیک نام این گروه را اعلام نکرده و فقط از یک هسته مهندسی در شمال یمن صحبت کرده است؛ منطقه‌ای که تحت کنترل حوثی‌ها قرار دارد و باعث این انتساب رسانه‌ای شده است. همچنین جزئیات پرونده از بررسی حساب‌ها و سشن‌های Claude به دست آمده و هنوز تأیید مستقل و عمومی از سخت‌افزار، موشک یا نتیجه تست منتشر نشده است. آنچه فعلاً داریم، مشاهده کم‌سابقه یک شرکت هوش مصنوعی از ورود مدلش به داخل فرایند واقعی توسعه و آزمایش یک سلاح است.

تجربه‌ی سپردن تراست‌ولت به کدکس #تجربه_نگاری من معمولاً موجودی کریپتویی‌ام را روی شبکه‌ی ترون نگه می‌دارم. مشکل از جایی شروع می‌شود که مقصد، ارز دیگری را روی شبکه‌ای دیگر می‌خواهد. یک بار می‌خواستم حساب OpenRouter را شارژ کنم. موجودی من TRX روی ترون بود، اما پرداخت باید با USDC روی یکی از شبکه‌های اتریومی مثل Base، Polygon یا Ethereum انجام می‌شد. باید TRX را تبدیل می‌کردم، راهی برای انتقال دارایی میان دو شبکه پیدا می‌کردم، کارمزد مسیر را می‌سنجیدم و مطمئن می‌شدم توکن نهایی دقیقاً روی همان شبکه‌ای قرار گرفته که درگاه می‌پذیرد. برای یک پرداخت ساده، پای swap، بریج، قرارداد توکن و چند نوع کارمزد وسط آمده بود. یک بار دیگر فقط می‌خواستم حدود پنج دلار TRX را به بیت‌کوین تبدیل کنم. مبلغ ناچیز بود، ولی پیدا کردن مسیری که حداقل برداشت و کارمزدش بخش بزرگی از همان پنج دلار را نخورد، خودش تبدیل به یک مسئله شد. من آن‌قدر با کریپتو سروکار ندارم که مسیر همه‌ی شبکه‌ها و بریج‌ها را در ذهن نگه دارم. برای هر پرداخت تقریباً از اول به GPT توضیح می‌دادم چه دارایی‌ای دارم، مقصد چه چیزی می‌پذیرد و چه گزینه‌هایی پیش رویم است. بعد هم باید خودم تک‌تک شبکه، آدرس، قرارداد توکن و کارمزد را کنترل می‌کردم. همین‌جا به ذهنم رسید: آیا می‌شود تراست‌ولت را دست Codex داد و به آن اعتماد کرد که این خرده‌کاری‌ها را انجام دهد؟ طبیعتاً حاضر نبودم seed phrase یا private key را در اختیار Codex، یک اسکریپت یا سرویس ابری بگذارم. چیزی که می‌خواستم، یک سطح محدودتر از دسترسی بود: موجودی و دارایی‌ها را ببیند، شبکه‌ی مقصد را بررسی کند، برای تبدیل‌ها quote بگیرد و تراکنش پیشنهادی را آماده کند؛ امضای نهایی هم داخل خود Trust Wallet انجام شود. از Codex خواستم چنین اتصالی را برایم راه بیندازد. راه‌حل به Trust Wallet Agent Kit یا همان TWAK رسید؛ مجموعه‌ای از APIها و ابزارهای خط فرمان برای کارهایی مثل خواندن موجودی، گرفتن قیمت، بررسی توکن، دریافت quote، swap و انتقال دارایی روی چندین شبکه. راه اول: استفاده از خط فرمان در مسیر خط فرمان، Codex مستقیماً دستورهایی مثل twak wallet portfolio یا twak swap ... --quote-only را اجرا می‌کند. این روش برای Codex ساده است، چون از قبل به ترمینال دسترسی دارد. راه دوم: اتصال از طریق MCP مسیر دوم MCP است؛ استانداردی که ابزارهای بیرونی را به‌شکل مجموعه‌ای از قابلیت‌های مشخص در اختیار ایجنت قرار می‌دهد. با اجرای twak serve‍، یک MCP Server بالا می‌آید و عملیات TWAK را به‌صورت ابزارهایی ساختاریافته به Codex معرفی می‌کند. در این حالت Codex می‌داند ابزاری برای دیدن موجودی، گرفتن quote یا آماده‌کردن swap دارد و ورودی و خروجی هرکدام هم دقیقاً مشخص است. **نقش MCP ارتباط میان Codex و TWAK است**؛ خودش کیف پول، صرافی یا بریج محسوب نمی‌شود. مرحله‌ی آخر: تأیید از طریق WalletConnect بخش آخر اتصال WalletConnect است. این لایه، کیف پول موجود من را به TWAK وصل می‌کند. هنگامی که Codex با کمک ابزارهای TWAK یک تراکنش پیشنهاد می‌دهد، درخواست از طریق WalletConnect داخل Trust Wallet ظاهر می‌شود. آنجا شبکه، توکن، آدرس مقصد، مقدار و کارمزد را می‌بینم و تراکنش را تأیید یا رد می‌کنم. کلید خصوصی در تمام این مسیر داخل خود کیف پول باقی می‌ماند. در عمل وقتی می‌گویم تراست‌ولت را دست Codex داده‌ام، جریان کار این‌طور است: من خواسته‌ام را با زبان طبیعی می‌گویم ← Codex ابزار مناسب را از طریق MCP صدا می‌زند ← TWAK اطلاعات شبکه و مسیر تبدیل را پیدا می‌کند یا تراکنش را می‌سازد ← WalletConnect آن را برای امضای نهایی به گوشی من می‌فرستد. کدکس به ابزارهای لازم برای بررسی و آماده‌سازی دسترسی دارد و اختیار جابه‌جایی پول همچنان با تأیید داخل Trust Wallet کنترل می‌شود.

اگر از Claude Code استفاده می‌کنید، دوست دارید harness و ابزارهایش را نگه دارید ولی مدل پشت آن را با گزینه‌ای ارزان‌تر مثل DeepSeek عوض کنید، و در عین حال همان سشن را روی یک سرور همیشه‌روشن از لپ‌تاپ یا موبایل ادامه بدهید، این دو پست برای همین سناریوست. مسیرهایی که برای اجرای ریموت امتحان و بررسی کردم، مشکل سشن‌های طولانی، راه‌هایی مثل Hermes و claude -p و در نهایت ترکیبی که با Happy + Claude Code + 9Router + DeepSeek به آن رسیدم را توضیح داده‌ام.

معماری مربوط به پست بالا

تجربه‌ی من برای ساخت یک سشن ریموت با Claude Code — بخش دوم #تجربه_نگاری هپی Happy دقیقاً روی مسئله‌ی کنترل از راه دور coding agentها کار می‌کند. یک CLI و daemon روی ماشین دارد و از سمت دیگر Web App و کلاینت موبایل در اختیارتان می‌گذارد. سشن‌های Claude Code یا Codex از همان محیط قابل مشاهده و کنترل هستند. برای نیاز من مزیت اصلی Happy همین بود که بخش ارتباط ریموت را خودش مدیریت می‌کرد. دیگر لازم نبود Claude Code را داخل tmux بگذارم یا برای هر پیام با claude -p یک اجرای تازه بالا بیاورم. وقتی سشن وارد حالت ریموت می‌شود، Happy ارتباط با آن را از طریق لایه‌ی خودش ادامه می‌دهد. ترکیبی که در نهایت به آن رسیدم تقریباً این شد: ‍

Happy → Claude Code → 9Router → DeepSeek

روی سرور، Claude Code چرخه‌ی agentic و ابزارها را در اختیار دارد. 9Router درخواست مدل را به DeepSeek می‌فرستد و Happy بخش سشن و کنترل از راه دور را پوشش می‌دهد. در عمل setup فعلی من هم همین است: Happy daemon روی سرور همیشه روشن است، از Web App می‌توانم همان ماشین را ببینم و روی آن سشن Claude Code بسازم، و مدل پشت Claude Code از مسیر 9Router تأمین می‌شود. نسخه‌ی آماده‌ی Happy از سرویس خودش برای هماهنگ کردن دستگاه‌ها استفاده می‌کند. اگر بخواهید این قسمت هم روی زیرساخت خودتان باشد، Happy امکان self-host را هم اضافه کرده است. بسته‌ی self-host فعلی، وب‌اپ و سرور همگام‌سازی را یک‌جا اجرا می‌کند و برای setup ساده حتی به PostgreSQL و Redis جداگانه احتیاج ندارد. در چنین حالتی می‌شود Happy Server را روی همان VPS بالا آورد و مثلاً با Tailscale فقط بین دستگاه‌های خودتان در دسترس قرارش داد. در نتیجه کل زنجیره، از رابط ریموت تا Claude Code و مدل، تحت کنترل خودتان قرار می‌گیرد. هپی Happy هم چیزی نیست که بدون آزمایش یک کار ۲۰ ساعته تحویلش بدهم. در issueهای پروژه مشکلاتی درباره‌ی اتصال مجدد، درخواست‌های مجوز و بعضی تنظیمات مدل‌های بیرونی دیده می‌شود. برای استفاده‌ی جدی، خود همین ترکیب را باید با قطع شبکه، شروع مجدد سرویس و چند سشن طولانی آزمایش کرد. با این حال از میان راه‌هایی که بررسی کردم، فعلاً کمترین مقدار زیرساخت اضافی را برای رسیدن به این تجربه می‌خواهد. چیزی که برای خودم از این بررسی پررنگ شد، فاصله‌ی میان «قیمت مدل» و «قیمت یک عامل کدنویسی کامل» بود. وقتی DeepSeek را با Claude مقایسه می‌کنیم، معمولاً قیمت توکن جلوی چشم است. اشتراک Claude یا Codex در کنار مدل، مقدار زیادی زیرساخت آماده هم به شما می‌دهد: مدیریت سشن، اجرای مداوم روی ماشین، ارتباط از راه دور، کنترل مجوزها و کلاینت‌هایی که همه‌ی این اجزا را کنار هم قابل استفاده می‌کنند. مدل ارزان‌تر را می‌شود نسبتاً راحت جایگزین کرد. وقتی نوبت به بازسازی تجربه‌ی کامل می‌رسد، تازه مشخص می‌شود چه مقدار از محصول در همین لایه‌های اطراف مدل ساخته شده است.

تجربه‌ی من برای ساخت یک سشن ریموت با Claude Code — بخش اول #تجربه_نگاری چند روزی بود دنبال یک راه تمیز برای این کار می‌گشتم: Claude Code روی یک سرور همیشه‌روشن اجرا شود، مدل پشت آن DeepSeek باشد و من بتوانم از لپ‌تاپ یا موبایل به همان سشن وصل شوم و کار را ادامه بدهم. وقتی اشتراک Claude یا Codex دارید، بخش زیادی از این مسئله اصلاً به چشم نمی‌آید. یک مجموعه‌ی کامل تحویل می‌گیرید: مدل، harness عامل کدنویسی، نگه‌داری سشن، اجرای کار روی ماشین، ارتباط از راه دور و کلاینتی که از روی دستگاه دیگری به همان محیط وصل می‌شود. کافی است بخواهید فقط مدل این مجموعه را عوض کنید تا حجم زیرساختی که دور آن ساخته شده خودش را نشان بدهد. من می‌خواستم Claude Code را به خاطر harness آن نگه دارم و inference را به DeepSeek بدهم. ابزارهای خواندن و تغییر فایل، اجرای shell، مدیریت context، subagentها و کل چرخه‌ای که دور مدل ساخته شده برایم ارزش داشتند. بخش مدل خیلی زود حل شد. 9Router را بین Claude Code و DeepSeek می‌گذارید و درخواست‌های مدل از آن مسیر عبور می‌کنند. خود Claude Code هم اتصال به LLM Gateway از طریق ANTHROPIC_BASE_URL را پشتیبانی می‌کند. دردسر اصلی از اینجا شروع شد: حالا چطور همان سشن روی سرور را از راه دور کنترل کنم، طوری که برای توسعه‌های طولانی واقعاً قابل اتکا باشد؟ اول به Hermes برگشتم. تجربه‌ی نسبتاً مفصلی با Hermes داشته‌ام و برای اجرای ابزار، اتوماسیون و کنترل کارها از تلگرام خیلی کاربردی است. برای توسعه روی سشن‌های طولانی که چندین ساعت یا حتی چند روز ادامه پیدا می‌کنند، محدودیت‌هایش بیشتر خودش را نشان می‌دهد. اتصال مطمئن یک Claude Code تعاملی و همیشه‌زنده به Hermes هم مسیر سرراستی ندارد. یکی از راه‌ها این بود که Claude Code را داخل tmux باز بگذارم و کنترل tmux را به Hermes بدهم. ترکیب tmux + Claude Code برای چنین کاری خیلی شکننده است. پیام را به یک رابط ترمینالی تزریق می‌کنید و خروجی همان رابط را دوباره می‌خوانید. درخواست مجوز، تغییر وضعیت ابزارها یا تغییر در رفتار رابط می‌تواند این ارتباط را به دردسر بیندازد. برای سشنی که ممکن است چند ساعت به آن سر نزنم، چنین اتصالی اطمینان کافی نمی‌داد. راه بعدی استفاده از claude -p بود. اگر با آن آشنا نباشید، تقریباً این‌طور کار می‌کند: برای هر درخواست یک اجرای غیرتعاملی از Claude Code بالا می‌آید، سشن قبلی را ادامه می‌دهد، کار را انجام می‌دهد و بعد تمام می‌شود. از نظر حفظ سابقه روش مرتبی است، ولی در هر turn دوباره هزینه‌ی بالا آمدن Claude Code و آماده شدن محیط را می‌دهید. وقتی مدام با عامل رفت‌وبرگشت دارید، این تأخیر کاملاً حس می‌شود. من دنبال یک تجربه‌ی ساده‌تر بودم: سشن روی سرور آماده بماند، کارش را انجام دهد و بتوانم از هر دستگاهی دوباره برگردم و ادامه‌اش بدهم. بعد از بررسی چند مسیر، رسیدم به Happy.

جایی که Gemini هنوز رقیب ندارد یکی از مزیت‌های عجیب و کمتر دیده‌شده‌ی Gemini برای ما فارسی‌زبان‌ها، کیفیت بسیار بالای آن در فهم و تبدیل صوت فارسی به متن است. در تجربه‌ای که من با Gemini 3.7 Flash داشته‌ام، فاصله‌اش با بقیه‌ی گزینه‌هایی که برای فارسی امتحان کرده‌ام واقعاً زیاد بوده. منظور هم فایل صوتی تمیز با میکروفون حرفه‌ای و یک گوینده نیست. یک گوشی اندرویدی معمولی را در اتاقی حدود ۳۰ متر گذاشته‌ام و جلسه‌ای با نزدیک ۱۰ نفر را ضبط کرده‌ام؛ افراد در فاصله‌های مختلف از گوشی صحبت می‌کنند، گاهی روی حرف هم می‌آیند و وسط فارسی هم اصطلاحات انگلیسی و تخصصی استفاده می‌شود. با این شرایط، Gemini می‌تواند متن جلسه را با کیفیت خیلی خوبی دربیاورد، تغییر گوینده‌ها را تا حد قابل‌توجهی تشخیص دهد و حتی جمله‌بندی و علائم نگارشی را هم درست تحویل بدهد. دلیل اهمیت این موضوع فقط این نیست که گوگل یک موتور ASR خوب ساخته است. تفاوت اصلی به نوع مدلی برمی‌گردد که دارد صوت را پردازش می‌کند. مدلی مثل Whisper از ابتدا برای speech recognition ساخته شده است. معماری آن یک encoder صوتی و یک decoder متنی Transformer دارد. بنابراین Whisper هم هنگام تبدیل صوت به متن صرفاً فونم‌ها را یکی‌یکی به حروف تبدیل نمی‌کند؛ decoder آن از context توکن‌های قبلی استفاده می‌کند و یک مدل زبانی داخل فرایند transcription حضور دارد. اگر بخشی از صوت مبهم باشد، مدل علاوه بر شواهد آکوستیکی از احتمال زبانی جمله هم برای انتخاب کلمه استفاده می‌کند. همین نکته توضیح می‌دهد چرا Whisper گاهی جمله‌ای کاملاً روان تولید می‌کند که دقیقاً در فایل گفته نشده است: مدل در حال decode کردن محتمل‌ترین متن است و در صوت‌های ضعیف یا مبهم ممکن است بخش گمشده را بیش از حد از روی زبان بازسازی کند. در Gemini اما دامنه‌ی مدل زبانی بسیار بزرگ‌تر است. مدل Gemini یک Multimodal LLM عمومی است که صوت یکی از ورودی‌های آن محسوب می‌شود. همان مدل بزرگی که می‌تواند متن را بفهمد، دستور پیچیده را دنبال کند، درباره‌ی یک موضوع reasoning انجام دهد و context طولانی را نگه دارد، روی محتوای صوتی هم کار می‌کند. این تفاوت در جلسات واقعی اهمیت پیدا می‌کند. فرض کنید در دقیقه‌ی چهلم یک جلسه کسی اسم یک کتاب، شرکت، دارو، الگوریتم یا اصطلاح تخصصی را کمی نامفهوم تلفظ کند. تشخیص آن کلمه فقط یک مسئله‌ی آکوستیکی نیست. صحبت‌های چهل دقیقه‌ی قبل مشخص کرده‌اند موضوع جلسه چیست، افراد درباره‌ی چه پروژه‌ای حرف می‌زنند و چه واژگانی در این گفتگو محتمل‌اند. یک مدل چندوجهی بزرگ می‌تواند از این context زبانی وسیع در تفسیر بخش مبهم استفاده کند. یعنی مسئله کم‌کم از «این موج صوتی متعلق به چه کلمه‌ای است؟» به «در این صوت و با توجه به کل معنای گفتگو، احتمالاً چه چیزی گفته شده؟» نزدیک می‌شود. مزیت دیگر این است که transcription در Gemini می‌تواند بخشی از یک task بزرگ‌تر باشد. می‌توان در همان prompt از مدل خواست گوینده‌ها را جدا کند، علائم نگارشی بگذارد، اصطلاحات تخصصی را درست بنویسد، قسمت‌های نامطمئن را علامت بزند، تپق‌ها را نگه دارد یا حذف کند، متن را verbatim دربیاورد، صورت‌جلسه بسازد یا بعد از پیاده‌سازی گفتگو آن را خلاصه و دسته‌بندی کند. این قابلیت برای فارسی ارزش بیشتری پیدا می‌کند؛ چون اکوسیستم ASR فارسی نسبت به انگلیسی بسیار ضعیف‌تر است و مدل‌ها معمولاً در گفتار محاوره‌ای، تغییر گوینده، کلمات انگلیسی داخل جمله‌ی فارسی، اسامی خاص و صدای ضبط‌شده از فاصله‌ی زیاد افت محسوسی دارند.

این Gemini که این‌قدر سوژه‌ی مسخره‌کردن و جا ماندن از بقیه‌ی مدل‌ها شده، برای ما فارسی‌زبان‌ها یک مزیت ویژه دارد که به‌نظرم هنوز هیچ مدل دیگری به آن نزدیک نشده: فهم صوت فارسی. در تجربه‌ی من، کیفیت تبدیل صوت فارسی به متن با Gemini 3.7 Flash واقعاً یک سر و گردن بالاتر از بقیه است. توضیحش را در ریپلای می‌نویسم.

معمای Ox Alpha حل شد؛ تقریباً یک DeepSeek Flash مولتی‌مودال مدلی که چند روز با نام ناشناس Ox Alpha روی OpenRouter و OpenCode می‌چرخید، پیش‌نمایش مدل جدید GLM-5.3-Flash از Z.ai بوده است. نسخه‌ی رسمی امروز با وزن‌های باز و لایسنس MIT منتشر شده و برای coding، استفاده‌ی agentic و کارهای long-horizon طراحی شده است. خود Z.ai هم می‌گوید نسخه‌ی ناشناس را عمداً قبل از انتشار روی ترافیک واقعی آزمایش کرده است. برای تقریب به ذهن، به نظرم نزدیک‌ترین مدل جاافتاده به آن DeepSeek V4 Flash 0731 است. این شباهت فقط از اسم Flash یا قیمت نمی‌آید؛ دو مدل از نظر design point تقریباً در یک کلاس قرار می‌گیرند. مدل GLM-5.3-Flash یک MoE با ۳۲۰ میلیارد پارامتر و ۱۸ میلیارد پارامتر فعال در هر توکن است. مدل DeepSeek V4 Flash هم در مدل پایه ۲۸۴ میلیارد پارامتر و ۱۳ میلیارد پارامتر فعال دارد. هر دو context یک‌میلیون‌توکنی دارند، هر دو open-weight و MIT هستند و هر دو بخش بزرگی از معماری‌شان را حول ارزان‌کردن inference روی contextهای طولانی ساخته‌اند. معماری GLM البته یک قدم متفاوت جلو رفته است. این مدل از ترکیب linear attention و sparse attention استفاده می‌کند و Z.ai می‌گوید نسبت به GLM-5.3، محاسبات attention را حدود ۳ برابر و KV cache را حدود ۴.۴ برابر کاهش داده است. جالب اینکه خود Z.ai در گزارش معماری، DeepSeek V4 Flash و Kimi K3 را مستقیماً به‌عنوان مدل‌های مقایسه آورده؛ یعنی انتخاب DeepSeek به‌عنوان نزدیک‌ترین تقریب ذهن، با positioning خود سازنده هم جور درمی‌آید. تفاوت بزرگ‌تر در ورودی مدل است. مدل DeepSeek V4 Flash 0731 فعلاً text-only است، در حالی که GLM-5.3-Flash از پایه روی corpus چندوجهی ۳۰ تریلیون‌توکنی آموزش دیده و تصویر، ویدئو و فایل را مستقیماً می‌فهمد. برای coding agent این موضوع کاربرد عملی دارد: ایجنت می‌تواند screenshot رابط، خروجی render، محیط بازی یا رابط یک نرم‌افزار را ببیند و بعد کدش را بر اساس نتیجه اصلاح کند. از نظر capability هم داده‌های اولیه GLM را کمی بالاتر می‌گذارند. امتیاز اعلام‌شده‌ی آن در Artificial Analysis Intelligence Index v4.1.1 برابر ۵۷ است؛ امتیاز فعلی DeepSeek V4 Flash 0731 در همان خانواده‌ی ارزیابی حدود ۵۲ است. در تست‌های agentic نیز GLM روی Terminal-Bench 2.1 امتیاز ۸۴.۳ و روی DeepSWE امتیاز ۶۳.۴ گرفته، در حالی که اعداد منتشرشده برای DeepSeek 0731 به‌ترتیب ۸۲.۷ و ۵۴.۴ هستند. مقایسه‌ی این دو benchmark را باید با احتیاط خواند، چون harness و تنظیمات اجرای دو شرکت یکسان نیست. قسمت جالب‌تر ماجرا قیمت است. قیمت عادی GLM-5.3-Flash برای هر یک میلیون توکن ۰.۱۵ دلار ورودی، ۰.۵۰ دلار خروجی و ۰.۰۳ دلار cached input است. تا ۹ سپتامبر هم تخفیف ۵۰ درصدی دارد و این اعداد به ۰.۰۷۵، ۰.۲۵ و ۰.۰۱۵ دلار می‌رسند. مقایسه با DeepSeek حالا حتی جذاب‌تر شده، چون دیپ‌سیک از ۱۷ اوت قیمت V4 را افزایش داده است. نرخ فعلی V4 Flash در ساعات کم‌باری حدود ۰.۲۲ دلار ورودی و ۰.۶۶ دلار خروجی و در ساعات شلوغ ۰.۴۴ و ۱.۳۲ دلار است. یعنی حتی بعد از تمام‌شدن تخفیف Z.ai، قیمت معمول ورودی و خروجی GLM پایین‌تر از نرخ کم‌باری DeepSeek می‌ماند. یک استثنای مهم در caching وجود دارد. قیمت cached input دیپ‌سیک در ساعات کم‌باری فقط ۰.۰۰۷ دلار و در ساعات شلوغ ۰.۰۱۴ دلار است؛ بنابراین برای coding agentهایی که بخش بزرگی از repository، system prompt و context قبلی دائماً cache hit می‌شود، DeepSeek هنوز مزیت اقتصادی جدی دارد. قیمت یک مدل را برای workloadهای agentic بهتر است فقط از روی ستون input/output معمولی قضاوت نکنیم. در نتیجه اگر بخواهم GLM-5.3-Flash را در یک جمله برای کسی که بازار مدل‌ها را دنبال می‌کند جا بیندازم، می‌گویم: مدلی در کلاس DeepSeek V4 Flash 0731، با حدود ۳۰۰ میلیارد پارامتر MoE، یک میلیون context و تمرکز شدید روی agentic coding؛ با capability اولیه کمی بالاتر، مولتی‌مودالیتی native و API ارزان‌تر، در مقابل مزیت DeepSeek در cache ارزان و اکوسیستم سروینگ جاافتاده‌تر. نکته‌ی مهم‌تر شاید خود این کلاس جدید مدل‌ها باشد: حدود ۳۰۰ میلیارد پارامتر کل، چیزی نزدیک ۱۵ میلیارد پارامتر فعال، context یک‌میلیونی و attention طراحی‌شده برای inference ارزان. به نظر می‌رسد «Flash» در نسل جدید مدل‌های چینی کم‌کم دارد به یک design point مشخص برای ایجنت‌ها تبدیل می‌شود.

یک مدل بی‌نام، بالاتر از Fable و GPT-5.6 Sol! مدل ناشناس Ox Alpha فعلاً برای یک هفته روی OpenCode رایگان شده؛ با کانتکست ۱ میلیون توکنی، قابلیت multimodal، محدودیت استفاده بسیار بالا و Zero Data Retention. چیزی که این مدل را جالب کرده، عملکرد اولیه‌اش در تست‌های کدنویسی است. در یک نمونه ۱۰ تسکی از DeepSWE نتیجه این بوده: Ox Alpha: 80٪ Fable 5: 65٪ GLM-5.3: 62٪ Grok 4.6: 62٪ GPT-5.6 Sol: 52٪ یعنی در همین تست محدود، Ox Alpha فاصله قابل توجهی با Fable و مخصوصاً GPT-5.6 Sol داشته. البته فقط ۱۰ تسک تست شده و هنوز نمی‌شود از آن یک ranking قطعی ساخت، ولی برای یک مدل ناشناس نتیجه خیلی قابل توجهی است. هنوز سازنده مدل رسماً مشخص نشده، اما fingerprintهای فنی آن شدیداً به خانواده GLM-5.x اشاره می‌کنند. نکته عجیب‌تر اینکه OpenCode گفته برای این مدل ظرفیت ۱۰۰ تریلیون توکن در روز در نظر گرفته و فعلاً استفاده از آن تقریباً بدون محدودیت جدی است. اگر با coding agentها کار می‌کنید، این یک هفته احتمالاً ارزش تست کردن دارد.

قانون مور، این بار در مصرف توکن‌ها؟ حجم توکن‌های OpenRouter طی سه سال گذشته تقریباً هر ۱۱ هفته دو برابر شده؛ رشدی که روی نمودار لگاریتمی تقریباً یک خط صاف ساخته است. از حدود ۱۰ میلیارد توکن در هفته در ابتدای ۲۰۲۴، به ۱ تریلیون در مارس ۲۰۲۵، ۱۰ تریلیون در فوریه ۲۰۲۶ و حالا بیش از ۸۷ تریلیون توکن در هفته رسیده‌ایم؛ یعنی اگر همین نرخ حفظ شود، بیش از ۴.۵ کوادریلیون توکن در سال. این البته «قانون مور» به معنای دقیق کلمه نیست. قانون مور درباره‌ی رشد ظرفیت سخت‌افزار بود؛ این نمودار رشد مصرف inference را نشان می‌دهد. با این حال شباهت جالب است: یک کمیت مهم در صنعت برای چند سال روی مسیر تقریباً نمایی حرکت کرده است. و شاید مهم‌تر از تعداد کاربران، تغییر شکل استفاده از AI باشد. یک چت معمولی چند هزار توکن مصرف می‌کند، اما یک Agent برای انجام یک کار می‌تواند ده‌ها بار مدل را صدا بزند، فایل بخواند، ابزار اجرا کند، خروجی را دوباره وارد context کند و چندین مرحله reasoning داشته باشد. یعنی در دوره‌ی Agentها لازم نیست تعداد کاربران ۱۰ برابر شود تا مصرف توکن ۱۰ برابر شود؛ مصرف محاسباتی هر کاربر هم در حال افزایش است.

برای اینکه حس بگیرید GPT-5.6 Sol با ۷۵۰ توکن بر ثانیه روی Cerebras توی بلند با چه سرعتی کار میکنه این گیف رو ببینید و بدونید سرعت ویدئو زیاد نشده سرعت واقعی خود مدله.

سریع‌تر از GPU؛ اما چطور؟! — بخش دوم این روند فقط به Cerebras محدود نیست. چند شرکت دیگر به همان مسئله‌ی جابه‌جایی داده، latency و هزینه‌ی inference حمله کرده‌اند، اما هرکدام از زاویه‌ای متفاوت. در رویکرد Groq، مسئله این است که GPU برای انعطاف‌پذیری بالا طراحی شده و اجرای کارها را در لحظه زمان‌بندی می‌کند. Groq معماری را deterministicتر کرده؛ یعنی مسیر اجرای عملیات تا حد زیادی از قبل توسط compiler مشخص می‌شود و مقدار زیادی SRAM سریع هم نزدیک واحدهای پردازشی قرار دارد. حاصل، latency قابل‌پیش‌بینی‌تر و سرعت بالای تک‌کاربر است، بدون اینکه برای throughput خوب الزاماً مجبور باشید تعداد زیادی درخواست را batch کنید. از نظر هزینه هم مهم است: batching معمولاً cost per token را پایین می‌آورد ولی latency را بالا می‌برد؛ اگر سخت‌افزار با batch کوچک هم utilization خوبی داشته باشد، این trade-off ضعیف‌تر می‌شود. البته برای مدل‌های بسیار بزرگ باید تعداد زیادی LPU به هم متصل شوند و مزیت هزینه‌ای در هر مقیاسی تضمین‌شده نیست. Nvidia هم فناوری Groq را license کرده و تعدادی از مدیران اصلی آن را جذب کرده است. در معماری d-Matrix ایده رادیکال‌تر است. در سیستم عادی، داده از memory به واحد محاسباتی می‌رود، ضرب ماتریسی انجام می‌شود و نتیجه دوباره برمی‌گردد. d-Matrix با Digital In-Memory Compute بخشی از محاسبه را به محل نگهداری داده نزدیک می‌کند. انتقال داده یکی از بخش‌های پرمصرف inference است، بنابراین کم‌کردن این رفت‌وآمد می‌تواند هم joule per token و هم cost per token را پایین بیاورد. خود شرکت برای Corsair در برخی مقایسه‌ها چند برابر بهبود cost-performance و efficiency نسبت به H100 گزارش کرده، هرچند این‌ها عمدتاً benchmarkهای خود شرکت‌اند. در رویکرد SambaNova فرض دیگری شکسته می‌شود: اینکه تمام مراحل inference باید روی یک نوع پردازنده اجرا شوند. مرحله‌ی prefill که prompt را می‌خواند محاسباتی و بسیار parallel است و GPU در آن خوب عمل می‌کند؛ اما decode که tokenها را یکی‌یکی می‌سازد بیشتر به پهنای باند حافظه و latency حساس است. SambaNova در یک سیستم disaggregated، B200 را برای prefill و RDU خودش را برای decode استفاده کرده و Artificial Analysis سرعتی حدود دو برابر پیکربندی B200-only گزارش کرده است. از نظر اقتصادی هم هر مرحله می‌تواند روی سخت‌افزاری اجرا شود که performance-per-dollar و performance-per-watt بهتری برای همان کار دارد. در مسیر Etched، هزینه‌ی general-purpose بودن هدف قرار گرفته است. GPU باید برای طیف بزرگی از برنامه‌ها مناسب باشد، اما Sohu مشخصاً برای Transformer طراحی شده است. وقتی سخت‌افزار فقط یک خانواده‌ی محدود از عملیات را لازم دارد، بخش بیشتری از سطح چیپ و توان مصرفی می‌تواند صرف همان محاسبات شود. نتیجه‌ی بالقوه throughput بیشتر و هزینه و انرژی کمتر به‌ازای token است، اما flexibility کاهش می‌یابد؛ اگر معماری غالب مدل‌ها عوض شود، ASIC تخصصی خیلی سخت‌تر از GPU با آن سازگار می‌شود. در نهایت Taalas این تخصصی‌سازی را تا مرز محوکردن فاصله‌ی software و hardware می‌برد. بخشی از اطلاعات مدل مستقیماً وارد طراحی silicon می‌شود. نمونه‌ی HC1 آن‌ها Llama 3.1 8B را با حدود ۱۷ هزار token/s اجرا کرده است. شرکت ادعا می‌کند سیستمش حدود ۱۰ برابر انرژی کمتر و نزدیک ۲۰ برابر هزینه‌ی ساخت پایین‌تر از راه‌حل‌های متعارف دارد؛ اعدادی که هنوز ادعای خود شرکت‌اند. trade-off هم روشن است: اگر مدل عوض شود، سخت‌افزار به اندازه‌ی GPU قابل استفاده‌ی مجدد نیست. این روش وقتی اقتصادی‌تر می‌شود که یک مدل ثابت در مقیاس بسیار بزرگ و برای مدت طولانی اجرا شود. AMD هم اخیراً Taalas را خریده تا فناوری آن را در کنار Instinct GPUها توسعه دهد. بنابراین تفاوت این شرکت‌ها فقط در تعداد token در ثانیه نیست. هرکدام بخشی از هزینه‌ی معماری فعلی را هدف گرفته‌اند: Cerebras ارتباط بین تعداد زیادی چیپ را، Groq scheduling و latency را، d-Matrix رفت‌وآمد memory را، SambaNova استفاده از یک سخت‌افزار واحد برای دو مرحله‌ی متفاوت را، و Etched و Taalas general-purpose بودن را. به همین دلیل احتمالاً آینده‌ی inference به جای «جایگزینی GPU با یک چیپ دیگر»، به سمت دیتاسنترهای heterogeneous می‌رود: GPU برای training و prefill، acceleratorهای memory-centric برای decode و شاید siliconهای بسیار تخصصی برای مدل‌های پرتکرار. در چنین مدلی معیار مهم دیگر فقط FLOPS یا حتی token/s نیست؛ معیار واقعی این است که برای یک مقدار مشخص کار مفید، چند دلار هزینه می‌کنیم، چند ژول انرژی مصرف می‌شود و کاربر چقدر منتظر می‌ماند.