OpenAI ने Codex मॉडल का context size 372k से घटाकर 272k किया

• OpenAI Codex के bundled model metadata को अपडेट करते हुए मॉडल का context size 372k से घटाकर 272k करने वाला बदलाव release/0.144 branch में backport किया गया
• PR #33972 ने agent/hotfix-0.144-model-metadata branch से बदलावों को Codex 0.144 release में स्थानांतरित किया
• बदलाव का दायरा 1 JSON file तक सीमित है, और diff आँकड़े 64 lines added · 54 lines deleted हैं
• अलग से किसी चर्चा या review के बिना, 1 commit और 36 checks के बाद इसे merge किया गया
• उपलब्ध page में file diff load नहीं हो रहा, इसलिए context reduction के अलावा metadata में कौन-से ठोस बदलाव हुए यह पुष्टि नहीं की जा सकती

---

बदलाव का उद्देश्य और दायरा

• PR का शीर्षक updated bundled model metadata को Codex 0.144 में backport करने का काम है
• Hacker News शीर्षक के अनुसार मॉडल का context size 372k से 272k कर दिया गया
• target branch openai:release/0.144 है, और source branch sayan-oai:agent/hotfix-0.144-model-metadata है

merge का परिणाम

• PR #33972 में 1 commit b06f4fa शामिल है
• commit का शीर्षक Backport refreshed bundled model metadata है
• यह 18 जुलाई 2026 को merge हुआ, और 36 checks तथा 1 file change दिखाया गया है
• बदलाव की मात्रा 64 lines added और 54 lines deleted है, और file format JSON है

पुष्टि की जा सकने वाली सीमाएँ

• page के file और comment sections में load error दिख रहा है, इसलिए वास्तविक JSON diff उपलब्ध सामग्री में देखा नहीं जा सकता
• reproduction steps, बदलाव का कारण, compatibility impact, review feedback जैसी बातें सामग्री में शामिल नहीं हैं

[GN⁺]

Hacker News की राय

• लोग कहते हैं कि compression से समस्या हल हो जाती है, लेकिन मेरे काम में compression से गायब हो जाने वाली details बहुत ज़्यादा होती हैं
  अगर plan सरल हो या बहुत बारीक चर्चा न हो, तो ठीक हो सकता है, लेकिन लंबे context की कमी के कारण आखिरकार मैं Anthropic ही इस्तेमाल करता रहता हूँ
  जब कई papers या बड़े और जटिल materials को पूरी तरह याद रखना होता है, तो context हमेशा 16% पर ही रहता है। करीब 5 मिनट बात करने के बाद compress हो जाता है, फिर materials दोबारा पढ़वाकर 16% तक पहुँचने की प्रक्रिया दोहरती रहती है
  372k context भी perfect नहीं था, लेकिन इसने 12–20% वाली गुंजाइश को लगभग 40% तक बढ़ा दिया था, जिससे काफी मदद मिली

  • Auto compression बंद नहीं किया जा सकता और compression से पहले की conversation history पर वापस भी नहीं जा सकते, इसलिए 5,000 lines से बड़े codebase में Codex इस्तेमाल नहीं कर सकता
    जब बचा हुआ context 10–20% होता है, यह randomly चल जाता है, इसलिए 272k का केवल 80% ही असल में इस्तेमाल हो पाता है। compression के बाद hallucination बहुत बढ़ जाती है, जो शुरुआत से शुरू करने से भी खराब है, और codebase को फिर से पढ़ते-पढ़ते फिर compression वाले चक्र में फँस जाता है
  • मेरी design process अलग है। कई बार revise होने वाला plan.md ही memory है, और session restart करके plan को दोबारा पढ़ना और review करना नए perspective पाने के लिए अच्छा रहता है
  • compression इतनी खराब है कि मैंने ऐसा tool बनाया है जिससे LLM context के कुछ हिस्सों को चुनकर delete कर सके और ज़रूरत पड़ने पर restore कर सके। अगर आप अक्सर auto compression limits से टकराते हैं, तो context bonsai आज़माने लायक है
    https://github.com/Vibecodelicious/context-bonsai-agents
  • Anthropic models 1 million token context देते हैं। अगले महीने OpenAI पर shift करने वाला था, लेकिन यह अभी भी लगभग 300k पर अटका है, तो लगता है नई reality के हिसाब से adjust करना पड़ेगा
  • आम तौर पर सलाह दी जाती है कि agent कभी-कभी .md files बनाए या update करे ताकि नई उभरी महत्वपूर्ण जानकारी याद रखी जा सके। लेकिन अगर agent को ठीक-ठीक पता हो कि सच में क्या important है, तो /compact भी ठीक से काम करना चाहिए

• बड़े context window के कारण हम यह चुनना बंद कर बैठे कि क्या डालना है, और compression पूरे context पर एक साथ lossy compression लागू कर देता है, जिससे ज़रूरी details भी खो जाती हैं
  मेरे हिसाब से हर बार पूरी conversation दोबारा भेजना ही मूल समस्या है। मेरे बनाए memory/context plugin से हर turn पर context खाली करके सिर्फ relevant information दोबारा inject करता हूँ, तो model 200k tokens की conversation history के बजाय चुने हुए कुछ हज़ार tokens की state ही पढ़ता है, इसलिए छोटा context समस्या नहीं बना
  coding agent में इसे अभी हल नहीं कर पाया हूँ, लेकिन task complete होने या अगले task के लिए ज़रूरी चीज़ें ही बनाए रखना और बाकी फेंक देना—ऐसी retention policy ही असली समाधान है, और इसे dedicated LLM से implement किया जा सकता है

  • LSTM और GRU वगैरह पर research करने वाले कई natural language processing experts भी पूरी conversation दोबारा भेजने को मूल समस्या मानते थे, लेकिन empirical तौर पर Transformer जीत गया
    भविष्य के model architectures इस समस्या पर फिर से विचार करेंगे या नहीं, यह दिलचस्प होगा। इंसानों को benchmark मानें तो जो चीज़ अभी कम है, वह short-term memory से long-term memory में information को efficiently ले जाने की क्षमता है; fine-tuning सिद्धांततः कुछ वैसा ही करता है, लेकिन efficient नहीं है

• पता नहीं इस बदलाव की वजह यही है या नहीं, लेकिन शुरुआत से ही इससे बड़ा context इस्तेमाल करना आम तौर पर mistake लगता है
  context बढ़ने पर model performance कितना गिरता है और token cost कितनी बढ़ती है, लोग इसे underestimate करते हैं। Claude 300k से ऊपर इस्तेमाल नहीं करता और compress करने के बजाय काम को बाँटता है, documents और modular codebase को concise रखता है
  one-off tasks में बड़ा context उपयोगी हो सकता है, लेकिन अगर आप लगातार 300k से ऊपर जा रहे हैं, तो संभव है आप बहुत कुछ खो रहे हों या codebase design अच्छा न हो

  • मैं भी 250k पर compress या restart करता हूँ। ज़रूरी context size project size के proportion में होता है, इसलिए जिन्हें bigger window चाहिए, वे शायद बस बड़े projects handle कर रहे हैं
  • मेरा अनुभव भी यही है, और मैं boundary बल्कि 100–150k मानूँगा। model लंबे context को support करता हो, तब भी actual performance अच्छी नहीं होती
  • context बढ़ने से model visibly बेवकूफ़ हो जाता है—यह बात मेरे अनुभव से मेल नहीं खाती। यह slow और expensive हो जाता है, लेकिन complex tasks के लिए यह cost उठानी पड़ती है
    main agent sub-agents से ज़रूरी चीज़ें investigate कराता है और plan लिखवाता है, फिर दूसरे sub-agents से adversarial review कराकर उसे मजबूत कराता है। खत्म होने पर 1 million token window का 30–40% भर जाता है, और 272k में यह flow संभव नहीं है
    5.6 Sol में इस process को काफी छोटा करना पड़ा, और शायद इसी वजह से result भी खराब है

• जब यह बदलाव हुआ, Tibo ने साथ में explanation पोस्ट किया था: https://x.com/thsottiaux/status/2076543065045795309

  • replies यहाँ देखे जा सकते हैं: https://xcancel.com/thsottiaux/status/2076543065045795309
    linked tweet Tibo की official information पर unofficial reply है, और Tibo ने replies में content correct किया है
  • यह chart समझ नहीं आ रहा। compress करने के बावजूद line लगातार ऊपर क्यों जा रही है, या फिर “overall trajectory size” में कोई ऐसा meaning छिपा है जो मुझे नहीं पता
  • reasoning intensity अलग होने के बावजूद overall trajectory length same हो सकती है या नहीं, समझ नहीं आता। reasoning tokens को trajectory length से exclude कर दें, तब भी यह संभव नहीं लगता

• मुझे इनके context compression पसंद नहीं हैं, और अब मुझे लगता है कि इन्हें कम-से-कम 10 लाख tokens देने चाहिए
  GPT 5.5 और 5.6 हर बार compression होने पर अपनी रफ्तार पकड़ने तक अटकते हैं, और compressed context में बचे पुराने instruction messages पर ज़रूरत से ज़्यादा ध्यान भी देने लगते हैं

  • GPT-5.6-Sol, Opus/Fable की तुलना में token efficiency में करीब 2x है, इसलिए अधिकतम 258k, Claude के करीब 516k के बराबर है
    Context decay अब भी समस्या है[1][2], और agent workflows में compression लंबे context के बराबर या उससे बेहतर है, इसके भी प्रमाण हैं[3]. अगर model 256k की तरह 1M context पर भी reasoning कर सके तो सबसे अच्छा होगा, लेकिन अभी यह संभव नहीं है
    [1] https://arxiv.org/abs/2605.12366
    [2] Opus 4.8 System Card में GraphWalks 256K और 1M F1 की तुलना: https://www-cdn.anthropic.com/0b4915911bb0d19eca5b5ee635c80f...
    [3] https://context-folding.github.io/
  • दूसरे coding tools के उलट automatic compression disable नहीं किया जा सकता, यह झुंझलाहट भरा है। यह बचे हुए context के 10~20% पर अनियमित रूप से चलता है, इसलिए guaranteed capacity 272k का सिर्फ 80% है
    बड़े codebase में जब काम लगभग खत्म हो और करीब 2 हजार tokens का response ही बाकी हो, तब 20% से नीचे जाते ही काफी देर processing के बाद Context compacted दिखता है। Compression से पहले वाली स्थिति में वापस नहीं जा सकते, इसलिए codebase को फिर से खंगालना पड़ता है, फिर दोबारा compression हो जाता है, और आखिर में सारे tokens खत्म हो जाते हैं
  • उम्मीद है token reduction usage बढ़ाने की कोई चाल नहीं, बल्कि मुख्यतः cost cutting के लिए है। हमारी company में भी cost संभालने वालों ने context को बहुत ज्यादा limit कर दिया, जिससे शुरुआत में ठीक-ठाक काम करने वाला internal LLM लगभग बेकार हो गया
    लगता है executives के बीच सबसे खराब practices साझा करने की कोई meeting होती होगी
  • Working memory Markdown files में store की जा सकती है और बड़े context की जरूरत नहीं होती। Context बढ़ने पर attention बिखर जाती है और LLM की performance गिरती है, इसलिए इसे छोटा रखना quality के लिए बेहतर है

• रोजमर्रा में Opus इस्तेमाल करता हूं और /clear अक्सर चलाता हूं। 1M context भी 50% के करीब पहुंचने पर तेजी से performance degrade होने लगती है, इसलिए आम तौर पर 30~40% पर reset करने से काफी बेहतर results मिलते हैं
  Compression की बजाय नए सिरे से शुरू करके जरूरी context शुरुआत से डालना बेहतर काम करता है। Feature-wise Markdown docs को कई tech collections में organize करके रखना, और पहली loading पर यह बताना कि काम से जुड़ी जानकारी कहां मिलेगी, असरदार तरीका है

• Codex में मुझे context size कभी समस्या नहीं लगी। Compression कैसे होता है पता नहीं, लेकिन यह जैसे कोई limit ही न हो, वैसे चलता रहता है

  • लगता है आपने Codex हाल ही में इस्तेमाल करना शुरू किया है। शुरुआत में compression से भी recover न हो पाने वाली model context size exceeded error बहुत गंभीर थी, और यह कुछ ही महीने पहले गायब हुई है
    अब काफी बेहतर है, लेकिन compression के बाद concise summary में क्या गया, यह नहीं दिखाता, इसलिए पता लगाना मुश्किल है कि जरूरी चीजें बची हैं या नहीं
    Codex लगता है users से ज्यादा-से-ज्यादा चीजें छिपाने की दिशा में जा रहा है; जैसे हाल में agent और sub-agent के बीच prompts encrypt किए, वैसे ही पूरा session log भी encrypt कर सकता है। अफसोस है, लेकिन अब तक जो इस्तेमाल किया है उनमें यह अभी भी best tool·model combo है
  • Codex में compression होने पर यह अक्सर आखिरी task पूरा करना भूल जाता है, खासकर जब compression से ठीक पहले message भेजा गया हो
  • ज्यादातर problems को divide and conquer किया जा सकता है, इसलिए 300k और 400k का फर्क शायद ही समस्या बनता है। Coding agent कोई infinite conversation नहीं है

• Compression कितना भी अच्छा हो, बड़े projects में कई files पढ़नी पड़ती हैं। शुरुआती 200k tokens बहुत तेजी से खर्च हो जाते हैं, लेकिन उसके बाद speed धीमी पड़ जाती है
  Fable sessions ज्यादातर 500k tokens से ऊपर नहीं जाते, इसलिए compression की जरूरत नहीं पड़ती, लेकिन Codex में एक ही session में बार-बार compression करना पड़ता है

  • मेरे हिसाब से कई files पढ़ने की वजह यह है कि agents.md कमजोर है। असल working files और कुछ related files ही पढ़नी चाहिए, बाकी चीजें docs में summarized होनी चाहिए

• मेरे काम के लिए यह काफी छोटा size है। मैं 200k से नीचे रखने की कोशिश करता हूं, लेकिन DeepSeek और MiMo sessions में आखिरी iteration push करने पर यह 350k tokens तक बढ़कर फिर compress हो जाता है
  सोचता हूं कि OpenAI क्या public paper में बताई गई DeepSeek की K/V cache technology अपनाकर cost को काफी घटा नहीं सकता

  • DeepSeek जितनी अच्छी caching कोई नहीं करता, इसलिए implementation differences इतने बड़े हैं कि copy करना मुश्किल लगता है
    DeepSeek को Reasonix के साथ इस्तेमाल करने पर cache structure के हिसाब से अतिरिक्त dedicated तरीका मिलता है, जिससे लंबे sessions में 97~98% tokens cache हो जाते हैं। जो model पहले से सस्ता है, वह और सस्ता हो जाता है
  • llamacpp-based local public models में agent के निर्देश पर 55k~85k के बीच compression होता है, और अगर complex log tracing जैसे बड़े context की सख्त जरूरत न हो तो 120k तक जाना rare है
    llamacpp के inference budget और messages के हिसाब से agent sub-agents बनाकर content compress करे, इसके लिए system prompt भी adjust किया है। opencode की dynamic context pruning का इस्तेमाल करके size बढ़ाए बिना direction बनाए रखता है, और कई sub-components को iteratively develop करने में यह कुल मिलाकर अच्छा काम करता है

• पिछले दो महीनों में मेरे use case के लिए यह काफी बेहतर रहा, इसलिए Claude से OpenAI पर switch कर लिया। इस बदलाव से output quality में फर्क महसूस होगा या नहीं, यह देखने की उत्सुकता है