بهروزرسانی — تابستان ۲۰۲۶: این روش برای من دیگر کار نکرد
تا تابستان ۲۰۲۶ این workflow دیگر برای من بهشکل قابل اتکا کار نمیکرد. شمارنده پنجره استفاده ۵ ساعته از حسابم ناپدید شد و فقط محدودیت هفتگی قابل مشاهده بود. در عمل، پنجره ریست کوتاهتری که قبلاً زمانبندی این روش را بر اساس آن انجام میدادم از بین رفت.
تغییر مهمتر مربوط به کارهای طولانی بود. وقتی یک وظیفه سنگین Codex به انتهای محدودیت هفتگی من میرسید، دیدم که کار متوقف میشود، نه اینکه تا پایان ادامه پیدا کند. بنابراین قانون قبلی من — «در ۳ تا ۵ درصد آخر سنگینترین کار را شروع کن» — بخش زیادی از ارزشش را از دست داد؛ دیگر نمیتوانستم روی ادامه یافتن کارِ در حال اجرا بعد از تمام شدن محدودیت هفتگی حساب کنم.
با این حال باید تجربه خودم را از قانون رسمی محصول جدا کنم. میتوانم چیزی را که در حساب و workflow خودم دیدم تأیید کنم، اما نمیتوانم ثابت کنم OpenAI پنجره ۵ ساعته را برای همه کاربران بهطور دائمی حذف کرده است. مستندات فعلی Codex همچنان هم پنجره ۵ ساعته و هم هفتگی را ذکر میکند و میگوید یک turn فعال ممکن است پس از رسیدن به محدودیت، با رعایت محدودیتهای fair use، گاهی ادامه پیدا کند. بنابراین تغییر تابستان ۲۰۲۶ را بهعنوان رفتاری واقعی که خودم تجربه کردم ثبت میکنم، نه یک قانون جهانی برای همه حسابها.
بقیه مقاله را بهعنوان شرح workflowای که پیش از این تغییر واقعاً برای من کار میکرد حفظ کردهام. برای وضعیت فعلی، این بهروزرسانی بر توصیههای زمان حال در متن قدیمی مقدم است.
وقتی شمارنده استفاده Codex در اشتراک ChatGPT Plus من به حدود ۳ تا ۵ درصد میرسد، باقیمانده را صرف درخواستهای کوچک نمیکنم. برعکس، بزرگترین کار مهندسیای را که از قبل آماده کردهام شروع میکنم.
در مورد من این معمولاً یعنی مهاجرت کامل به TypeScript، پاکسازی ESLint در کل repository، بررسی عمیق باگها در یک codebase بزرگ یا refactor ساختاری گسترده. اغلب چند پروژه را از قبل آماده نگه میدارم تا بخش آخر استفاده به سنگینترین کاری برسد که واقعاً آماده اجراست.
دلیلش یک مشاهده تکرارشونده است. چند بار کار بزرگی را نزدیک انتهای محدودیت قابلمشاهده شروع کردم و بعد دیدم Codex حتی وقتی آن محدودیت تمامشده به نظر میرسید، به کار ادامه میدهد. گاهی task آنقدر جلو رفت که کامل شد. این تجربه آنقدر تکرار شد که برنامهریزی من را تغییر دهد، اما نه آنقدر که آن را یک تضمین محصول بدانم.
مشاهدهای که workflow من را تغییر داد
واکنش طبیعی نزدیک محدودیت این است که محافظهکار شویم: بخش آخر را روی درخواستهای کوچک خرج کنیم چون ممکن است کار بزرگ وسط راه قطع شود. من حالا ۳ تا ۵ درصد آخر را متفاوت میبینم؛ برای من یک پنجره شروع است.
سؤال دیگر این نیست که «چند پرامپت کوچک دیگر جا میشود؟» بلکه این است که «تا وقتی استفاده مشمول طرح باقی مانده، باارزشترین task آمادهای که میتوانم شروع کنم چیست؟»
این روش فقط به این دلیل کار میکند که پروژه از قبل آماده و task روشن است. من چند درصد آخر را صرف فهمیدن اینکه چه کاری باید انجام شود نمیکنم؛ آن را صرف شروع اجرا میکنم.
یک اصلاح مهم درباره نام و محدودیت
من قبلاً به این حالت “Codex Plus” میگفتم، اما این نام رسمی محصول نیست و فقط یک shorthand است. OpenAI، Codex را قابلیتی مشمول ChatGPT Plus معرفی میکند. این اصلاح مهم است تا تصور نشود Codex Plus یک محصول یا پلن جداگانه است.
مستندات فعلی OpenAI درباره استفاده Codex هم توضیح میدهد که مصرف به اندازه و پیچیدگی کار، مدل و محل اجرای task بستگی دارد و پنجرههای استفاده شامل یک پنجره ۵ ساعته و یک پنجره هفتگی است. بنابراین منظور من از «۳ تا ۵ درصد» همان درصد باقیماندهای است که رابط usage نشان میدهد، نه ۳ تا ۵ درصد از زمان واقعی، tokens یا مقدار تضمینشدهای از کار مهندسی.
کاربران واجد شرایط Plus اکنون میتوانند بعد از تمام شدن سهم مشمول، با credits استفاده Codex را ادامه دهند. این موضوع workflow را بیاعتبار نمیکند؛ فقط مرزش را روشن میکند. من درباره نحوه تخصیص استفاده مشمول خودم حرف میزنم، نه روشی برای دور زدن quota.
در ۳ تا ۵ درصد آخر چه چیزی را شروع میکنم
کارهایی که معمولاً برای این لحظه نگه میدارم عملیات مهندسی گستردهاند:
- مهاجرت کامل به TypeScript
- پاکسازی ESLint در کل repository
- بررسی عمیق باگ در codebaseهای بزرگ
- refactor ساختاری بزرگ
ترجیح میدهم یکی از این کارها را بهعنوان یک اجرای جدی شروع کنم تا اینکه باقیمانده را بین چند درخواست کمارزش تقسیم کنم. در این نوع کارها repository آماده و هدف روشن از یک prompt هوشمندانه مهمتر است.
چند پروژه آماده نیز به همین دلیل مفید است. اگر یک repository هنوز به تصمیم یا setup نیاز داشته باشد، پنجره آخر را صرف آمادهسازی آن نمیکنم؛ سراغ پروژهای میروم که آماده است.
محدودیت واقعی، آمادهسازی است
ترفند این نیست که «تا ۳ درصد صبر کن و بعد یک prompt عظیم بچسبان». اگر task مبهم باشد، budget محدود در exploration، پرسشهای روشنکننده یا رفتن در جهت اشتباه هدر میرود. الگوی من فقط وقتی مفید است که پروژه آماده اجرا و task دقیقاً محدود شده باشد.
برای workflow مشابه، بهتر است قبل از delegation مشخص باشد چه چیزی باید تغییر کند، چه چیزی نباید تغییر کند، چه constraintهایی مهماند، نتیجه چگونه validate میشود و از agent چه خروجیای انتظار دارید. اینها safeguards عمومی مهندسیاند، نه مدرکی که format خاصی از prompt استفاده بیشتری آزاد میکند.
این آمادهسازی باعث میشود اگر limit واقعاً task را متوقف کرد، ادامه دادن هم سادهتر باشد. وقتی scope و معیارهای validation از ابتدا روشن باشند، ادامه یک migration یا review نیمهتمام بسیار راحتتر است.
چه چیزی را میتوانم تأیید کنم — و چه چیزی را نه
چیزی که از تجربه خودم میتوانم تأیید کنم محدود است: چند بار taskای که از قبل شروع شده بود، بعد از تمامشده به نظر رسیدن محدودیت قابلمشاهده همچنان پیش رفت و گاهی کامل شد.
اما mechanism را نمیتوانم تأیید کنم. نمیتوانم بگویم OpenAI به همه taskهای در حال اجرا grace period مخفی میدهد، ۳ تا ۵ درصد آخر برای پایان هر کار بزرگی کافی است، این behavior ثابت میماند یا راهی برای عبور از limit است. مستندات OpenAI چنین چیزی را تضمین نمیکند.
این تفاوت مهم است. من با توجه به رفتاری که بارها دیدهام برنامهریزی میکنم، اما آن را تضمین فرض نمیکنم. اگر task روی limit متوقف شود، به این معنا نیست که چیزی خراب شده است. اگر استفاده باقیمانده به کاری مهمتر از چند prompt کوچک رسیده باشد، strategy هدفش را انجام داده است.
تمام شدن task یعنی تأیید شدن آن نیست
هرچه task بزرگتر شود یک تفکیک دیگر مهمتر میشود: completion مساوی correctness نیست. مهاجرت TypeScript که build میشود، صحت رفتار runtime را ثابت نمیکند. ESLint تمیز، صحت business logic را ثابت نمیکند. bug review که pattern مشکوکی پیدا میکند لزوماً bug واقعی را تأیید نکرده است. حتی refactor با tests سبز فقط به اندازه پوشش tests و checks قابل اعتماد است.
این workflow زمان شروع کار را تغییر میدهد، نه استاندارد validation را. تغییرات agentic بزرگ همچنان به بررسی متناسب با ریسک نیاز دارند: diff review، typecheck، tests، build، runtime checks یا verification مخصوص پروژه.
چه زمانی این الگو مناسب نیست
هر task بزرگی برای انتهای limit مناسب نیست. وقتی کار هنوز مبهم است، تصمیمهای مکرر محصول لازم دارد، عملیات destructive یا production-sensitive دارد، یا اگر نیمهکاره قطع شود repository را در وضعیت خطرناک میگذارد، این approach ضعیفتر است.
در این حالتها یک task کوچکتر و well-bounded یا یک usage window تازه معمولاً تصمیم مهندسی بهتری است. هدف dramatic کردن آخرین prompt نیست؛ هدف این است که استفاده مشمول محدود به کاری برسد که بتواند با ایمنی پیشرفت مفید ایجاد کند.
قانون فعلی من
وقتی استفاده مشمول Codex در ChatGPT Plus من به حدود ۳ تا ۵ درصد میرسد، دیگر تعداد promptهای باقیمانده را optimize نمیکنم. پروژههای آماده را نگاه میکنم و سنگینترین کار مهندسی روشن و ارزشمند را شروع میکنم.
اگر Codex بعد از صفر شدن شمارنده قابلمشاهده ادامه داد، آن را behavior مفیدی میدانم که مشاهده کردهام، نه حقی تضمینشده. اگر متوقف شد، تعجب نمیکنم. من راهی برای دور زدن limit پیدا نکردم؛ راه بهتری برای انتخاب کاری پیدا کردم که قبل از رسیدن به limit باید شروع شود.