अपडेट — 2026 की गर्मियां: मेरे लिए यह तरीका काम करना बंद कर गया
2026 की गर्मियों तक यह workflow मेरे लिए भरोसेमंद तरीके से काम करना बंद कर चुका था। मेरे account से 5-hour usage window का counter गायब हो गया, जबकि weekly limit दिखाई देती रही। व्यवहार में इसका मतलब था कि वह छोटा reset window नहीं रहा जिसके आसपास मैं पहले इस workflow का timing तय करता था।
इससे भी महत्वपूर्ण बदलाव लंबे tasks में था। जब कोई बड़ा Codex task मेरे weekly allowance के अंत तक पहुंचता, मैंने काम को पूरा होने तक चलते रहने के बजाय रुकते देखा। इसलिए मेरी पुरानी rule — “आखिरी 3–5% में सबसे भारी task शुरू करो” — काफी हद तक बेकार हो गई: मैं अब यह मानकर नहीं चल सकता था कि शुरू हो चुका task weekly limit खत्म होने के बाद भी चलता रहेगा।
लेकिन मेरे observation और official product rule को अलग रखना जरूरी है। मैं अपने account और workflow में देखी बात की पुष्टि कर सकता हूं, पर यह साबित नहीं कर सकता कि OpenAI ने हर user के लिए 5-hour window स्थायी रूप से हटा दी। वर्तमान Codex documentation अभी भी 5-hour और weekly दोनों windows का उल्लेख करती है और कहती है कि active turn limit पहुंचने के बाद कभी-कभी fair-use limits के अधीन जारी रह सकता है। इसलिए मैं 2026 की गर्मियों के बदलाव को अपने वास्तविक अनुभव के रूप में लिख रहा हूं, न कि हर account पर लागू universal rule के रूप में।
बाकी article को उस workflow के रिकॉर्ड के रूप में रखा गया है जो इस बदलाव से पहले मेरे लिए सच में काम करता था। मौजूदा स्थिति में ऊपर दिया गया update पुराने text की present-tense recommendations से अधिक महत्वपूर्ण है।
जब मेरे ChatGPT Plus plan में Codex usage counter लगभग 3–5% पर आ जाता है, तो मैं बची हुई usage को छोटे prompts पर खर्च नहीं करता। मैं उल्टा करता हूँ: पहले से तैयार सबसे बड़ा engineering task शुरू कर देता हूँ।
मेरे मामले में यह आम तौर पर पूरा TypeScript migration, पूरे repository में ESLint cleanup, किसी बड़ी codebase का deep bug review या बड़ा structural refactor होता है। मैं अक्सर कई projects पहले से तैयार रखता हूँ, ताकि आखिरी usage उस heavy task को मिल सके जो वास्तव में run करने के लिए ready हो।
इसका कारण एक repeated observation है। एक से ज़्यादा बार मैंने visible limit के करीब बड़ा काम शुरू किया और limit खत्म दिखने के बाद भी Codex को काम जारी रखते देखा। कभी-कभी task इतना आगे गया कि पूरा हो गया। यह अनुभव मेरे scheduling को बदलने के लिए काफी बार हुआ, लेकिन इसे product guarantee कहना सही नहीं होगा।
वह observation जिसने मेरा workflow बदला
Usage limit के पास natural instinct conservative होने का होता है: आखिरी हिस्सा छोटे requests पर खर्च करो, क्योंकि बड़ा task बीच में रुक सकता है। अब मैं आखिरी 3–5% को अलग तरह से देखता हूँ। मेरे लिए यह एक launch window है।
सवाल अब “और कितने छोटे prompts चला सकता हूँ?” नहीं है। सवाल है: “included usage रहते हुए सबसे valuable prepared task कौन-सा है जिसे अभी शुरू किया जा सकता है?”
यह तभी काम करता है जब project पहले से ready हो और task साफ़ defined हो। मैं आखिरी प्रतिशत यह तय करने में नहीं लगाता कि करना क्या है; मैं उन्हें execution शुरू करने में लगाता हूँ।
नाम और limit को लेकर जरूरी clarification
मैंने पहले इसे “Codex Plus” कहा था, लेकिन यह official product name नहीं, shorthand है। OpenAI Codex को ChatGPT Plus में शामिल बताता है। यह correction जरूरी है, ताकि “Codex Plus” किसी अलग plan या product जैसा न लगे।
OpenAI की मौजूदा Codex usage documentation यह भी कहती है कि consumption काम के size और complexity, model और task कहाँ run हो रहा है, उस पर निर्भर करता है। इसमें 5-hour और weekly usage windows भी documented हैं। इसलिए यहाँ “3–5%” का मतलब usage interface में दिखने वाला remaining percentage है, न कि wall-clock time, tokens या guaranteed engineering work का 3–5%।
Eligible Plus users included limit खत्म होने के बाद credits से Codex usage बढ़ा भी सकते हैं। इससे workflow गलत नहीं हो जाता; बस उसका scope साफ़ होता है। मैं अपने included usage को allocate करने की बात कर रहा हूँ, quota bypass करने की नहीं।
आखिरी 3–5% में मैं क्या शुरू करता हूँ
इस समय के लिए मैं आम तौर पर broad engineering operations रखता हूँ:
- पूरा TypeScript migration
- repository-wide ESLint cleanup
- बड़ी codebase का deep bug review
- बड़ा structural refactor
बची हुई usage को कई low-value requests में बाँटने की जगह मैं इनमें से किसी काम को substantial run देना पसंद करता हूँ। ऐसे tasks में clever prompt wording से ज़्यादा prepared repository और clear target मायने रखते हैं।
कई projects ready रखने का फायदा भी यही है। अगर एक repository को अभी decisions या setup चाहिए, तो आखिरी window उसे तैयार करने में बर्बाद नहीं करनी पड़ती; मैं दूसरे ready project पर काम शुरू कर सकता हूँ।
असल constraint preparation है
Trick यह नहीं है कि “3% तक wait करो और फिर बहुत बड़ा prompt paste कर दो।” Task ambiguous हो तो limited budget exploration, clarification या गलत direction में निकल सकता है। मेरा pattern तभी useful है जब project execution-ready हो और task well scoped हो।
ऐसा workflow आज़माने वाले developers के लिए practical preflight है: क्या बदलना है, क्या नहीं बदलना है, कौन-सी constraints हैं, result कैसे validate होगा और agent से कौन-सा output चाहिए। ये general engineering safeguards हैं, इस बात का proof नहीं कि किसी खास prompt format से ज्यादा usage unlock होती है।
अगर limit सच में task रोक दे, तो यही preparation उसे resume करना भी आसान बनाती है। Scope और validation criteria पहले से clear हों तो partial migration या review को continue करना काफी आसान होता है।
मैं क्या confirm कर सकता हूँ — और क्या नहीं
अपने use से मैं सिर्फ इतना narrow claim confirm कर सकता हूँ: कई बार पहले से शुरू task visible usage limit खत्म दिखने के बाद भी आगे बढ़ता रहा, और कभी-कभी complete हुआ।
Mechanism मैं confirm नहीं कर सकता। मैं यह claim नहीं कर सकता कि OpenAI हर running task को hidden grace period देता है, आखिरी 3–5% किसी भी बड़े काम को finish कराने की guarantee है, behavior stable है, या यह limit bypass करने का तरीका है। OpenAI documentation इनमें से किसी बात का promise नहीं करती।
यही distinction महत्वपूर्ण है। मैं repeated observation को ध्यान में रखकर plan करता हूँ, लेकिन उस पर निर्भर नहीं रहता। Limit पर task रुक जाए तो यह किसी failure का proof नहीं है। अगर remaining included usage कुछ tiny prompts की जगह ज्यादा महत्वपूर्ण काम पर लगी, तो strategy ने अपना उद्देश्य पूरा कर दिया।
Task खत्म होना verified होना नहीं है
Task जितना बड़ा होता है, एक दूसरी distinction उतनी जरूरी होती है: completion correctness नहीं है। TypeScript migration build हो जाए तो runtime behavior सही साबित नहीं होता। ESLint clean हो जाए तो business logic सही साबित नहीं होती। Bug review कोई suspicious pattern दिखाए तो confirmed bug नहीं हो जाता। Tests pass करने वाला refactor भी उतना ही मजबूत है जितनी tests और checks की coverage।
यह workflow सिर्फ काम शुरू करने का timing बदलता है; validation standard कम नहीं करता। बड़े agentic changes में risk के हिसाब से diff review, typecheck, tests, build, runtime checks या project-specific verification अभी भी जरूरी हैं।
कब यह pattern खराब fit है
हर बड़ा task end-of-limit task नहीं होना चाहिए। Work अभी unclear हो, frequent product decisions चाहिए हों, destructive या production-sensitive operations हों, या बीच में रुकने पर repository risky state में छूटे—तो यह approach कमजोर है।
ऐसी स्थिति में छोटा well-bounded task या fresh usage window बेहतर engineering choice है। Goal आखिरी prompt को dramatic बनाना नहीं है; scarce included usage को ऐसे काम पर लगाना है जो safely useful progress कर सके।
अब मेरा नियम
ChatGPT Plus में included Codex usage जब लगभग 3–5% पर आता है, तो मैं remaining prompts की गिनती optimize करना बंद कर देता हूँ। पहले से तैयार projects देखता हूँ और सबसे heavy, clearly scoped, worth-doing engineering task शुरू करता हूँ।
Visible counter zero होने के बाद Codex चलता रहे तो मैं उसे useful observed behavior मानता हूँ, entitlement नहीं। रुक जाए तो मुझे surprise नहीं होता। मैंने limit को bypass करने का तरीका नहीं खोजा; मैंने limit तक पहुँचने से पहले क्या शुरू करना है, यह चुनने का बेहतर तरीका खोजा।