مقاله‌های رسمی

آنتروپیک روز ۷ اکتبر Claude Haiku 5.5 رو معرفی کرد؛ اولین Haiku جدیدش بعد از نزدیک یه سال. Anthropic اسمش رو «ارزون‌ترین، سریع‌ترین و توانمندترین مدل کوچکی که تا حالا ساختیم» گذاشته. کاربردهای هدفش کارهای پرحجم و حساس به هزینه‌ست، مثل خلاصه‌سازی، دسته‌بندی، routing، کوئری دیتابیس، پشتیبانی زنده‌ی مشتری و browser use. می‌تونه کنار Opus 5.5 و Sonnet 5.5 به‌عنوان subagent توی کارهای کدنویسی هم کار کنه. یه تغییر دیگه هم اینه که اولین Haiku با کنترل effort هست و حالت پیش‌فرضش medium عه.

قیمت و دسترسی

قیمت برای هر یک میلیون توکن، برای درخواست‌های زیر ۱۰۰ هزار توکن، ورودی ۰.۱۰ دلار و خروجی ۰.۵۰ دلاره؛ یعنی ۹۰ درصد ارزون‌تر از Haiku 4.5 (۱ و ۵ دلار). برای درخواست‌های بالای ۱۰۰ هزار توکن قیمت می‌شه ۰.۵۰ و ۲.۵۰ دلار. Anthropic می‌گه در عمل حدود ۷۵ درصد از هزینه‌ی کارها کم می‌شه، چون توکنایزر جدید برای همون کار یه کم توکن بیشتری مصرف می‌کنه و این توی تخمینشون حساب شده. مدل از طریق پلتفرم Anthropic، AWS، Google Cloud و Microsoft Azure در دسترسه و شناسه‌ی API این هست:

claude-haiku-5-5

SDKهای پایتون و تایپ‌اسکریپت هم پشتیبانی بتای computer use و browser use گرفتن. هم‌زمان قیمت cache read مدل Sonnet 5.5 نصف شد (از ۰.۲۰ به ۰.۱۰ دلار) و کاربران Max و Team اعتبار API ماهانه می‌گیرن.

بنچمارک‌ها

طبق عددهای خود Anthropic، توی OSWorld 2.1 (زیرمجموعه‌ی آفلاین) نمره‌ی Haiku 5.5 برابر ۷۲.۴ درصده، در حالی که Haiku 4.5 فقط ۱۵.۷ و GPT-6 Luna حدود ۴۸.۹ داشتن (Sonnet 5.5 هم ۸۳.۹). توی Terminal-Bench 4.0 نمره‌ش ۳۹.۲ درصده، در برابر ۰ برای Haiku 4.5، ۱۶.۴ برای Luna و ۷۰.۶ برای Sonnet 5.5. توی GDPval-AA هم ۱۶۲۰ گرفته، بالاتر از Luna با ۱۴۳۷ ولی پایین‌تر از Sonnet 5.5 با ۱۸۴۰. نکته اینه که با effort متوسط، نمره‌ی Terminal-Bench حدود ۲۰ درصد می‌شه. از نظر امنیت سایبری هم محدودیت‌هاش از Haiku 4.5 سخت‌گیرانه‌تره و pentest تحت safeguardهای عادی بلاکه؛ سازمان‌هایی که دسترسی بیشتر می‌خوان باید از برنامه‌های تأیید هویت Anthropic درخواست بدن.

کلادفلر روز ۱ اکتبر ۲۰۲۶ توی بلاگ رسمی‌ش خانواده‌ی Clef رو معرفی کرد: مجموعه‌ای از «مدل‌های تصمیم‌گیر» (decision models) متن‌باز که برای ایجنت‌های هوش مصنوعی ساخته شدن تا بتونن دسته‌بندی‌های سریع و قطعی انجام بدن. این دقیقاً همون دسته‌ایه که Jev از TypeSafe و Laya پایه‌گذاری کردن، و کلادفلر هم حالا با یه بازیگر بزرگ‌تر واردش شده. مقاله‌ی بلاگ رو مایکل چن، الکس رنو و کوین فلنزبورگ نوشتن.

Clef دقیقاً چیه؟

Clef یه مدل non-autoregressive هست، یعنی به‌جای تولید متن توکن‌به‌توکن، جواب رو به‌صورت یه خروجی ساختاریافته و محدود (مثلاً انتخاب یکی از چند دسته به‌همراه احتمال) برمی‌گردونه. کلادفلر این رو به‌عنوان مکمل LLM ها معرفی می‌کنه: LLM ها خوب استدلال می‌کنن ولی غیرقطعی (non-deterministic) هستن، در حالی که ایجنت‌ها برای کارهایی مثل مسیردهی تسک‌ها، دسته‌بندی ورودی‌ها و تصمیم‌گیری برای اجرای یه اقدام، یه جواب سریع، قابل‌برنامه‌ریزی و با احتمال کالیبره‌شده می‌خوان.

ساختار فنی

کلادفلر مدل‌های Clef رو روی بک‌بون Qwen ساخته: مدل استاندارد Clef روی یه مدل حدود ۲۷ میلیارد پارامتری و نسخه‌ی سبک‌تر Clef-flash روی یه مدل حدود ۹ میلیارد پارامتری که وزن‌های اصلیشون freeze شده. روی این بک‌بون‌ها یه فرآیند «two-stage attention routing» برای استخراج context مربوط به هر گزینه، و بهینه‌سازی مشترک با low-rank adapter های rank-256 اعمال شده. برای کالیبره بودن احتمال‌ها، از label-smoothed cross-entropy و Brier loss استفاده شده، و یه مرحله‌ی ثانویه‌ی RL اختصاصی به اسم Reinforcement Learning for Calibrated Decisions هم داره.

دو تفاوت مهم با Jev که خود کلادفلر روشون تأکید کرده: Clef یه vision encoder داره و می‌تونه تصویر هم دسته‌بندی کنه، و پنجره‌ی context ش ۶۴ هزار توکنه (در برابر ۳۲ هزار توکن Jev).

عملکرد، طبق ادعای کلادفلر

از نظر تأخیر median، کلادفلر عدد ۳۸.۸ میلی‌ثانیه رو برای Clef-flash و ۲۰۹.۳ میلی‌ثانیه رو برای Clef اعلام کرده، در برابر ۵۲۴.۱ میلی‌ثانیه برای Jev و ۵.۸ میلی‌ثانیه برای Laya. روی دقت هم چند تا نمونه منتشر شده: روی BFCL (case exact) عدد ۹۸.۷۶ درصد برای Clef-flash در برابر ۹۵.۷۵ درصد Jev، روی API-Bank عدد ۹۳.۱۱ درصد در برابر ۸۸.۱۹ درصد، و روی Banking77 (macro-F1) عدد ۹۴.۲۰ درصد برای Clef در برابر ۷۹.۷۴ درصد برای Jev. جالبه که Banking77 همون بنچمارکیه که توی بررسی Laya دیدیم Jev روش قوی بود؛ کلادفلر Laya رو سریع‌ترین ولی با کیفیت قابل‌توجه پایین‌تر توصیف کرده.

تیم Svelte روز ۱ اکتبر ۲۰۲۶ نسخه‌ی پایدار SvelteKit 3 رو منتشر کرد، حدود هفت هفته بعد از release candidate که ۱۳ آگوست اومده بود. این یه major release واقعیه و چند تا breaking change داره که تقریباً هر پروژه‌ی SvelteKit رو درگیر می‌کنه؛ خبر خوب اینه که یه ابزار migration رسمی هم همراهشه.

چه چیزهایی عوض شده؟

بزرگ‌ترین تغییر، جابه‌جایی کانفیگ پروژه‌ست: تنظیمات SvelteKit دیگه توی فایل svelte.config.js نیست و باید توی فایل vite.config.ts قرار بگیره. تغییر دوم که حتماً توی کدت حسش می‌کنی، جایگزین شدن alias معروف lib با subpath import های استاندارد Node.js هست، یعنی importها از پیشوند دلار به پیشوند هشتگ تغییر می‌کنن. alias های دیگه مثل app و env همچنان با پیشوند دلار می‌مونن، پس یه مدت با یه قرارداد ترکیبی کار می‌کنی:

// قبل از SvelteKit 3
import { formatDate } from '$lib/utils';

// SvelteKit 3
import { formatDate } from '#lib/utils';

علاوه بر این، فایل tsconfig پروژه حالا باید از یه مسیر جدید در app/tsconfig ارث‌بری کنه، به‌جای فایل تولیدشده توی پوشه‌ی svelte-kit. پیاده‌سازی service worker ها هم ساده‌تر شده و تنظیماتشون رو از ماژول‌های app میگیرن.

قابلیت‌های تازه

متغیرهای محیطی حالا یه قابلیت پایدار و درجه‌یک هستن (قبلاً experimental بودن). توی نسخه‌ی جدید، متغیرها رو توی یه فایل مشخص با کتابخونه‌های سازگار با Standard Schema مثل Zod، Valibot یا ArkType تعریف می‌کنی و اعتبارسنجی موقع استارت اپ انجام میشه، یعنی خطای کانفیگ همون اول معلوم میشه، نه وسط اجرا.

مدیریت خطا هم یکپارچه‌تر شده: کامپوننت error هم خطاهای load و هم خطاهای render رو مدیریت می‌کنه، همه‌ی خطاها از طریق handleError عبور می‌کنن، و stack trace ها حالا sourcemap دارن که دیباگ production رو راحت‌تر می‌کنه. shallow routing هم به‌جای API قبلی، با goto و گزینه‌ی shallow انجام میشه.

مهاجرت از نسخه‌ی قبلی

گوگل روز ۳۰ سپتامبر ۲۰۲۶ رسماً Gemini 4 Argon رو معرفی کرد؛ همون Gemini 4 ای که چند روز قبلش کوری کاوکچوگلو گفته بود وارد post-training شده. گوگل Argon رو یه مدل frontier برای reasoning عمیق توی workflow های طولانی‌مدت معرفی کرده که روی مهندسی نرم‌افزار واقعی، کارهای دانش‌محور سازمانی مثل حقوقی و مالی، و امنیت سایبری تمرکز داره.

کجا در دسترسه؟

دسترسی فعلاً خیلی محدوده: Argon اول از همه فقط از طریق برنامه‌ی Fairwind در اختیار مدافع‌های سایبری تأییدشده، سازمان‌های دولتی و شرکای امنیتی Google Cloud قرار گرفته. بعدش نوبت مشتری‌های پولی API و مشترک‌های Google AI Ultra هست، و دسترسی عمومی‌تر برای توسعه‌دهنده‌ها و کاربرهای عادی هنوز تاریخ مشخصی نداره.

قیمت

قیمت‌گذاری مقدماتی ۲ دلار برای هر میلیون توکن ورودی و ۱۰ دلار برای خروجیه، و توکن ورودی cache شده با ۹۵ درصد تخفیف (۰.۱ دلار) حساب میشه. بعد از دوره‌ی مقدماتی (که گوگل مدتش رو نگفته)، قیمت استاندارد ۴ و ۲۰ دلار خواهد بود.

قابلیت‌ها و سقف خروجی

سقف خروجی مدل از ۶۴ هزار به یک میلیون توکن رسیده، که برای migration های بزرگ کد و تحلیل سندهای طولانی طراحی شده. گوگل همچنین ادعا کرده نرخ موفقیت حمله‌ی indirect prompt injection روی این مدل ۰.۷ درصده، یعنی پایین‌ترین بین مدل‌های مقایسه‌شده.

بنچمارک‌ها

گوگل میگه Argon توی ۱۳ بنچمارک از ۱۹ بنچمارکی که منتشر کرده جلوئه؛ مثلاً روی DeepSWE v1.1 عدد ۷۷.۹ درصد رو گرفته (در برابر ۷۴.۲ درصد Claude Opus 5.5 و ۷۴.۱ درصد GPT-6 Astra)، و روی کشف آسیب‌پذیری واقعی ۸۵.۸ درصد Pass@1 داره.

ولی تصویر یکدست نیست. Argon روی Terminal-Bench 4.0 با ۵۷.۴ درصد از Opus 5.5 (۶۶.۴ درصد) عقب‌تره و روی FrontierSWE v2 هم ۵۵ درصد در برابر ۶۵.۵ درصد Astra داره. ارزیابی مستقل Artificial Analysis هم امتیاز ۵۲.۶ رو به Argon داده، در برابر ۵۷.۶ برای Opus 5.5.

چیزهایی که هنوز مشخص نیست

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

آنتروپیک دوشنبه (۲۸ سپتامبر) Claude Sonnet 5.5 رو منتشر کرد و اون رو «مکمل سریع‌تر و ارزون‌تر» Opus 5.5 معرفی کرد: مدلی که برای کارهای مشخص و روزمره، رفع باگ، و ساخت سند، اسلاید و اسپردشیت طراحی شده. قیمت API بدون تغییر مونده (۲ دلار ورودی و ۱۰ دلار خروجی به ازای هر میلیون توکن)، ولی طبق ادعای آنتروپیک سرعت تولید خروجی بیش از ۳۰ درصد بالاتر رفته و هزینه‌ی انجام بیشتر کارها تا ۳۰ درصد کمتر شده، چون مدل توکن و tool call کمتری مصرف می‌کنه. روی Terminal-Bench 4.0 عدد ۷۰.۶ درصد رو گرفته، در برابر ۱۰.۳ درصد Sonnet 5 و حتی بالاتر از ۶۶.۴ درصد Opus 5.5؛ و توی effort سطح High، به گفته‌ی آنتروپیک، به بهترین امتیاز GPT-6 Sol می‌رسه، اونم با حدود یک‌پنجم هزینه‌ی هر تسک.

یه تغییر مهم دیگه سمت ایمنیه: Sonnet 5.5 اولین مدل Sonnet هست که با safeguard های سایبری مشابه مدل‌های فرانتیر عرضه میشه، چون توانایی سایبریش با Opus 5 قابل‌مقایسه‌ست. درخواست‌های پرریسک سایبری به‌صورت شفاف به Sonnet 5 fall back می‌کنن، و یه نسخه‌ی گسترش‌یافته از Cyber Verification Program هم به‌زودی دسترسی مرحله‌ای به قابلیت‌های پیشرفته رو برای مدافع‌های تأییدشده باز می‌کنه. این مدل همچنین اولین Sonnet با classifier هایی برای جلوگیری از استخراج reasoning (anti-distillation) هست.

یه نکته‌ی احتیاطی هم هست: ارزیابی مستقل Artificial Analysis توی تست با effort حداکثری، هزینه‌ی هر تسک رو بالاتر از Sonnet 5 دیده، یعنی ادعای «تا ۳۰ درصد ارزون‌تر» به سطح effort بستگی داره. مدل تحت نام claude-sonnet-5-5 روی Claude Platform، Amazon Web Services، Google Cloud و Microsoft Azure در دسترسه (با zero data retention)، و پیش‌فرض effort توی اپ‌ها و Claude Code روی Medium و توی API روی High هست. Claude Haiku 5.5 هم طی هفته‌های آینده برای تکمیل خانواده منتشر میشه.

تیم Next.js در ۲۲ سپتامبر ۲۰۲۶ یک out-of-band security release منتشر کرد. این آپدیت یک آسیب‌پذیری Critical با امکان Remote Code Execution در پیاده‌سازی Node.js مربوط به ImageResponse در next/og رو برطرف می‌کنه.

نسخه‌های 16.2.0 تا قبل از 16.3.6 تحت تأثیر این آسیب‌پذیری هستن. مشکل از escaping نامناسب SVG تولیدشده توسط Satori و dependencyهای مرتبط ناشی می‌شه.

نسخه‌های patched:
next@16.3.6

برای شاخه‌ی 15 هم نسخه‌ی 15.5.26 منتشر شده که شامل hardening مرتبطه؛ خود Next.js اعلام کرده که شاخه‌ی 15 تحت تأثیر RCE اصلی نبوده.

اگر از Next.js 16.2.x استفاده می‌کنید، آپدیت به 16.3.6 توصیه می‌شه:

npm install next@16.3.6

همچنین Next.js اعلام کرده یک security release برنامه‌ریزی‌شده‌ی دیگر برای ۳۰ سپتامبر در راهه که شامل نسخه‌های 16.3.7 و 15.5.27 و ۹ آسیب‌پذیری دیگه خواهد بود.

تیم Laravel نسخه‌ی 13.33.0 رو در ۲۳ سپتامبر منتشر کرد. این نسخه قابلیت‌های جدیدی برای cache و Eloquent اضافه می‌کنه.

مهم‌ترین تغییرات شامل پشتیبانی Cache::memo() از tagged cache، attribute جدید #[Refreshes] برای reload کردن مقادیری که database بعد از write تولید می‌کنه، پشتیبانی inplace() برای بعضی index migrationها، پشتیبانی از valkey:// و valkeys:// و چندین bug fix در Queue، Redis، Eloquent و Artisan هست.

#[Refreshes] مخصوصاً برای generated columns مثل storedAs و virtualAs کاربردیه و باعث می‌شه بعد از create() یا update() فقط columnهای مشخص‌شده دوباره از database خوانده بشن.

نسخه‌ی 12.0.6 از Nest CLI در ۲۴ سپتامبر منتشر شد. این release شامل آپدیت @rspack/core به نسخه‌ی 2.2.7 و چند اصلاح در compiler هست.

از جمله تغییرات این نسخه می‌شه به resolve کردن TypeScript path aliasها از مسیر tsconfig، امکان جلوگیری از restart شدن application هنگام تغییر بعضی assetها و resolve شدن SWC source root به‌صورت مستقل برای هر application اشاره کرد.

اگر از Nest 12 استفاده می‌کنید، می‌تونید CLI رو با npm install -g @nestjs/cli@latest آپدیت کنید.

تیم NestJS نسخه‌ی 12.1.0 رو در ۲۳ سپتامبر منتشر کرد. این نسخه بیشتر روی bug fix و بهبود رفتار core و microservices تمرکز داره.

از تغییرات مهم می‌شه به بهبود inheritance برای constructorهای optional، نام‌گذاری بهتر moduleها در metadataهای نامعتبر، retry شدن Redis client بعد از connection failure، مدیریت بهتر pending requestها در microservices، پشتیبانی از چند global prefix، cookie support مستقل از adapter و پشتیبانی از multipart file upload در Fastify اشاره کرد.

در کنار این‌ها، CSRF protection و security headers داخلی هم اضافه شدن.

تیم Node.js نسخه‌ی 22.23.3 با نام Jod رو در ۲۳ سپتامبر منتشر کرد. این یک نسخه‌ی LTS هست و علاوه بر به‌روزرسانی dependencyهای داخلی، چند تغییر مهم در runtime داره.

در این نسخه OpenSSL به 3.5.8، npm به 10.9.9، Corepack به 0.36.0، ICU به 78.3 و Undici به 6.28.1 آپدیت شدن. همچنین پشتیبانی Node-API برای SharedArrayBuffer در napi_create_typedarray و API جدید napi_create_external_sharedarraybuffer اضافه شده.

اگر روی Node.js 22 هستید، آپدیت به 22.23.3 پیشنهاد می‌شه.

تیم Go در ۲۴ سپتامبر جزئیات API آزمایشی جدید platform-independent SIMD رو منتشر کرد. در Go 1.27 یک پکیج آزمایشی به نام simd اضافه شده که اجازه می‌ده عملیات vectorized رو بدون وابستگی مستقیم به اندازه یا معماری خاص CPU بنویسیم.

این API می‌تونه برای کارهای پردازشی سنگین مثل data processing، cryptography و AI مفید باشه و در صورت وجود SIMD از دستورهای سخت‌افزاری استفاده می‌کنه؛ روی معماری‌هایی که پشتیبانی مستقیم ندارن هم امکان emulation وجود داره.

برای فعال کردن این قابلیت آزمایشی باید GOEXPERIMENT=simd رو در زمان build تنظیم کنید.