Qwen Code की लंबी सेशन जारी रखें: कंप्रेशन और कॉन्टेक्स्ट सेटिंग

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

विषय-सूची
Qwen Code की लंबी सेशन जारी रखें: कंप्रेशन और कॉन्टेक्स्ट सेटिंग

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 में क्या चुनें

कमांडक्या करता हैकब चुनेंमुख्य जोखिम
/summaryHistory बदले बिना project state file में लिखता हैअसली compression, pause या नई session से पहलेSummary की manual review ज़रूरी है
/compressChat history को summary से replace करता हैबहुत से decisions, constraints और dependencies वाले taskपुरानी history के लिए destructive; details छूट सकती हैं
/compress-fastAI के बिना पुराने tool outputs और thinking content हटाता हैLogs/tool output बहुत बड़े हों और goal पहले से साफ होहटाए गए पुराने tool outputs में बाद में जरूरी जानकारी हो सकती है; उसे पहले checkpoint में लिखकर जाँचें
/clearConversation 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 रखें:

  1. .qwen/PROJECT_SUMMARY.md, जिसमें task checkpoint है;
  2. 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 सुरक्षित होने के बाद /compress fail हो तो /compress-fast आज़माएँ; वह भी fail हो तो नई session खोलकर @.qwen/PROJECT_SUMMARY.md inject करें।
  • Compression के बाद constraint गायब हो तो summary दोबारा inject करें, कमी सुधारें और edits से पहले checkpoint फिर से कहलवाएँ।
  • Context घटने के बाद भी request fail हो तो देखें error balance, plan, rate limit या authentication से जुड़ा है या नहीं।
  • Server अभी भी context overflow दे तो contextWindowSize provider की 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 या levelActive provider के generationConfig में effective limit रखें
Server फिर भी overflow देता हैConfig वास्तविक limit से बड़ा हैEffective value तक घटाकर फिर जाँचें
Compression के बाद quota error रहता हैBalance, plan या rate limitProvider console जाँचें
Model अगला कदम नहीं बता पाताCheckpoint अधूरा हैPROJECT_SUMMARY.md inject करके Git और tests से मिलाएँ

याद रखने के चार नियम

  1. कॉन्टेक्स्ट और कोटा अलग हैं। Compression history घटाता है, account limit नहीं बढ़ाता।
  2. Compression से पहले save करें। Git code state बचाता है और /summary task state।
  3. Complex continuity के लिए /compress, tool output के बोझ के लिए /compress-fast। दोनों के बाद verification करें।
  4. Setting effective level पर रखें। context.autoCompactThreshold उपयोग करें और provider model का contextWindowSize उसकी modelProviders entry में रखें।

मौजूदा session में /status, /model, /doctor, /context detail और /summary से शुरू करें। Compression चुनने से पहले checkpoint file पढ़ें। Summary पूर्ण न भी हो, तो traceable code और task state से काम पुनः शुरू किया जा सकता है।

अपना LLM वर्कफ़्लो बेहतर बनाना चाहते हैं?

एक API से मॉडल जोड़ें, कुंजियाँ प्रबंधित करें और AI खर्च नियंत्रित करें।

मुफ़्त शुरू करें