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

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

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

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

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

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

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

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

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

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

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

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

اگر در حال توسعه پروژه‌های ری‌اکت یا نکست‌جی‌اس با TypeScript هستید، قطعا موقع نوشتن کامپوننت‌ها یا تعریف تمپلیت‌ها، به این سه تایپ (Type) برخوردید: ReactNode ،ReactElement و JSX.Element.

در این مقاله می‌خوایم به زبون ساده و با مثال‌های واقعی بررسی کنیم که این سه مفهوم دقیقاً چی هستن، چه تفاوتی با هم دارن و در چه سناریویی باید از کدومشون استفاده کنیم.
۱. مفهوم React Element:
یک React Element کوچک‌ترین واحد سازنده در یک اپلیکیشن ری‌اکت هستش. از نظر فنی، این تایپ یک شیء (Object) ساده و جاوااسکریپتیه که توصیف می‌کنه یک جزء از پورتال یا UI شما چطور باید به نظر برسه (مثلاً نوعش چیه، چه Propsهایی داره و فرزندانش کدوم هستن).
وقتی شما یک کامپوننت یا تگ HTML رو می‌نویسین، ری‌اکت در پشت صحنه اون رو به یک الگو تبدیل می‌کنه.
چه زمانی تولید می‌شه؟ هر زمانی که تابع React.createElement() فراخوانی شه.
ویژگی مهم: این تایپ نمی‌تونه شامل متن ساده (String)، عدد یا آرایه باشه؛ بلکه فقط و فقط یک آبجکت معتبر ری‌آکتیه.

// این یک ReactElement است
const element: React.ReactElement = <h1>سلام کادولوپر!</h1>; 

// این خطا ایجاد می‌کند چون رشته متنی به تنهایی ReactElement نیست
const invalidElement: React.ReactElement = "Hello World"; // Error!

// هر دو خط زیر از نظر عملکردی کاملاً یکسان هستند:
const buttonOne: React.ReactElement = <button>کلیک کنید</button>;
const buttonTwo: JSX.Element = <button>کلیک کنید</button>;

type ReactNode = ReactElement | string | number | Iterable<ReactNode> | ReactPortal | boolean | null | undefined;

// تمام موارد زیر به عنوان ReactNode کاملاً معتبر هستند:
const nodeText: React.ReactNode = "یک متن ساده";
const nodeNumber: React.ReactNode = 1405;
const nodeElement: React.ReactNode = <div>یک المان کامپوننت</div>;
const nodeNull: React.ReactNode = null;

type LayoutProps = {
  children: React.ReactNode; // بهترین انتخاب برای دریافت هر نوع محتوا
};

export default function Layout({ children }: LayoutProps) {
  return <main className="main-container">{children}</main>;
}

type ListProps = {
  // کاربر نمی‌تواند متن ساده بفرستد، حتماً باید یک کامپوننت یا تگ معتبر باشد
  children: React.ReactElement; 
};

const renderStatusIcon = (status: string): JSX.Element => {
  if (status === "success") return <SuccessIcon />;
  return <ErrorIcon />;
};

یه روز یکی از بچه‌های تیم اومد گفت «بیا کل بک‌اند رو GraphQL کنیم، REST قدیمیه». دو هفته بعد، همون آدم داشت با N+1 query کلنجار می‌رفت و آرزو می‌کرد کاش همون REST قدیمی رو نگه داشته بودیم. این داستان رو احتمالاً قبلاً جایی شنیدی، چون تقریباً هر تیمی یه نسخه از آن را تجربه کرده.

واقعیت این است که هیچ‌کدام از این سه‌تا «بهتر» نیستند؛ هرکدام برای یک نوع درد طراحی شده‌اند.

REST: همون که همه می‌شناسن

REST رو همه به‌خاطر سادگی‌اش دوست دارن. منبع‌محور است: هر URL یک resource را نشان می‌دهد و متدهای HTTP (GET، POST، PUT، DELETE) کاری که می‌خواهی روی آن انجام دهی را مشخص می‌کنند. کتابخانه‌ها همه‌جا هستند، کش کردن با HTTP caching معمولی کار می‌کند، و هر کسی که یک بار با API کار کرده، REST را بدون توضیح زیاد می‌فهمد.

مشکلش از

 همان‌جایی شروع می‌شود که اپلیکیشن‌ها پیچیده‌تر می‌شوند. فرض کن صفحه‌ی پروفایل کاربر را داری که هم اطلاعات کاربر، هم پست‌های اخیرش، هم تعداد فالوورها را نیاز دارد. در REST کلاسیک، این می‌شود سه (یا بیشتر) درخواست جدا، یا یک endpoint سفارشی که فقط برای همین صفحه ساخته‌ای و جای دیگری استفاده نمی‌شود. این پدیده اسم دارد: over-fetching وقتی داده‌ی اضافه می‌گیری، و under-fetching وقتی کم می‌گیری و باید درخواست دوم بزنی.

GET /users/42
GET /users/42/posts?limit=5
GET /users/42/followers/count

query {
  user(id: 42) {
    name
    posts(limit: 5) { title }
    followersCount
  }