Qwen Code की लंबी सेशन जारी रखें: कंप्रेशन और कॉन्टेक्स्ट सेटिंग
जब Qwen Code की लंबी सेशन कॉन्टेक्स्ट सीमा के पास पहुँचे, तो इतिहास तुरंत साफ न करें और विंडो का मान मनमाने ढंग से न बढ़ाएँ। पहले कोड और टास्क की स्थिति सुरक्षित करें, summary-based या fast compression चुनें, निरंतरता जाँचें, फिर autoCompactThreshold और contextWindowSize को उसी configuration level पर रखें जो वास्तव में लागू होता है।
विषय-सूची

Qwen Code की लंबी सेशन लगभग भर जाए तो शुरुआत /clear से न करें और contextWindowSize को बिना प्रमाण किसी बड़े अंक पर न रखें। सुरक्षित क्रम यह है: पहले तय करें कि समस्या कॉन्टेक्स्ट क्षमता की है या अकाउंट कोटा की, फिर कोड और टास्क की स्थिति सुरक्षित करें, सही कंप्रेशन चुनें, परिणाम की जाँच करें और उसके बाद ही auto-compact threshold तथा model window की सेटिंग सुधारें।
नीचे दिए गए कमांड और सेटिंग 11 अक्टूबर 2026 को खोले गए Qwen Code के कमांड दस्तावेज़, सेटिंग संदर्भ और Model Providers संदर्भ पर आधारित हैं। आपके इंस्टॉल किए गए संस्करण में अंतर हो सकता है, इसलिए पहले उसी को जाँचें।
पहले पहचानें: कॉन्टेक्स्ट भरा है या कोटा खत्म हुआ है
| लक्षण | संभावित कारण | अगला कदम |
|---|---|---|
/context अधिक उपयोग दिखाता है या अनुरोध बहुत लंबा बताया जाता है | मौजूदा सेशन का कॉन्टेक्स्ट विंडो | स्थिति सुरक्षित करके कंप्रेस करें |
| provider balance, plan, quota, rate या account limit बताता है | सेवा या API का कोटा | provider console देखें; कंप्रेशन कोटा नहीं बढ़ाता |
/context का कुल विंडो वास्तविक सीमा से बहुत अलग है | Qwen Code गलत विंडो मान रहा है | contextWindowSize का मान और स्थान सुधारें |
| कंप्रेशन के बाद उपयोग घटता है, पर quota error रहता है | यह कॉन्टेक्स्ट समस्या नहीं है | key, balance, plan और rate limit जाँचें |
contextWindowSize केवल यह बताता है कि Qwen Code अपने अनुमान और compact trigger के लिए कितनी विंडो माने। यह मॉडल या API server की वास्तविक सीमा नहीं बढ़ाता और subscription या balance वापस नहीं देता।
इंस्टॉल किया गया संस्करण और मौजूदा उपयोग जाँचें
चलाएँ:
/status
/help
/model
/doctor
/context detail
हर कमांड के पूरा होने और prompt लौटने तक प्रतीक्षा करें। Version के लिए /status, मौजूदा model selection के लिए /model, authentication और environment checks के लिए /doctor, तथा context breakdown के लिए /context detail उपयोग करें।
यदि आपके build में /summary, /compress-fast या नीचे की कोई सेटिंग नहीं है, तो पहले आधिकारिक installation instructions देखें। जिस key को आपका संस्करण जानता ही नहीं, उसे बार-बार बदलने से वह लागू नहीं होगी।
कंप्रेशन से पहले दो तरह की स्थिति सुरक्षित करें
कंप्रेशन conversation history बदलता है। यह uncommitted code को अपने-आप सुरक्षित नहीं करता और generated summary हर implicit constraint को बचाए रखे, इसकी गारंटी भी नहीं है।
कोड की स्थिति सुरक्षित करें
Git project में चलाएँ:
!git status --short
!git diff --stat
ज़रूरत हो तो पूरा diff देखें या ऐसा checkpoint commit बनाएँ जिसे रखना स्वीकार्य हो। आपको पता होना चाहिए कि कौन-सी files बदली हैं, कौन-सी untracked हैं और कौन-से tests अभी नहीं चले।
टास्क की स्थिति सुरक्षित करें
आगे कोई file बदले बिना स्पष्ट handoff माँगें:
फाइलें बदले बिना वर्तमान टास्क का checkpoint लिखें:
- अंतिम लक्ष्य
- पूरा किया गया काम
- बदली हुई फाइलें और मुख्य बदलाव
- वे constraints जिन्हें नहीं बदलना है
- चलाए गए verification और उनके परिणाम
- अनसुलझी समस्याएँ
- अगला एकमात्र कदम और उसका verification command
इसे पढ़कर जाँचें, फिर चलाएँ:
/summary
Custom path न देने पर documented file यह है:
.qwen/PROJECT_SUMMARY.md
/summary non-destructive है: यह वर्तमान chat history को replace किए बिना project summary लिखता है। File को दोबारा inject करके read-only audit करें:
@.qwen/PROJECT_SUMMARY.md लक्ष्य, constraints, बदली फाइलें, verification results और अगले कदम की जाँच करें। केवल कमी बताएँ; code न बदलें।
यदि आप welcome-back flow पर निर्भर हैं तो default path रखें। आधिकारिक दस्तावेज़ के अनुसार custom path की summary उस flow को अपने-आप नहीं मिलती।
/compress, /compress-fast, /summary और /clear में क्या चुनें
| कमांड | क्या करता है | कब चुनें | मुख्य जोखिम |
|---|---|---|---|
/summary | History बदले बिना project state file में लिखता है | असली compression, pause या नई session से पहले | Summary की manual review ज़रूरी है |
/compress | Chat history को summary से replace करता है | बहुत से decisions, constraints और dependencies वाले task | पुरानी history के लिए destructive; details छूट सकती हैं |
/compress-fast | AI के बिना पुराने tool outputs और thinking content हटाता है | Logs/tool output बहुत बड़े हों और goal पहले से साफ हो | हटाए गए पुराने tool outputs में बाद में जरूरी जानकारी हो सकती है; उसे पहले checkpoint में लिखकर जाँचें |
/clear | Conversation history साफ करता है | जब external checkpoint से जानबूझकर दोबारा शुरू करना हो | पुराना context खो जाता है |
अधिकांश complex coding tasks के लिए क्रम रखें: /summary → manual review → /compress। Normal compression पूरा न हो, provider call अस्थायी रूप से उपलब्ध न हो, या पुराने tool outputs अधिक जगह ले रहे हों तो सुरक्षित checkpoint के बाद /compress-fast चुनें।
/summarize को file-saving command न समझें। Current documentation में यह /compress का alias है और history को replace करता है।
पूरी, जाँचने योग्य compression प्रक्रिया
1. Input तैयार करें
Compression से पहले यह सब सुरक्षित होना चाहिए:
- वर्तमान goal और non-negotiable constraints;
- बदली files और Git state;
- completed तथा pending verification;
- अगला कदम और उसकी success condition;
- reviewed
.qwen/PROJECT_SUMMARY.md।
2. Compression चलाएँ
Complex task के लिए:
/compress
Tool-output-heavy session और अच्छे checkpoint के लिए:
/compress-fast
Operation पूरा होने और prompt लौटने तक प्रतीक्षा करें। Compression चलते समय नया code-editing instruction न भेजें।
3. Output सुरक्षित रखें
दो independent outputs रखें:
.qwen/PROJECT_SUMMARY.md, जिसमें task checkpoint है;- working tree और Git diff, जिनमें वास्तविक code changes हैं।
Compressed chat को अकेला source of truth न बनाएँ। Files, tests और diff बताते हैं कि वास्तव में क्या बदला।
4. सफलता जाँचें
फिर चलाएँ:
/context
Context usage स्पष्ट रूप से कम होना चाहिए। इसके बाद बिना file edit की अनुमति दिए continuity check करें:
अभी फाइलें न बदलें। जवाब दें:
1. वर्तमान एकमात्र लक्ष्य क्या है?
2. कौन-से constraints नहीं बदलने हैं?
3. कौन-सी files बदली गई हैं?
4. कौन-से checks पास हुए और कौन-से अभी नहीं चले?
5. अगला एकमात्र कदम और उसका success signal क्या है?
उत्तर को PROJECT_SUMMARY.md, git status और वास्तविक test record से मिलाएँ। तीनों समान होने पर केवल एक छोटा अगला कदम करें और सबसे संबंधित verification चलाएँ।
5. Failure में task न खोएँ
- Checkpoint सुरक्षित होने के बाद
/compressfail हो तो/compress-fastआज़माएँ; वह भी fail हो तो नई session खोलकर@.qwen/PROJECT_SUMMARY.mdinject करें। - Compression के बाद constraint गायब हो तो summary दोबारा inject करें, कमी सुधारें और edits से पहले checkpoint फिर से कहलवाएँ।
- Context घटने के बाद भी request fail हो तो देखें error balance, plan, rate limit या authentication से जुड़ा है या नहीं।
- Server अभी भी context overflow दे तो
contextWindowSizeprovider की effective limit से बड़ा हो सकता है।
Auto-compact threshold सुधारें: पुरानी key अब लागू नहीं होती
वर्तमान key यह है:
{
"context": {
"autoCompactThreshold": 0.85
}
}
मान 0 से बड़ा और 1 से अधिक नहीं होना चाहिए; default 0.85 है। यह ceiling है, यह वादा नहीं कि हर model ठीक 85% पर compact होगा। छोटी window में summary के लिए जगह बचाने हेतु Qwen Code पहले compact कर सकता है।
Replace होकर बिना warning के ignore होने वाला पूरा path model.chatCompression.contextPercentageThreshold है:
{
"model": {
"chatCompression": {
"contextPercentageThreshold": 0.7
}
}
}
Migration में value को context.autoCompactThreshold में ले जाएँ और पहले default behavior देखें। केवल तब कम करें जब compression बार-बार बहुत देर से शुरू होती दिखे; history लंबी रखने के लिए इसे बिना कारण न बढ़ाएँ।
User scope और project scope सोच-समझकर चुनें
~/.qwen/settings.json: वर्तमान user के सभी projects;- project root का
.qwen/settings.json: केवल वही project, और user settings पर प्राथमिकता।
Documented precedence है: defaults, system defaults, user settings, project settings, system settings, environment variables, command-line arguments। User file बदलने पर असर न दिखे तो ऊँची priority की layer जाँचें।
/config simple settings बदल सकता है:
/config context.autoCompactThreshold=0.85
लेकिन यह बदलाव ~/.qwen/settings.json में लिखता है। Repository-specific value के लिए .qwen/settings.json सीधे edit करें।
ज़रूरत हो तो JSON syntax जाँचें:
!python3 -m json.tool ~/.qwen/settings.json >/dev/null
!python3 -m json.tool .qwen/settings.json >/dev/null
contextWindowSize को उसी level पर रखें जो सच में लागू है
चुने गए model के लिए provider की effective limit लिखें, marketing maximum या मनचाहा अंक नहीं। बहुत बड़ा मान compression देर से कराता है; बहुत छोटा मान warning और compression जल्दी कराता है।
Model modelProviders से चुना गया है
Value उसी provider entry के भीतर होना चाहिए। नीचे 128000 केवल structure example है:
{
"modelProviders": {
"openai": [
{
"id": "your-model-id",
"name": "Your model",
"baseUrl": "https://provider.example/v1",
"envKey": "OPENAI_API_KEY",
"generationConfig": {
"contextWindowSize": 128000
}
}
]
},
"security": { "auth": { "selectedType": "openai" } },
"model": { "name": "your-model-id" }
}
Provider model entries sealed होती हैं: top-level model.generationConfig उनके missing fields नहीं भरता। यही placement rule किसी भी OpenAI-compatible custom endpoint पर लागू होता है—उदाहरण के लिए संभावित API service के रूप में BetterToken—लेकिन पहले client, resource और चुने model की support जाँचें।
Runtime model modelProviders से नहीं चुना गया
केवल तब top-level setting उपयोग करें:
{
"model": {
"generationConfig": {
"contextWindowSize": 128000
}
}
}
दोनों जगह अलग मान लिखकर अनुमान न लगाएँ। मौजूदा model को /model से और authentication को /doctor से जाँचें, model का source पहचानें और एक सही स्थान चुनें।
तेज़ troubleshooting क्रम
| लक्षण | संभावित कारण | सुधार और verification |
|---|---|---|
/compress-fast unknown है | पुराना version | /status, update, फिर /help से पुष्टि |
| पुराना threshold असर नहीं करता | Key ignore हो रही है | context.autoCompactThreshold पर migrate करें |
| User setting लागू नहीं होती | Project या system override | .qwen/settings.json, policy और launch arguments जाँचें |
| 0.85 से पहले compact होता है | Summary के लिए headroom चाहिए | /context में वास्तविक window और usage देखें |
/context बहुत बड़ी window दिखाता है | गलत value या level | Active provider के generationConfig में effective limit रखें |
| Server फिर भी overflow देता है | Config वास्तविक limit से बड़ा है | Effective value तक घटाकर फिर जाँचें |
| Compression के बाद quota error रहता है | Balance, plan या rate limit | Provider console जाँचें |
| Model अगला कदम नहीं बता पाता | Checkpoint अधूरा है | PROJECT_SUMMARY.md inject करके Git और tests से मिलाएँ |
याद रखने के चार नियम
- कॉन्टेक्स्ट और कोटा अलग हैं। Compression history घटाता है, account limit नहीं बढ़ाता।
- Compression से पहले save करें। Git code state बचाता है और
/summarytask state। - Complex continuity के लिए
/compress, tool output के बोझ के लिए/compress-fast। दोनों के बाद verification करें। - Setting effective level पर रखें।
context.autoCompactThresholdउपयोग करें और provider model काcontextWindowSizeउसकीmodelProvidersentry में रखें।
मौजूदा session में /status, /model, /doctor, /context detail और /summary से शुरू करें। Compression चुनने से पहले checkpoint file पढ़ें। Summary पूर्ण न भी हो, तो traceable code और task state से काम पुनः शुरू किया जा सकता है।