OpenAI ने Codex Model Context Size को 372k से घटाकर 272k किया
OpenAI ने अपने Codex coding agent के लिए context window को अस्थायी रूप से 372k से 272k tokens तक घटा दिया है, जिससे बड़े और लंबे समय तक चलने वाले software projects के लिए cost savings बनाम capability पर बहस छिड़ गई है। कई उपयोगकर्ताओं का कहना है कि conversation history और code context की आक्रामक, अस्पष्ट “compaction” जटिल workflows को बिगाड़ सकती है, खासकर जब बड़े codebases, कई repositories, या बड़े rule files के साथ काम किया जा रहा हो; जबकि अन्य का तर्क है कि अच्छी planning, subagents, और external markdown “memory” छोटे windows की भरपाई काफी हद तक कर देते हैं और बहुत लंबे context lengths पर quality loss से बचाते हैं। Anthropic के million-token models और DeepSeek-style caching से तुलना एक व्यापक तनाव को दिखाती है: क्या frontier tools को विशाल raw context को प्राथमिकता देनी चाहिए या context management और harness design को अधिक स्मार्ट और अधिक controllable बनाना चाहिए।
Context Size में कमी और कारण
- Codex की context window को 372k से घटाकर 272k tokens कर दिया गया; commit और tweets से संकेत मिलता है कि यह अस्थायी cost/usage नियंत्रण है, capabilities में बदलाव नहीं।
- कुछ लोग बताते हैं कि इससे higher-priced long-context tiers ट्रिगर होने से बचाव होता है, जो पहले उपयोगकर्ताओं को अनपेक्षित रूप से प्रभावित करते थे।
- एक टिप्पणी में कहा गया है कि underlying models 1M context तक संभाल सकते हैं, लेकिन Codex के client limits कम हैं ताकि कुल (input + max output) billing threshold के अंदर रहे।
Cost/Trajectory Chart को समझना
- कई पाठकों को पोस्ट किया गया cost chart भ्रमित करने वाला लगा; दूसरों ने इसे इस तरह समझाया कि turn count के साथ cumulative cost लगभग quadratic रूप से बढ़ती है, और compaction तक ऐसा होता है, जबकि छोटा context (जैसे 200k) बड़े (300k) की तुलना में लगातार सस्ता trajectory देता है।
- इस बात पर असहमति है कि क्या curve quadratic attention को दर्शाता है या सिर्फ cumulative linear costs को।
वास्तविक workloads पर प्रभाव
- एक बड़ा समूह कहता है कि 272k बड़े codebases, reverse engineering, या कई plans, reviews, और long-running agents वाले workflows के लिए बहुत छोटा है; वे अक्सर limit के पास रहते हैं और बार-बार compactions झेलते हैं।
- दूसरों का तर्क है कि अधिकांश समस्याओं को ~200–300k से कम chunks में तोड़ा जा सकता है और ऐसा करना चाहिए; छोटे contexts बेहतर quality और कम cost देते हैं।
Compaction: Quality, Control, और Workarounds
- कई लोग Codex की auto-compaction की शिकायत करते हैं:
- यह लगभग 10–20% शेष context पर ट्रिगर हो जाती है, और इसे disable या roll back करने का तरीका नहीं है।
- कभी-कभी model हाल के tasks या पहले पढ़े गए code को “भूल” जाता है, जिससे re-scans करने पड़ते हैं और tokens खर्च होते हैं।
- अन्य लोगों का कहना है कि पहले releases के मुकाबले Codex compaction काफी बेहतर हुई है और उनके लिए ठीक काम करती है।
- इसे कम करने की सामान्य रणनीतियाँ:
- chat history पर निर्भर रहने की बजाय markdown “plan”/“rules”/“report” files को स्थायी memory की तरह इस्तेमाल करना।
- subagents, hierarchical planning, और ऐसे external tools का आक्रामक उपयोग करना जो prior context को store करके फिर से inject करते हैं।
- sessions को manually restart करना या लगभग 200–300k पर context साफ करना।
अन्य Models और Harnesses से तुलना
- कई उपयोगकर्ता कहते हैं कि वे ~1M context वाले models (जैसे Anthropic, DeepSeek, अन्य) के साथ बने रहेंगे या उन्हीं पर जाएंगे, भले ही कुछ सौ हज़ार tokens के बाद उनमें भी similar degradation दिखती हो।
- दूसरों का कहना है कि long-context marketing वास्तविक usable context को बढ़ा-चढ़ाकर पेश करती है; उन्हें कई models में 120–300k के आसपास एक “dumb zone” दिखता है।
- कुछ लोग alternative open-source या third-party harnesses को पसंद करते हैं जिनमें tunable compaction, history trees, और stronger user control होता है।
Safety और Harness Design
- वही commit destructive actions से पहले stricter system-prompt guidance जोड़ता है (जैसे, home या root directories को recursively delete न करें), ताकि accidental mass deletion के वास्तविक मामलों का जवाब दिया जा सके।
- आगे isolation (containers, guarded
rmwrappers) के लिए समर्थन है और agents को destructive commands चलाने देने पर skepticism भी है।