Claude Code: /compact कब चलाएँ और नया सेशन कब शुरू करें

Claude Code में /compact पुरानी बातचीत को छोटे, संरचित सार में बदलता है। इससे active context window में जगह खाली होती है, जबकि task का लक्ष्य, महत्वपूर्ण फैसले और project की मौजूदा स्थिति बचाए रखने की कोशिश की जाती है। यह तब सबसे उपयोगी है जब task वही है और दिशा सही है, लेकिन लंबे logs, tool output, diffs और बीच की चर्चा ने सेशन को भारी बना दिया है।

फिर भी /compact किसी उलझे हुए सेशन को जादुई रूप से ठीक नहीं करता। Compaction के बाद active context में हर पुरानी बात शब्दशः मौजूद नहीं रहती। Exact error message, पहले खारिज किया गया तरीका, अस्थायी सीमा या केवल chat में कही गई instruction कम प्रमुख हो सकती है। Claude यदि tasks मिला रहा है, असफल समाधान दोहरा रहा है या गलत architecture assumption पर काम कर रहा है, तो छोटा handoff तैयार करके साफ नया सेशन शुरू करना अधिक सुरक्षित है।

Claude Code और Claude Web में /compact क्या करता है?

Claude Code में /compact पुरानी multi-turn बातचीत का सार बनाकर context space खाली करता है; इस command से project files अपने-आप नहीं बदलतीं। Context limit के पास पहुँचने पर Claude Code automatic compaction भी कर सकता है, और आप session धीमा या noisy होने से पहले इसे manually चला सकते हैं।

सामान्य Claude Web chat में /compact नाम की user command नहीं होती। Code execution enabled होने पर लंबी बातचीत context limit के करीब पहुँचती है, तो Claude पुराने messages का automatic summary बनाकर chat जारी रख सकता है। कभी-कभी interface में Claude के “organizing its thoughts” जैसा status दिखाई देता है। Full chat history बनी रहती है, लेकिन model के active working context में पूरी transcript की जगह summary इस्तेमाल होती है।

सवाल	Claude Code	Claude Web
Compaction कैसे शुरू होता है	/compact से manually या automatic	Limit के पास automatic context management
क्या user वही command चला सकता है	हाँ	नहीं, वैसी chat command नहीं है
क्या वही बातचीत जारी रहती है	हाँ, वही session	हाँ, वही chat
मुख्य उद्देश्य	उसी development task के लिए context खाली करना	लंबी chat को length interruption के बिना आगे बढ़ाना
मुख्य जोखिम	Exact errors और chat-only constraints summary में कमजोर हो सकते हैं	पुराने details active context में कम prominent हो सकते हैं

/compact, /clear, /rewind या नया सेशन: किसे चुनें?

विकल्प	क्या बदलता है	कब उपयोग करें	कब न करें
Continue	कुछ reset या summarize नहीं होता	Claude symptom, constraints और latest evidence ठीक से याद रखता है	Session loop कर रहा हो, tasks मिला रहा हो या rejected idea दोहरा रहा हो
/compact	पुराने turns summarize होते हैं, context खाली होता है, वही session रहता है	Task वही है, दिशा सही है, लेकिन logs और tool output बहुत हैं	मूल समझ गलत है या पुराने exact details जरूरी हैं
/clear	मौजूदा Claude Code process में blank conversation शुरू होती है; पुराना session /resume से मिल सकता है	उसी working directory और files के साथ साफ chat चाहिए	Code changes undo करने हैं; /clear files restore नहीं करता
/rewind	Checkpoint menu से code, conversation या चुने हिस्से का summary restore किया जा सकता है	हाल के turns गलत दिशा में गए और सही checkpoint पता है	Changes Bash, external tool, manual edit या अधिकतर subagents से हुए हों
अलग नया सेशन	दूसरे terminal, window या isolated workspace में clean context	Task बदल रहा हो, architecture दोबारा सोचना हो या parallel work हो	केवल logs ज्यादा हों, जबकि session अभी सही समझ रहा हो

/clear अपने-आप एक नई blank conversation शुरू करता है। यहाँ “अलग नया सेशन” का मतलब अधिक स्पष्ट सीमा है: नया terminal या window, जरूरत हो तो अलग branch या worktree, और केवल verified facts वाला handoff।

पहले तय करें: समस्या context की है या diagnosis की?

मान लें CSV import में खाली amount आने पर validation error लौटना चाहिए और data लिखना नहीं चाहिए। Claude handler दो बार बदल चुका है, वही files फिर से खोल चुका है और अब पहली implementation फिर सुझा रहा है।

तुरंत /compact या restart न करें। पहले सबसे छोटा test चलाएँ:

npm test -- tests/import/empty-amount.test.ts

अब result को इस तरह पढ़ें:

• Test मौजूद नहीं है या गलत behavior जाँचता है: पहली समस्या specification या reproduction की है। नया session evidence नहीं बनाएगा।
• Test सही symptom को लगातार reproduce करता है और Claude result का सही उपयोग कर रहा है: current session जारी रखें।
• Test लगातार fail होता है, लेकिन Claude excluded causes भूल रहा है, scope बढ़ा रहा है या पुराने ideas दोहरा रहा है: context degradation संभव है।

कोई official token count या message count यह तय नहीं करता कि compaction कब करना है। 60%–80% context usage को early warning मान सकते हैं, hard rule नहीं। बेहतर संकेत behavior है: क्या Claude लक्ष्य, constraints, verified facts और अगली validation command सही बता पा रहा है?

/compact कब चलाना चाहिए?

इन सभी शर्तों के पूरा होने पर /compact बेहतर विकल्प है:

1. आप उसी task और repository पर काम कर रहे हैं।
2. Claude goal और allowed files सही समझता है।
3. Current direction test या log से supported है, केवल अनुमान नहीं।
4. Context का बड़ा हिस्सा लंबे logs, build output, repeated diffs या बीच की चर्चा ने घेर लिया है।
5. जरूरी facts कुछ वाक्यों में लिखे जा सकते हैं।

Compaction से पहले working tree देखें:

git status --short
git diff

फिर /context चलाकर देखें कि context messages, tools, MCP definitions या CLAUDE.md में कहाँ खर्च हो रहा है। यदि एक बहुत बड़ा पहला prompt, attachments, tool definitions या oversized memory file असली कारण है, तो /compact के पास summarize करने के लिए पर्याप्त पुराने turns नहीं होंगे।

Project root का CLAUDE.md /compact के बाद फिर load होता है। केवल conversation में कही गई instructions उतनी durable नहीं होतीं। Long-term project rules छोटे CLAUDE.md में रखें और task-specific facts compaction से पहले और बाद में साफ दोहराएँ।

Compaction के तुरंत बाद context verify करें

/compact के बाद Claude को तुरंत files edit न करने दें। पहले यह localized verification prompt भेजें:

हमने अभी context compact किया है। कोई file बदलने से पहले चार सवालों के जवाब दो:
1. हम किस exact symptom को ठीक कर रहे हैं और expected result क्या है?
2. कौन-सा approach पहले test करके reject किया जा चुका है, और क्यों?
3. किन files को बदलने की अनुमति है और क्या बिल्कुल नहीं बदलना है?
4. Hypothesis जाँचने के लिए अगली केवल एक command कौन-सी चलाएँगे?

यदि किसी जवाब के लिए current context में पर्याप्त जानकारी नहीं है, तो अनुमान लगाने के बजाय बताओ कि क्या missing है।

Example task में Claude को कम से कम यह बताना चाहिए:

• खाली amount validation error दे और data न लिखे;
• Number(value || 0) reject किया गया क्योंकि वह खाली value को valid zero बना देता है;
• Scope parser और focused test तक सीमित है;
• अगला कदम narrow test या tracing command है, पूरे import system का refactor नहीं।

Answers सही हों तो उसी session में आगे बढ़ें। Answers vague हों, rejected solution वापस आए या README और public CSV format scope में जुड़ जाएँ, तो summary पर भरोसा न करें। Handoff तैयार करके /clear या अलग नया session इस्तेमाल करें।

कब /compact सही tool नहीं है?

1. Task बदल चुका है

पहले validation bug था, फिर README update, deployment change और दूसरा API issue जोड़ दिया गया। Compaction इन सबका एक summary बनाएगा; clean boundaries नहीं बनाएगा। दूसरे task को नए session में ले जाएँ।

2. Claude की मूल assumption गलत है

Claude खाली value को बार-बार zero मान रहा है या data-write path गलत समझ रहा है, तो समस्या केवल लंबी transcript नहीं है। Verified facts से शुरू किया साफ session अक्सर तेज होता है।

3. Exact details शब्दशः चाहिए

कुछ error lines, SQL, stack locations, protocol fields और security constraints summary पर नहीं छोड़े जा सकते। Minimum जरूरी fragment handoff note या local file में रखें।

4. एक input ही बहुत बड़ा है

पहले prompt में huge log, attachments या बहुत से tool definitions हों, तो compact करने के लिए पुरानी multi-turn conversation नहीं होगी। Input छोटा करें, file paths दें या unused MCP servers disable करें।

5. Summary बनाने की जगह भी नहीं बची

Context पूरी तरह भरने पर /compact खुद fail हो सकता है। Esc दो बार दबाकर कुछ turns पीछे जाएँ और फिर कोशिश करें। फिर भी काम न हो तो /clear चलाएँ; पुराना session /resume से उपलब्ध रहेगा।

/rewind कब /compact से बेहतर है?

जब समस्या केवल हाल के turns में हो, तो /rewind अधिक precise है। Empty prompt पर /rewind चलाएँ या Esc दो बार दबाएँ। Checkpoint menu से आप:

• code और conversation दोनों restore कर सकते हैं;
• conversation restore करके current files रख सकते हैं;
• code restore करके conversation रख सकते हैं;
• चुने point से आगे की history summarize कर सकते हैं;
• चुने point से पहले की history summarize कर सकते हैं।

यह तब उपयोगी है जब पिछले तीन turns गलत दिशा में गए हों, लेकिन उससे पहले का context सही हो।

Checkpoint मुख्यतः Claude के file-editing tools से हुए changes track करता है। Bash commands, external programs, manual edits या अधिकतर subagents के changes restore न भी हों। यह Git का replacement नहीं है; महत्वपूर्ण points पर branch, commit या कम-से-कम git diff जरूरी है।

Task को नए session में सुरक्षित तरीके से कैसे दें?

नए session को पूरी transcript नहीं चाहिए। उसे verified facts, current file state और एक स्पष्ट next step चाहिए।

पहले देखें:

git status --short
git diff

फिर यह handoff भेजें:

लक्ष्य: खाली amount validation error लौटाए और data न लिखे।
Working tree: पहले git status और git diff जाँचो; इसे clean मानकर मत चलो।
Target files: parser/amount.ts, tests/import/empty-amount.test.ts
Reproduction: npm test -- tests/import/empty-amount.test.ts
Current result: test fail हो रहा है।
Rejected approach: Number(value || 0), क्योंकि यह खाली value को zero में बदल देता है।
Constraints: public CSV format न बदलो और unrelated modules refactor न करो।
Open question: खाली value और legitimate 0 को किस layer पर अलग किया जाए?
Next step: CSV parser से validation branch तक value trace करो और केवल एक testable hypothesis दो।

Editing से पहले goal, constraints, rejected approach और अगली validation command दोहराओ।

API Key, Cookie, .env content, personal data या पूरा raw log handoff में न डालें। Error line जरूरी हो तो minimum fragment और local log का path दें।

एक मिनट का decision flow

1. पहले reproduce करें। सबसे छोटा test या command चलाएँ जो symptom सिद्ध करे।
2. क्या session अभी accurate है? Claude goal, constraints और latest result याद रखता है तो continue करें।
3. क्या मुख्य समस्या noise है? वही task, सही direction और बहुत logs हों तो /compact करें।
4. क्या केवल recent turns गलत हैं? Targeted restore या summary के लिए /rewind करें।
5. क्या task बदल गया या understanding degrade हुई? Handoff के साथ /clear या अलग नया session लें।
6. Edit से पहले verify करें। Claude से facts दोहरवाएँ, फिर changes की अनुमति दें।

अक्सर पूछे जाने वाले सवाल

Claude Code में /compact वास्तव में क्या करता है?

यह पुरानी multi-turn conversation को छोटे context representation में summarize करता है, ताकि उसी session के लिए जगह खाली हो। Command अपने-आप project files नहीं बदलता।

क्या /compact पुरानी chat या code delete करता है?

इसका उद्देश्य active context compact करना है, code delete करना नहीं। Session transcript बनी रहती है, लेकिन आगे के turns summary और current active content पर अधिक निर्भर करते हैं; critical details अलग से verify करें।

/compact कब करें और नया session कब शुरू करें?

Task और direction सही हों, केवल logs और intermediate output ज्यादा हों, तो /compact करें। Tasks mixed हों, rejected ideas लौटें, key constraints खो जाएँ या architecture गलत समझा गया हो, तो clean session शुरू करें।

Claude Web में Compact क्या है?

लंबी chat context limit के पास पहुँचने पर Claude Web पुराने messages का automatic summary बना सकता है। यह Claude Code की /compact command नहीं है और आम तौर पर manually trigger नहीं करनी पड़ती। Automatic context management के लिए code execution enabled होना चाहिए।

/clear और नया terminal खोलने में क्या अंतर है?

/clear current Claude Code process में blank conversation शुरू करता है और पुराना session /resume से मिल सकता है। नया terminal या window task isolation, parallel work और अलग branch या worktree के लिए बेहतर है।

आधिकारिक संदर्भ

• Claude Code interactive mode और /clear
• Claude Code checkpoints और /rewind
• Context-limit errors और /compact
• Compaction के बाद CLAUDE.md का व्यवहार
• Claude Web usage, length limits और automatic context management