چطور قبل از بازنشستگی GPT-5.5 کدکس را مهاجرت دهیم؟

مدل gpt-5.5 در ۱۴ اکتبر ۲۰۲۶ از کدکس بازنشسته می‌شود، پس سه روز فرصت دارید هر پیکربندی، ایجنت سفارشی، کار زمان‌بندی‌شده و اسکریپت خط لوله‌ای را که این شناسه را انتخاب می‌کند پیدا کنید. با codex debug models روی نسخه‌ی 0.158.0 نشان می‌دهم فیلد upgrade مقصد مهاجرت هر مدل را نام می‌برد و چطور همه‌ی سنجاق‌ها را جایگزین کنید. هیچ کلید API لازم نشد.

بازنشستگی چه چیزی را و چه چیزی را نه

یادداشت رسمی کدکس در صفحه‌ی تغییرات، منتشرشده در ۱۴ سپتامبر ۲۰۲۶، می‌گوید در ۱۴ اکتبر ۲۰۲۶ مدل gpt-5.5 از ChatGPT، ChatGPT Work و کدکس روی همه‌ی پلن‌ها کنار می‌رود؛ شامل مصرف‌کننده، کسب‌وکار، سازمانی و آموزشی [1]. جمله‌ی کلیدی همان متن این است: این بازنشستگی روی API اثری ندارد.

پس اگر کدکس شما با کلید API خودتان احراز هویت می‌شود، کار شما در این تاریخ نمی‌شکند. آنچه می‌شکند، نشست‌هایی است که با ورود ChatGPT به کدکس وصل‌اند. این کار را باز هم انجام دهید، ولی فوریت شما متفاوت است.

سه چیز را باید دست بزنید: پیش‌فرض فضای کاری، تنظیمات مدل ذخیره‌شده، و پیکربندی‌های مدیریت‌شده. متن رسمی فهرست بلندتری هم می‌دهد: ایجنت‌های سفارشی، کارهای زمان‌بندی‌شده و اسکریپت‌هایی که هنوز gpt-5.5 را انتخاب می‌کنند [1]. هیچ‌کدام را کدکس برای شما پیدا نمی‌کند.

ممیزی بدون کلید API: فیلد upgrade در کاتالوگ

کدکس پیش از هر فرمان، کاتالوگ مدل‌ها را از سرور تازه می‌کند. همان کاتالوگ به صورت JSON خام با codex debug models بیرون می‌ریزد و هیچ درخواستی به شبکه نمی‌فرستد [2][3]. کلیدی که کار شما را راه می‌اندازد upgrade است: برای هر مدلی که جایگزین دارد، نام مقصد و متن مهاجرت در آن نشسته است.

$ codex --version
codex-cli 0.158.0

# کاتالوگ زنده را می‌خوانیم؛ --bundled فقط نسخه‌ی همراه باینری را می‌دهد
$ codex debug models | python3 -c "
import json,sys
for m in json.load(sys.stdin)['models']:
    u=(m.get('upgrade') or {}).get('model')
    if u: print('%-16s -> %s' % (m['slug'], u))
"
gpt-5.6-sol      -> gpt-6-sol
gpt-5.6-terra    -> gpt-6-sol
gpt-5.6-luna     -> gpt-6-luna
gpt-5.5          -> gpt-6-sol

خروجی همان لحظه‌ی خواندن، ۱۱ اکتبر ۲۰۲۶، چهار سنجاق را نشان می‌دهد و همه به gpt-6-sol می‌رسند جز gpt-5.6-luna که مقصدش gpt-6-luna است. نکته‌ی مهم این است که مقصد برای gpt-5.5 مستقیم gpt-6-sol است، نه gpt-5.6-sol که در متن یادداشت بازنشستگی به عنوان مسیر جایگزین آمده.

یعنی gpt-5.6-sol خودش هم سنجاق است. کاتالوگ آن را «مدل کدنویسی قدیمی برای کار پیچیده» توصیف می‌کند و فیلد upgrade‌اش هم gpt-6-sol را نام می‌برد. اگر پیرو متن یادداشت بروید، یک مهاجرت انجام می‌دهید که خودش یک مهاجرت دیگر لازم دارد.

هزینه‌ی واقعی: پنجره‌ی context و نردبان تلاش

سنجاق‌کردن روی gpt-5.5 فقط ریسک تاریخی نیست؛ همین امروز شما را از دو قابلیت محروم می‌کند. مقایسه‌ی سه مدل از همان JSON:

$ codex debug models | python3 -c "
import json,sys
ms={m['slug']:m for m in json.load(sys.stdin)['models']}
for s in ('gpt-5.5','gpt-5.6-sol','gpt-6-sol'):
    m=ms[s]
    print('%-12s ctx=%-7s max=%-7s efforts=%s' % (s, m['context_window'], m['max_context_window'], [e['effort'] for e in m['supported_reasoning_levels']]))
"
gpt-5.5      ctx=272000  max=272000  efforts=['low', 'medium', 'high', 'xhigh']
gpt-5.6-sol  ctx=272000  max=872000  efforts=['low', 'medium', 'high', 'xhigh', 'max', 'ultra']
gpt-6-sol    ctx=272000  max=872000  efforts=['low', 'medium', 'high', 'xhigh', 'max', 'ultra']

دو عدد در این جدول فرق دارند و نباید یکی گرفته شوند. context_window برابر ۲۷۲٬۰۰۰ برای هر سه مدل است و یعنی پنجره‌ی پیش‌فرض یکسان. اما max_context_window سقفی است که کدکس می‌تواند تا آن بالا برود: برای gpt-5.5 همان ۲۷۲٬۰۰۰ است و یعنی هرگز نمی‌توانید پنجره را بزرگ کنید، در حالی که دو مدل دیگر تا ۸۷۲٬۰۰۰ بالا می‌روند.

نسبت را خودتان حساب کنید: ۸۷۲٬۰۰۰ بر ۲۷۲٬۰۰۰ برابر ۳٫۲۱ است. برای ریپویی که باید یک نقشه‌ی کامل را در یک نشست نگه دارد، همین تفاوت کار را از نیاز به تقسیم کار به یک اجرای واحد تبدیل می‌کند.

تفاوت دوم نردبان تلاش استدلال است. gpt-5.5 چهار پله دارد و هر دو مدل دیگر شش پله. دو پله‌ی max و ultra یک کار مشخص می‌کنند: ultra فراتر از یک اجرای تک‌ایجنت است و از زیر‌ایجنت‌ها برای موازی کردن کار استفاده می‌کند، همان چیزی که مستندات رسمی برای کارهای بزرگِ قابل شکستن توصیه می‌کنند [2]. روی gpt-5.5 این مسیر اصلا باز نیست.

مدل	پنجره‌ی پیش‌فرض	سقف پنجره	پله‌های تلاش	مقصد مهاجرت
`gpt-5.5`	۲۷۲٬۰۰۰	۲۷۲٬۰۰۰	۴	`gpt-6-sol`
`gpt-5.6-sol`	۲۷۲٬۰۰۰	۸۷۲٬۰۰۰	۶	`gpt-6-sol`
`gpt-5.6-terra`	۲۷۲٬۰۰۰	۸۷۲٬۰۰۰	۶	`gpt-6-sol`
`gpt-5.6-luna`	۲۷۲٬۰۰۰	۸۷۲٬۰۰۰	۵	`gpt-6-luna`
`gpt-6-sol`	۲۷۲٬۰۰۰	۸۷۲٬۰۰۰	۶	—
`gpt-6-luna`	۲۷۲٬۰۰۰	۸۷۲٬۰۰۰	۵	—

سه مدل نخست جدول از upgrade گرفته شده‌اند. دو سطر آخر نشان می‌دهند چرا مقصد مهاجرت gpt-6-sol است نه gpt-5.6-luna: هر دو پنجره و هر دو پله را دارند، اما gpt-6-luna پله‌ی ششم را ندارد و برای کارهای پرتراکنش طراحی شده است، نه برای کار پیچیده‌ی کدنویسی.

پیدا کردن هر سنجاق، پیش از آنکه بشکند

کاتالوگ می‌گوید کدام مدل جایگزین دارد، ولی نمی‌گوید شما کجا آن را انتخاب کرده‌اید. پیکربندی کدکس یک فایل TOML است و دستور --model روی خط فرمان می‌آید، پس جست‌وجوی متنی تنها راه درست پیدا کردن همه‌ی سنجاق‌هاست. یک پوشه‌ی نمونه می‌سازم که هر سه شکل را داشته باشد:

$ mkdir -p ~/gpt55lab && cd ~/gpt55lab && git init -q

# سه سنجاق متفاوت: پیکربندی، ایجنت سفارشی، خط لوله
$ printf 'model = "gpt-5.5"\nmodel_reasoning_effort = "xhigh"\n' > config.toml
$ printf '# پروژه\n\nمدل پیش‌فرض این پروژه gpt-5.5 است.\n' > AGENTS.md
$ printf "jobs:\n  review:\n    run: codex exec --model gpt-5.5 --sandbox read-only 'review'\n" > ci.yml

# حالا ممیزی: هر سنجاق در هر شکلی که باشد
$ grep -rn 'gpt-5\.5' . --include='*.toml' --include='*.md' --include='*.yml'
./AGENTS.md:3:مدل پیش‌فرض این پروژه gpt-5.5 است.
./ci.yml:3:    run: codex exec --model gpt-5.5 --sandbox read-only 'review'
./config.toml:1:model = "gpt-5.5"

خروجی سه سنجاق را در سه شکل متفاوت نشان می‌دهد. نکته‌ی کاربردی این است که AGENTS.md سنجاقی است که هیچ ابزاری برایت پیدا نمی‌کند: کدکس آن را دستور متنی به مدل می‌دهد، نه پیکربندی، پس حتی اگر config.toml را درست کنید، مدل همچنان در پرامپت می‌خواند که «مدل پیش‌فرض این پروژه gpt-5.5 است».

جایگزینی را با همان کاتالوگ انجام دهید تا مقصد را حدس نزنید. فیلد upgrade برای gpt-5.5 مقدار gpt-6-sol را می‌دهد، پس همان را جایگزین می‌کنیم:

$ sed -i 's/gpt-5\.5/gpt-6-sol/g' config.toml
$ grep -rn 'gpt-5\.5' . --include='*.toml' || echo 'config.toml: no gpt-5.5 left'
config.toml: no gpt-5.5 left

$ cat config.toml
model = "gpt-6-sol"
model_reasoning_effort = "xhigh"

# آزمون منفی: بایگانی‌شده یعنی هنوز یک سنجاق جا مانده
$ grep -rn 'gpt-5\.5' . --include='*.toml' --include='*.md' --include='*.yml'
./AGENTS.md:3:مدل پیش‌فرض این پروژه gpt-5.5 است.
./ci.yml:3:    run: codex exec --model gpt-5.5 --sandbox read-only 'review'

آخرین خط نشان می‌دهد چرا یک جایگزینی کور کافی نیست: دو سنجاق هنوز سر جایشان‌اند. برای AGENTS.md جمله را بازنویسی کنید و برای ci.yml پرچم --model را عوض کنید. همیشه با یک اسکن دوباره تمام کنید، چون پیکربندی، فایل ایجنت و خط لوله سه جای متفاوت‌اند.

اثبات مهاجرت: مدل به‌روزشده چه می‌بیند

تا اینجا فقط متن فایل‌ها را عوض کردیم. برای اثبات اینکه کدکس مدل جدید را می‌بیند، از codex debug prompt-input استفاده کنید که ورودی‌های قابل‌دیدن مدل را JSON چاپ می‌کند [7]. این همان ترفندی است که در پست چطور ببینیم کدکس پیش از پیام ما چه چیزی به مدل تزریق می‌کند به کار رفت؛ آن یکی محتوا را نشان می‌داد و این یکی مدل انتخاب‌شده را. این فرمان هم بدون کلید API کار می‌کند.

$ codex debug prompt-input 'سلام' | head -6
[
  {
    "type": "message",
    "id": "msg_01a1298f-2baf-7fe2-938e-c6fb553c9b2a",
    "role": "developer",
    "content": [
      {
        "type": "input_text",
        "text": "<skills_instructions>\n## Skills\nA skill is a set of local instructions...

خروجی نشان می‌دهد کدکس همان ورودی توسعه‌دهنده‌ی مهارت‌ها را می‌سازد. برای مهاجرت، جای دیگری در این جریان مهم است: پیش از هر نشست کاتالوگ دوباره خوانده می‌شود و upgrade تعیین می‌کند چه پیشنهادی به شما نشان داده شود. پس پس از جایگزینی، دوباره codex debug models را بگیرید و ببینید شناسه‌ی قدیمی دیگر در فهرست نیست.

برای کاتالوگ همراه باینری، سوییچ --bundled را اضافه کنید تا فقط نسخه‌ای را بدهد که همراه نصب شما آمده و نه آنچه از سرور تازه شده. روی این ماشین هر دو یکسان بودند: هر دو ده مدل، بدون تفاوت در شش فیلد کلیدی. اگر روی سیستم شما فرق کرد، یعنی باینری شما از کاتالوگ زنده عقب مانده و بهتر است کدکس را به‌روز کنید [4].

$ codex debug models --bundled | python3 -c "
import json,sys,subprocess
b={m['slug']:m for m in json.load(sys.stdin)['models']}
l={m['slug']:m for m in json.loads(subprocess.run(['codex','debug','models'],capture_output=True,text=True).stdout)['models']}
print('bundled:',len(b),'live:',len(l))
print('only in live:',sorted(set(l)-set(b)) or 'none')
print('only in bundled:',sorted(set(b)-set(l)) or 'none')
"
bundled: 10 live: 10
only in live: none
only in bundled: none

اگر این فرمان روی نسخه‌ی شما تفاوتی نشان داد، به‌روزرسانی کدکس اولین کاری است که باید بکنید، چون جدول بالا از کاتالوگ زنده خوانده شده و باینری قدیمی ممکن است شناسه‌ای را نداشته باشد که سرور می‌فرستد. سه نسخه‌ی تازه در صفحه‌ی تغییرات ثبت شده‌اند: 0.158.0 در ۲۸ سپتامبر، 0.159.0 در ۲۹ سپتامبر و 0.160.0 در ۱ اکتبر [1][5].

سه روز مانده: چه کاری را به ترتیب انجام دهید

ترتیب درست کار، از فوری‌ترین به کم‌ضررترین، این است. اول grep را روی تمام مخزن‌ها و اسکریپت‌های خط لوله اجرا کنید، چون AGENTS.md و --model هیچ‌کدام در هیچ ابزار خودکاری دیده نمی‌شوند. دوم، مقصد را از خود کاتالوگ بردارید نه از متن یادداشت، چون متن gpt-5.6-sol را پیشنهاد می‌دهد ولی کاتالوگ مستقیم gpt-6-sol را می‌گوید.

سوم، پس از هر جایگزینی، یک codex debug models دوباره بگیرید و مطمئن شوید شناسه‌ی قدیمی دیگر در فهرست نیست. چهارم، اگر روی gpt-5.5 بودید، این روزها گزینه‌ی ultra نداشتید؛ بعد از مهاجرت شش پله دارید [2].

آنچه لازم نیست: هیچ کاری با max_context_window انجام ندهید. این عدد سقف است نه پیش‌فرض. اگر پیش از ۱۴ اکتبر فقط یک کار بکنید، آن یک کار اسکن کردن است.

برای دیدن همین روش روی بخش دیگری از ابزار، codex debug prompt-input را کنار آنچه در پست چطور کاتالوگ مدل‌های کدکس را ببینیم آمده بگذارید. آن یکی ساختار کاتالوگ و نردبان تلاش را توضیح داد و این یکی نشان می‌دهد چه زمانی کاتالوگ خودش به شما می‌گوید مهاجرت کنید.

چطور قبل از بازنشستگی GPT-5.5 کدکس را مهاجرت دهیم؟

بازنشستگی چه چیزی را و چه چیزی را نه

ممیزی بدون کلید API: فیلد upgrade در کاتالوگ

هزینه‌ی واقعی: پنجره‌ی context و نردبان تلاش

پیدا کردن هر سنجاق، پیش از آنکه بشکند

اثبات مهاجرت: مدل به‌روزشده چه می‌بیند

سه روز مانده: چه کاری را به ترتیب انجام دهید

منابع

دیدگاه‌ها