یادداشت انتشار کدکس 0.153.0 در ۲ سپتامبر ۲۰۲۶ تنظیم features.context_management.experimental_mode را اضافه کرد که پیش‌فرض خاموش است. روی codex-cli 0.158.0 اندازه گرفتم که هر دو نگارش ممکن این پرچم را روشن می‌کنند و codex features list هر دو را under development true چاپ می‌کند، اما هشدار Under-development features enabled فقط با نگارش بولی چاپ می‌شود، نه با نگارش جدولی که خود یادداشت انتشار نوشته است.
پرچمی که یادداشت انتشار نوشت و کدکس می‌خواند
یادداشت انتشار 0.153.0 این تنظیم را «غیرفعال به‌صورت پیش‌فرض» توصیف می‌کند. سه چیز را فعال می‌کند: کانتکست با بودجه‌ی توکن، یادداشت‌های تاریخچه، و ابزار new_context.
مخاطب این قابلیت نشست‌های واجد شرایط ChatGPT Plus، Pro و Pro Lite هستند که از بک‌اند کدکس استفاده می‌کنند. PR شماره 42385 که همین تغییر را آورده، صریح می‌گوید نشست‌های با کلید API، ارائه‌دهنده‌های سفارشی و نخ‌های ساخت‌یافته‌ی موقت از آن کنار گذاشته می‌شوند.
مرحله‌ی بلوغ این پرچم در همان نسخه under development است، نه experimental و نه stable. در جدول پرچم‌های کدکس چهار مرحله وجود دارد: پایدار، آزمایشی، در حال توسعه و حذف‌شده. پرچمی که در مرحله‌ی در حال توسعه است یعنی سازنده خودش نوشته که رفتارش کامل نیست و ممکن است غیرقابل پیش‌بینی باشد.
آیا واقعا روشن می‌شود؟ با features list
فرمانی که این ادعا را می‌آزماید codex features list است. این فرمان هر پرچم را با نام، مرحله‌ی بلوغ و وضعیت مؤثر چاپ می‌کند. اندازه‌گیری روی codex-cli 0.158.0 در ۱۲ مهر ۱۴۰۵ این است:
$ codex --version
codex-cli 0.158.0
# پایه: پرچم در این نصب خاموش است، چون هنوز کسی آن را روشن نکرده
$ codex features list | grep context_management
context_management under development false
# نگارش جدولی؛ همان چیزی که راهنمای پیکربندی می‌نویسد
$ codex features list -c features.context_management.experimental_mode=true | grep context_management
context_management under development true
# نگارش بولی؛ یک پرچم، یک مقدار، بدون کلید داخلی
$ codex features list -c features.context_management=true | grep context_management
context_management under development trueسه خط آخر مهم‌اند: -c یک بازنویسی یک‌بارمصرف برای یک اجراست و پس از آن در config.toml چیزی نوشته نمی‌شود. برای همین اندازه‌گیری‌های این نوشته همه با -c انجام شده‌اند، نه با دست‌کاری فایل پیکربندی شما.
اگر به تعداد پرچم‌ها علاقه دارید، همان خروجی ۱۵۱ سطر دارد و از آن ۴۳ پرچم پایدار و روشن‌اند. یعنی ۱۰۸ پرچم از ۱۵۱، معادل ۷۱٫۵ درصد، یا پایدار و روشن نیستند. ریزش این ۱۰۸ تا این‌گونه است: ۵۷ در حال توسعه، ۴۰ حذف‌شده، ۴ منسوخ و ۳ آزمایشی. در این میان ۹ پرچم حذف‌شده هنوز روشن‌اند و ۴ پرچم پایدار خاموش‌اند.
| دسته‌ی پرچم | تعداد | سهم از ۱۵۱ پرچم |
|---|---|---|
| پایدار و روشن | 43 | 28.5٪ |
| در حال توسعه | 57 | 37.7٪ |
| حذف‌شده | 40 | 26.5٪ |
| منسوخ | 4 | 2.6٪ |
| آزمایشی | 3 | 2.0٪ |
سهم هر دسته از تقسیم همان ۱۵۱ سطر بر دسته به‌دست آمده و جمعشان ۱۰۰ درصد است. روشن بودن یک پرچم حذف‌شده مثل sqlite یا steer نشانه‌ی کار است، نه تله: کدکس آن‌ها را نادیده می‌گیرد و با -c هم نمی‌توان خاموششان کرد.
دو نگارش، یک پرچم: کدام را در فایل بنویسیم
راهنمای پیکربندی کدکس همین کلید را با نقطه می‌نویسد، یعنی شکل جدولی:
# ~/.codex/config.toml
# این شکل را راهنمای رسمی می‌نویسد و کدکس آن را می‌پذیرد
[features.context_management]
experimental_mode = trueشماتیک JSON خود کدکس هر دو شکل را می‌پذیرد. تعریف FeatureToml_for_ContextManagementConfigToml یک anyOf است: یا boolean، یا جدولی با تنها یک کلید به نام experimental_mode. یعنی این هم مجاز است:
# نگارش دوم: همان پرچم، بدون کلید داخلی
[features]
context_management = trueهر دو را اندازه گرفتم و هر دو پرچم را روشن کردند. هر ۱۱ پرچمی که در شماتیک شکل بولی-یا-جدول دارند از همین مسیر پذیرفته می‌شوند، و این یک استثنای مخصوص کدکس نیست.
اندازه‌گیری که این را قطعی می‌کند، آزمون منفی با سوییچ --strict-config است. این سوییچ فقط روی codex exec هست، پس هر سه حالت را در یک CODEX_HOME جدا اجرا کردم:
$ cat config.toml # نگارش جدولی
[features.context_management]
experimental_mode = true
$ codex exec --strict-config "ping"
OpenAI Codex v0.158.0
(بدون خطای پیکربندی؛ اجرا آغاز شد)
$ cat config.toml # نگارش بولی
[features]
context_management = true
$ codex exec --strict-config "ping"
OpenAI Codex v0.158.0
(بدون خطای پیکربندی؛ اجرا آغاز شد)
$ cat config.toml # آزمون منفی: کلیدی که وجود ندارد
[features]
definitely_not_a_flag = true # این نام در شماتیک نیست و باید رد شود
$ codex exec --strict-config "ping"
Error loading config.toml:
/.../config.toml:2:1: unknown configuration field `features.definitely_not_a_flag`
|
2 | definitely_not_a_flag = true
| ^^^^^^^^^^^^^^^^^^^^^آن خطای سوم آزمون منفی است: کلیدی که واقعاً وجود ندارد، با یک پیام خطای دقیق رد می‌شود. همین کلید ناشناس روی خط فرمان هم رد می‌شود، ولی فقط وقتی --strict-config حاضر باشد. بدون آن، کدکس بی‌صدا از -c features.definitely_not_a_flag=true می‌گذرد، هیچ هشداری نمی‌دهد و همان ۱۵۱ سطر را چاپ می‌کند. برای همین یک تنظیم اشتباه در -c می‌تواند بی‌اثر بماند و شما فکر کنید روشن شده است.
اگر هر دو نگارش را در یک اجرا بدهید، آخری برنده می‌شود. این را هم اندازه گرفتم: -c features.context_management.experimental_mode=true -c features.context_management=false پرچم را خاموش می‌گذارد، و با جابه‌جا کردن ترتیب، روشن.
هشداری که با یک نگارش می‌آید و با دیگری نه
اینجاست که اندازه‌گیری چیزی را نشان داد که از راهنما معلوم نبود. کدکس هنگام اجرا پرچم‌های در حال توسعه‌ی روشن را اعلام می‌کند. سه بار تکرار کردم و در هر سه بار نتیجه یکسان بود:
$ codex exec -c features.context_management=true "ping"
# این تنها خطی است که بین دو نگارش فرق می‌کند
warning: Under-development features enabled: context_management. Under-development
features are incomplete and may behave unpredictably. To suppress this warning,
set `suppress_unstable_features_warning = true` in .../config.toml.با نگارش جدولی هیچ خطی چاپ نشد. همین نتیجه در هر سه تکرار تکرار شد، هم با فایل پیکربندی و هم با -c.
برای اینکه مطمئن شوم این رفتار مخصوص همین یک پرچم نیست، پرچم‌های دیگر همین شکل را هم آزمودم. token_budget در هر دو نگارش هشدار می‌دهد و code_mode هم در هر دو. rollout_budget و network_proxy در هیچ‌کدام هشدار نمی‌دهند. پس رفتار یک‌دست نیست و به شکل نگارش وابسته است، نه فقط به وضعیت پرچم.
تفاوت کلیدی همین‌جاست: جدول ContextManagementConfigToml تنها کلیدش experimental_mode است، در حالی که جدول TokenBudgetConfigToml کلید enabled دارد. حدس من این است که هشدار دنبال کلید enabled یا خودِ مقدار بولی می‌گردد و experimental_mode را نمی‌شناسد، ولی از روی سه اجرای یکسان نمی‌توانم این را علت قطعی اعلام کنم.
آنچه برای شما قطعی است: نگارش بولی همان اثری را می‌گذارد که نگارش جدولی می‌گذارد، به‌علاوه‌ی یک هشدار که به شما می‌گوید دارید از قابلیت نیم‌کاره استفاده می‌کنید. اگر می‌خواهید هشدار را ببینید، نگارش بولی را بنویسید.
کجا به بن‌بست می‌خورید
پرچم روشن، تضمین فعال شدن قابلیت نیست. سه شرط پشت آن است که در همین اندازه‌گیری به آن‌ها نخوردم، و باید صریح بگویم کدام را نتوانستم بسنجم.
اول اینکه نشست باید با ورود ChatGPT و اشتراک واجد شرایط باشد. روی این ماشین codex login status می‌گوید Not logged in و فایل auth.json هم وجود ندارد. پس شرط اشتراک و شرط بک‌اند کدکس هر دو برقرار نیستند.
دوم اینکه مدل باید در فهرست خودش این توانایی را اعلام کند. codex debug models روی همین نسخه ۱۰ مدل برمی‌گرداند: هفت مدل با visibility: list و سه مدل با visibility: hide. ستون supports_experimental_context در هر ده مدل false است.
سوم اینکه خودِ کانتکست مدل تغییر می‌کند یا نه. codex debug prompt-input ورودی دیدنی مدل را چاپ می‌کند. آن را با پرچم خاموش و روشن سه بار مقایسه کردم: هر سه اجرا ۵ آیتم در ۱۴٬۷۵۰ بایت تولید کردند و تنها تفاوت، شناسه و زمان پیام‌ها بود. حتی یک بار هم token_budget، context_window، new_context یا get_context_remaining در متن نیامد.
این سه نتیجه با هم یکی می‌گویند: پرچم را می‌توان روشن کرد و می‌توان روشن بودنش را دید، ولی بدون ورود ChatGPT این قابلیت چیزی به ورودی مدل اضافه نمی‌کند. اگر این آزمایش برایتان مهم است، با یک نشست Plus یا Pro و یک مدلی که supports_experimental_context را true اعلام کند تکرارش کنید و همان دو فرمان را دوباره بزنید.
روش‌های سنجش پرچم را در نوشته‌ی پرچم‌های کدکس با features list کامل‌تر توضیح داده‌ام، و اینکه codex debug models چه چیزی برمی‌گرداند را در نوشته‌ی کاتالوگ مدل‌ها آورده‌ام.
دیدگاه‌ها
۰ موردهنوز دیدگاهی ثبت نشده. اولین نفر باشید.