আপডেট — ২০২৬ সালের গ্রীষ্ম: আমার জন্য এটি আর কাজ করেনি
২০২৬ সালের গ্রীষ্ম নাগাদ এই workflow আমার জন্য আর নির্ভরযোগ্যভাবে কাজ করছিল না। আমার account থেকে ৫-ঘন্টার usage window-এর counter অদৃশ্য হয়ে যায়, আর weekly limit দৃশ্যমান থাকে। ফলে যে ছোট reset window ধরে আমি আগে এই workflow-এর timing ঠিক করতাম, বাস্তবে সেটির ওপর আর নির্ভর করা যাচ্ছিল না।
আরও গুরুত্বপূর্ণ পরিবর্তন ছিল দীর্ঘ task-এর আচরণে। বড় একটি Codex task আমার weekly allowance-এর শেষ সীমায় পৌঁছালে আমি দেখেছি কাজ শেষ পর্যন্ত চলার বদলে থেমে যাচ্ছে। তাই আমার পুরোনো rule — “শেষ ৩–৫%-এ সবচেয়ে ভারী task শুরু করো” — অনেকটাই অর্থ হারায়: চলমান task weekly limit শেষ হওয়ার পরও টিকে থাকবে বলে আর ধরে নিতে পারতাম না।
তবে আমার observation আর official product rule আলাদা রাখা জরুরি। আমি আমার account এবং workflow-এ যা দেখেছি তা নিশ্চিত করতে পারি, কিন্তু OpenAI সব user-এর জন্য ৫-ঘন্টার window স্থায়ীভাবে সরিয়ে দিয়েছে—এটি প্রমাণ করতে পারি না। বর্তমান Codex documentation এখনও ৫-ঘন্টার এবং weekly—দুই ধরনের window-এর কথা বলে এবং জানায় যে active turn limit-এ পৌঁছানোর পর fair-use সীমার মধ্যে কখনও কখনও চলতে পারে। তাই ২০২৬ সালের গ্রীষ্মের পরিবর্তনকে আমি নিজের বাস্তব অভিজ্ঞতা হিসেবে লিখছি, সব account-এর universal rule হিসেবে নয়।
বাকি article-টি এই পরিবর্তনের আগে আমার জন্য সত্যিই কাজ করা workflow-এর রেকর্ড হিসেবে রাখা হয়েছে। বর্তমান অবস্থার জন্য উপরের update-টি পুরোনো লেখার present-tense recommendation-এর চেয়ে অগ্রাধিকার পাবে।
ChatGPT Plus-এ আমার Codex usage counter যখন প্রায় শেষ ৩–৫%-এ নেমে আসে, আমি আর সেই অংশ ছোট prompt-এ খরচ করি না। আমি উল্টোটা করি: আগে থেকেই প্রস্তুত রাখা সবচেয়ে বড় engineering task শুরু করি।
আমার ক্ষেত্রে সাধারণত সেটা হয় পূর্ণ TypeScript migration, পুরো repository জুড়ে ESLint cleanup, বড় codebase-এর deep bug review, অথবা বড় structural refactor। আমি প্রায়ই একাধিক project আগে থেকে প্রস্তুত রাখি, যাতে শেষের usage যেই heavy task প্রস্তুত আছে সেখানে দিতে পারি।
এর কারণ একটি পুনরাবৃত্ত পর্যবেক্ষণ। একাধিকবার আমি visible limit-এর একেবারে কাছাকাছি বড় কাজ শুরু করেছি, তারপর limit শেষ দেখালেও Codex-কে কাজ চালিয়ে যেতে দেখেছি। কখনও task শেষও হয়েছে। অভিজ্ঞতাটি এতবার ঘটেছে যে আমার scheduling বদলেছে, কিন্তু এটাকে product guarantee বানানো ঠিক হবে না।
যে পর্যবেক্ষণ আমার workflow বদলেছে
Usage limit-এর কাছে গেলে স্বাভাবিক প্রবণতা হলো conservative হওয়া: বড় task মাঝপথে থেমে যেতে পারে বলে শেষ অংশ ছোট request-এ ব্যবহার করা। আমি এখন শেষ ৩–৫%-কে অন্যভাবে দেখি। আমার কাছে এটি একটি launch window।
প্রশ্নটি আর “আর কতগুলো ছোট prompt চালাতে পারব?” নয়। বরং “included usage থাকা অবস্থায় সবচেয়ে মূল্যবান কোন প্রস্তুত task এখন শুরু করা উচিত?”
এটি কাজ করে কারণ project আগে থেকেই ready এবং task পরিষ্কারভাবে defined। শেষ কয়েক শতাংশ আমি কাজ কী হবে তা খুঁজতে ব্যবহার করি না; execution শুরু করতে ব্যবহার করি।
নাম ও limit নিয়ে একটি গুরুত্বপূর্ণ সংশোধন
আমি আগে একে “Codex Plus” বলতাম, কিন্তু সেটি official product name নয়, shorthand। OpenAI-এর ভাষায় Codex ChatGPT Plus-এর সঙ্গে অন্তর্ভুক্ত। এই পার্থক্যটি গুরুত্বপূর্ণ, কারণ “Codex Plus” শুনলে আলাদা plan বা product মনে হতে পারে।
OpenAI-এর বর্তমান Codex usage documentation বলছে usage কাজের আকার ও জটিলতা, model এবং task কোথায় run করছে তার ওপর নির্ভর করে। সেখানে ৫ ঘণ্টার window এবং weekly window-ও আছে। তাই এখানে “৩–৫%” বলতে আমি UI-তে দেখা remaining percentage বোঝাচ্ছি; wall-clock time, tokens বা নিশ্চিত পরিমাণ engineering work নয়।
Eligible Plus user-রা included limit শেষ হওয়ার পরে credits দিয়েও Codex usage বাড়াতে পারেন। এতে workflow-এর মূল ধারণা বদলায় না; শুধু boundary পরিষ্কার হয়। আমি included usage কীভাবে বরাদ্দ করি তা বলছি, quota bypass করার পদ্ধতি নয়।
শেষ ৩–৫%-এ আমি কী শুরু করি
এই মুহূর্তের জন্য আমি সাধারণত broad engineering operation রাখি:
- পূর্ণ TypeScript migration
- repository-wide ESLint cleanup
- বড় codebase-এর deep bug review
- বড় structural refactor
শেষের allowance অনেক ছোট request-এ ভাগ করার বদলে আমি এই কাজগুলোর একটি substantial run শুরু করতে পছন্দ করি। এখানে clever prompt-এর চেয়ে prepared repository এবং পরিষ্কার target বেশি গুরুত্বপূর্ণ।
একাধিক project ready রাখার সুবিধাও এটাই। একটি repository-তে সিদ্ধান্ত বা setup বাকি থাকলে শেষ window সেটি প্রস্তুত করতে নষ্ট না করে অন্য ready project-এ কাজ শুরু করতে পারি।
আসল constraint হলো preparation
কৌশলটি “৩% পর্যন্ত অপেক্ষা করে বিশাল prompt paste করা” নয়। Task অস্পষ্ট হলে সীমিত budget exploration, clarification বা ভুল direction-এ চলে যেতে পারে। আমার pattern তখনই useful যখন project execution-ready এবং task well scoped।
এ ধরনের delegation-এর আগে scope পরিষ্কার করা ভালো: কী বদলাবে, কী বদলাবে না, কী constraint আছে, ফলাফল কীভাবে validate হবে এবং agent-এর কাছ থেকে কী output দরকার। এগুলো সাধারণ engineering safeguard; বিশেষ prompt format বেশি usage unlock করে—এমন প্রমাণ নয়।
এতে limit task থামিয়ে দিলে পরে resume করাও সহজ হয়। Scope এবং validation criteria শুরু থেকেই পরিষ্কার থাকলে partial migration বা review চালিয়ে নেওয়া অনেক সহজ।
আমি কী নিশ্চিত করতে পারি — আর কী পারি না
আমার নিজের ব্যবহারে আমি শুধু এটুকু নিশ্চিত করতে পারি: একাধিকবার আগে থেকে শুরু করা task visible usage limit শেষ দেখানোর পরও progress করেছে, এবং কখনও complete হয়েছে।
Mechanism আমি নিশ্চিত করতে পারি না। OpenAI সব running task-কে hidden grace period দেয়, শেষ ৩–৫% যেকোনো বড় কাজ শেষ করার জন্য যথেষ্ট, behavior স্থায়ী, বা এটি limit এড়ানোর উপায়—এর কোনোটিই আমি দাবি করতে পারি না। OpenAI documentation-ও এমন promise করে না।
এই পার্থক্যটাই গুরুত্বপূর্ণ। আমি বারবার দেখা behavior মাথায় রেখে plan করি, কিন্তু guarantee ধরে নিই না। Limit-এ task থেমে গেলে সেটি failure নয়। Remaining included usage যদি কয়েকটি tiny prompt-এর বদলে বেশি গুরুত্বপূর্ণ কাজে যায়, strategy তবুও কাজ করেছে।
Task শেষ হওয়া মানেই verified নয়
Task বড় হলে আরেকটি distinction জরুরি: completion correctness নয়। TypeScript migration build করলেই runtime behavior সঠিক প্রমাণ হয় না। ESLint clean হলেই business logic সঠিক নয়। Bug review suspicious pattern দেখালেই confirmed bug নয়। Refactor tests pass করলেও সেই confidence tests ও checks-এর coverage-এর ওপর নির্ভর করে।
এই workflow শুধু কখন কাজ শুরু করি তা বদলায়; validation standard কমায় না। Risk অনুযায়ী বড় agentic change-এ diff review, typecheck, tests, build, runtime check বা project-specific verification দরকার।
কখন এই pattern ভালো fit নয়
সব বড় task end-of-limit task নয়। Work এখনও unclear হলে, frequent product decision লাগলে, destructive বা production-sensitive operation থাকলে, বা মাঝপথে থামলে repository risky state-এ থাকলে এই approach দুর্বল।
সেসব ক্ষেত্রে ছোট well-bounded task বা fresh usage window ভালো engineering choice। লক্ষ্য শেষ prompt-কে dramatic করা নয়; scarce included usage এমন কাজে দেওয়া যা safely useful progress করতে পারে।
এখন আমার নিয়ম
ChatGPT Plus-এ included Codex usage যখন প্রায় ৩–৫%-এ নামে, আমি remaining prompt-এর সংখ্যা optimize করা বন্ধ করি। আগে থেকে প্রস্তুত project দেখি এবং সবচেয়ে heavy, clearly scoped, worth-doing engineering task শুরু করি।
Visible counter zero হওয়ার পরও Codex কাজ করলে আমি সেটিকে useful observed behavior হিসেবে দেখি, entitlement হিসেবে নয়। থেমে গেলে অবাক হই না। আমি limit-এর রাস্তা ঘুরে যাওয়ার উপায় পাইনি; limit-এ পৌঁছানোর আগে কী শুরু করব, সেটি বেছে নেওয়ার ভালো উপায় পেয়েছি।