Claude AI गाइड: टिप्स और बेस्ट प्रैक्टिस

Claude के सोचने के तरीक़े में पीढ़ीगत बदलाव आ चुका है। पुरानी extended thinking में हर request पर token बजट आपको ख़ुद बताना पड़ता था — thinking: {"type": "enabled", "budget_tokens": N} — लेकिन सही बजट हर टास्क के लिए अलग होता है, पहले से भाँपा नहीं जा सकता, और उसे बदलने से prompt cache invalidate हो जाता है। मौजूदा adaptive thinking बस एक लाइन है, type: "adaptive": सोचना है या नहीं और कितनी गहराई से, यह मॉडल का अपना फ़ैसला है — इस आधार पर कि request कितनी मुश्किल दिखती है। माइग्रेशन चरणों में हुआ: budget_tokens को Opus 4.6 / Sonnet 4.6 पर deprecated किया गया और Opus 4.7 से आगे 400 error के साथ ठुकराया जाता है। यह लेख हर मॉडल के नियम एक टेबल में समेटता है — Fable 5 हमेशा सोचता है (बंद नहीं हो सकता), Opus 5 और Sonnet 5 पर thinking डिफ़ॉल्ट रूप से चालू है (Opus 5 पर बंद करना सिर्फ़ effort high या उससे नीचे पर संभव), Opus 4.8 / 4.7 पर explicit adaptive सेट करना पड़ता है, और Sonnet 4.5 / Haiku 4.5 जैसे legacy मॉडल आज भी budget_tokens को ही एकमात्र mode के रूप में इस्तेमाल करते हैं। गहराई का नियंत्रण अब output_config: {"effort": ...} के पाँच स्तरों (डिफ़ॉल्ट high) में है, और effort बदलने से cache वैसे ही टूटता है जैसे पहले बजट बदलने से टूटता था। दिखना display से तय होता है: नई पीढ़ी का डिफ़ॉल्ट "omitted" है (ख़ाली thinking blocks), और बिल दोनों सूरतों में पूरे thinking tokens का लगता है — मापिए usage.output_tokens_details.thinking_tokens से; कच्ची chain of thought कोई setting नहीं लौटाती। Opus 5 पर thinking बंद करने के दर्ज side effects हैं (tool calls सादे text में, आंतरिक tags का leak), इसलिए लागत घटाने का सुरक्षित रास्ता effort घटाना है। tool calls के बीच reasoning — interleaved thinking — adaptive में अपने आप होती है, पुराना beta header अब नहीं चाहिए। और रफ़्तार चाहिए तो fast mode वही Opus क़रीब 2.5x तेज़ चलाता है, दोगुनी क़ीमत पर (सिर्फ़ Opus 5/4.8, Claude Code में /fast से toggle)। हर बात Anthropic के आधिकारिक Thinking, Extended thinking और Fast mode documentation पर आधारित है।

काम के बीच Claude Desktop अचानक जम जाती है और खुले हुए सारे Claude Code सेशन ठीक उसी पल रुक जाते हैं; ज़बरदस्ती बंद कीजिए तो कभी-कभी ऐप दोबारा चालू ही नहीं होती। ऐसे मौक़ों पर %APPDATA%\Claude\logs\main.log की आख़िरी पंक्ति लगभग हमेशा एक ही होती है — GPU process gone, exitCode 101457950 (0x060C201E) के साथ। यह लेख बताता है कि वह कोड है क्या, एक-दूसरे से कोई नाता न रखने वाले सेशन भी साथ में क्यों चले जाते हैं, और कौन-से उपाय सचमुच काम के हैं। पहला क़दम अलगाव है: क्रैश Claude Code (CLI) नहीं हुआ, बल्कि उसे ढोने वाले Electron डेस्कटॉप ऐप की GPU प्रोसेस हुई है। दूसरा क़दम यह समझना है कि नुक़सान इतनी दूर तक फैलता क्यों है। Chromium सारी रेंडरिंग एक ही GPU प्रोसेस में समेट देता है, और हर ऐप्लिकेशन में उसकी सिर्फ़ एक होती है, जिसे हर विंडो, हर टैब और हर सेशन साझा करते हैं; इसलिए in-app ब्राउज़र में खुला एक भारी पन्ना आठ असंबंधित सेशन को उसी पल गिरा सकता है, और यूज़र की तरफ़ की कोई सेटिंग उन्हें अलग नहीं करती। फिर ट्रिगर की बात आती है। सार्वजनिक issues में in-app ब्राउज़र सबसे आगे है — #80444 दर्ज करता है कि पन्ने की WebGL/WebGPU फ़ीचर डिटेक्शन के 15 से 36 सेकंड बाद प्रोसेस मरी, चारों बार वही exit code; #82967 ट्रिगर को ब्राउज़र टूल के प्रीव्यू स्क्रीनशॉट लेने पर टिकाता है; #83478 लगातार अपडेट होते प्रीव्यू को खुला छोड़ने पर इसे दोहराता है। पर ब्राउज़र अकेला ट्रिगर नहीं है: #68049 ARM64 पर चालू होते समय, बिना किसी ब्राउज़र छेड़छाड़ के, वही कोड रिपोर्ट करता है, और #83028 इसे Intel के इंटीग्रेटेड GPU पर दोहराता है। इसके बाद निदान ठोस रूप लेता है — तीन फ़ाइलें (main.log, unknown-window.log में उसी समय का CONTEXT_LOST_WEBGL, और Crashpad फ़ोल्डर), साथ में एक तालिका जो 101457950 को उन exit codes से अलग करती है जिनका मतलब सामान्य समाप्ति है, और यह चेतावनी कि उसी लॉग में दिखने वाली requestAdapter / powerPreference वाली पंक्ति Chromium का सामान्य संदेश है, क्रैश का संकेत नहीं। वापसी वाले हिस्से में Repair है, उस हालत के लिए जब Windows पैकेज को Modified मानकर उसे चलाने से इनकार कर दे; साथ में वह रिपोर्ट भी, जिसमें हालत Modified, NeedsRemediation तक पहुँच गई और ऐप सिर्फ़ पूरी तरह हटाकर दोबारा इंस्टॉल करने पर लौटी। सहेजे हुए ट्रांसक्रिप्ट बचे रहते हैं, पर जो काम उसी वक़्त चल रहा था वह नहीं (#81698 में समांतर चल रहे सबएजेंट के नतीजे चले गए)। अंत में यह कि क्या काम करता है और क्या नहीं — MSIX वाले बिल्ड पर --disable-gpu मना कर दिया जाता है, ऐप अपडेट करने से यहाँ यह नहीं रुका, GPU प्रोसेस को अलग करना ढाँचे के कारण संभव ही नहीं — हाइब्रिड GPU तय कर देने वाली सलाह और यह बात कि इस लक्षण में उससे फ़ायदा हुआ हो ऐसी कोई रिपोर्ट नहीं मिली, तथा Store के अपडेट से हुए ज़बरदस्ती बंद होने को असली क्रैश से कैसे अलग पहचानें।

Dispatch वह फ़ीचर है जिसमें आप अपने फ़ोन से निर्देश भेजते हैं और Claude वह काम आपके अपने कंप्यूटर पर करता है (बीटा, Pro और Max)। यह क्लाउड में नहीं चलता; आपकी असली मशीन चलती है, और इसी एक तथ्य से इसका फ़ायदा भी निकलता है और इसका ख़तरा भी। आधिकारिक हेल्प कहती है कि आप अपने फ़ोन से Claude को संदेश भेजकर उससे अपने डेस्कटॉप कंप्यूटर पर काम करवा सकते हैं, और वह इसके लिए वही connector, plugin और फ़ाइल-एक्सेस इस्तेमाल करता है जो आपने Cowork में पहले से सेट कर रखे हैं — Anthropic इसे एक लगातार चलती बातचीत बताता है जिस तक दोनों डिवाइस से पहुँचा जा सकता है। इसे चलाने के लिए PC का जगा होना और डेस्कटॉप ऐप का खुला होना ज़रूरी है, और कंप्यूटर उपयोग सिर्फ़ macOS तथा Windows पर समर्थित है, Linux पर कंप्यूटर उपयोग है ही नहीं। मशीनरी के लिहाज़ से यह प्राथमिकता की तीन सीढ़ियाँ उतरता है: connector अगर मौजूद हो, न हो तो ब्राउज़र चलाना, और आखिरी उपाय के तौर पर स्क्रीन से सीधा व्यवहार — बीच-बीच में वह स्क्रीन समझने के लिए स्क्रीनशॉट भी लेता है। असली आकलन इसके बाद शुरू होता है। जहाँ यह रुकता है, वे जगहें डिज़ाइन में रखी गई हैं: कंप्यूटर उपयोग डिफ़ॉल्ट रूप से बंद है और Settings, General के नीचे चालू होता है; हर नए ऐप के लिए अलग से permission माँगी जाती है; किसी फ़ाइल को स्थायी रूप से मिटाने के लिए साफ़ permission चाहिए; और निवेश तथा ट्रेडिंग प्लेटफ़ॉर्म एवं क्रिप्टोकरेंसी ऐप डिफ़ॉल्ट रूप से दायरे से बाहर हैं। पर कुछ जगहें ऐसी भी हैं जहाँ यह नहीं रुकता। पहले से मंज़ूर किए ऐप के भीतर की अलग-अलग कार्रवाइयों की पुष्टि आपसे नहीं ली जाती, और आधिकारिक शब्द यही हैं कि Claude आपकी स्क्रीन पर सीधे क्लिक करता है, टाइप करता है और नेविगेट करता है, उन permission जाँचों के बिना जो बाकी Cowork tool पर लगती हैं। दस्तावेज़ यह भी जोड़ते हैं कि Claude और आपकी स्क्रीन पर मौजूद चीज़ों के बीच कोई sandbox नहीं है, और एक ऐप में की गई कार्रवाइयाँ दूसरे ऐप पर असर डाल सकती हैं। सबसे बड़ा जोखिम prompt injection है, जिसे Anthropic अपने शब्दों में यूँ रखता है: वेब का कंटेंट prompt injection हमलों का एक प्रमुख रास्ता है, और कोई तोड़-मरोड़कर डाला गया निर्देश, कोई अप्रत्याशित कमांड, या आपके ब्राउज़र में खुला कोई फ़िशिंग लिंक ऐसी कार्रवाइयों की शृंखला में बदल सकता है जिन्हें पलटना मुश्किल या असंभव हो। Anthropic कहता है कि वह ऐसा व्यवहार पकड़ने के लिए मॉडल की भीतरी activations स्कैन करता है, पर इससे संभावना घटती है, आपकी अपनी रेखा खींचने की ज़रूरत खत्म नहीं होती, और मार्गदर्शन अब भी यही कहता है कि जब कोई काम संवेदनशील फ़ाइलों, खातों या साइटों को छूता हो तो मैनुअल मंज़ूरी पर चले जाइए। Anthropic सीमा नाम लेकर बताता है: संवेदनशील ऐप, जैसे बैंकिंग, स्वास्थ्य-सेवा और सरकारी, को कंप्यूटर उपयोग की permission मत दीजिए, और वित्तीय खातों, कानूनी दस्तावेज़ों, चिकित्सा जानकारी तथा निजी डेटा से बचिए। लेख फ़ोन वाली तरफ़ को भी उठाता है। हैंडसेट खोने पर जो रिसता है वह उसमें रखा डेटा नहीं, बल्कि आपके PC को आदेश देने की हैसियत है, और साथ में लगातार चलती बातचीत का सामान — और Dispatch की आधिकारिक हेल्प अनपेयर करने या खोए डिवाइस से निपटने का कोई ब्योरा नहीं देती, इसलिए उपाय खाते की तरफ़ से आते हैं: Settings, Account, Active sessions में जाकर उस एक session को खत्म करना, claude.ai से हर session का लॉगआउट करना (जो मोबाइल ऐप में उपलब्ध नहीं है और इसलिए वेब ब्राउज़र माँगता है), या फिर बस PC वाली तरफ़ काट देना, यानी डेस्कटॉप ऐप बंद कर देना या मशीन को स्लीप में जाने देना — दरअसल यही सबसे तेज़ है, क्योंकि Dispatch को PC का जगा होना और ऐप का खुला होना चाहिए। आखिर में लेख Dispatch और कंप्यूटर उपयोग को दो अलग स्विच के रूप में अलग करता है, दोनों को Claude Code के agent view से भी अलग करता है (जिसकी क्रिया को आधिकारिक दस्तावेज़ dispatch कहते हैं), और एक व्यावहारिक रेखा खींचता है: शुरुआत उस काम से कीजिए जिसे वापस लिया जा सके।

Claude Code का agent view, जो claude agents से खुलता है, वह फ़ीचर है जिससे आप एक के बाद एक स्वतंत्र बैकग्राउंड session शुरू करते हैं और उन सबको एक ही स्क्रीन से सँभालते हैं। आधिकारिक दस्तावेज़ वहाँ की जाने वाली क्रिया को dispatch कहते हैं, और यह नाम डेस्कटॉप ऐप के उसी नाम वाले बिलकुल अलग फ़ीचर से टकराता है, इसलिए पहला काम दोनों को अलग पहचानना है। दस्तावेज़ agent view को उस फ़ीचर की तरह बताते हैं जो एक ही स्क्रीन से बहुत सारे Claude Code session डिस्पैच करने और सँभालने देता है, और यह एक रिसर्च प्रीव्यू है जिसके लिए v2.1.139 या उससे नया बिल्ड चाहिए। यह लेख मशीनरी और सुरक्षा-मॉडल तक सीमित रहता है। पहला झटका यही लगता है कि इनपुट बॉक्स में टाइप किया गया हर prompt अपना नया session शुरू करता है: दूसरा टाइप कीजिए तो पहले के बगल में दूसरा session खड़ा हो जाएगा, न कि पहले में जुड़ा कोई अतिरिक्त निर्देश। आगे के निर्देश peek panel से जाते हैं, जो Space से खुलता है और पूरा ट्रांसक्रिप्ट नहीं, बल्कि ताज़ा आउटपुट या वह सवाल दिखाता है जिस पर session रुका है। सुरक्षा-मॉडल का दिल है worktree के ज़रिए अलगाव। कोई भी फ़ाइल बदलने से पहले बैकग्राउंड session .claude/worktrees/ के नीचे एक अलग-थलग git worktree में चला जाता है, इसलिए समानांतर session एक ही checkout पढ़ते हैं पर लिखता हर एक अपने में है — पढ़ना साझा, लिखना अलग। जो कुछ भी मुख्य checkout तक पहुँचता, वह तीन जाँचों से कट जाता है: Edit, Write और NotebookEdit के ज़रिए फ़ाइल-बदलाव; वे कमांड जिनकी वर्किंग डायरेक्टरी मुख्य checkout पर टिकती है या जिनके बारे में यह पक्का नहीं हो सकता कि वे बाहर ही रहेंगे; और git का रुख मोड़ने की कोशिशें, चाहे वे git -C, --git-dir, GIT_DIR, GIT_WORK_TREE से हों या git से पहले लगाए गए cd से। फ़ैसला जानबूझकर सुरक्षित पक्ष में लिया गया है, यानी जिसकी पुष्टि न हो सके वह चलता ही नहीं, और यही सुरक्षा session के खड़े किए हर सबएजेंट को विरासत में मिलती है। हालाँकि यह OS-स्तर की दीवार नहीं है: रिपॉज़िटरी के बाहर की फ़ाइलें और नेटवर्क दायरे से बाहर हैं, और PowerShell के कमांड पर सिर्फ़ वर्किंग-डायरेक्टरी वाली जाँच लगती है। permission भी डिस्पैच के वक़्त चुनी नहीं जाती; वह उस डायरेक्टरी के defaultMode से, या डिस्पैच किए गए सबएजेंट के frontmatter के permissionMode से विरासत में आती है, यानी आपका रोज़मर्रा का कॉन्फ़िगरेशन जितना ढीला होगा, एक साथ उतने ही ज़्यादा लावारिस और ढीली permission वाले session बनेंगे। इसके बाद तीन चीज़ें अलगाव से बाहर रिसती हैं। हाँ, आगे मत पूछना चुनने पर वह नियम मुख्य checkout की .claude/settings.local.json में सहेजा जाता है, इसलिए वह मुख्य checkout और हर दूसरे worktree में लागू होता है और जिस worktree में बना था उसके मिटने के बाद भी बचा रहता है। agent view में session डिलीट करने पर Claude का बनाया worktree भी साथ मिट जाता है, यानी बिना commit किया काम गायब हो जाता है — और Ctrl+X पहली बार में रोकता है, दूसरी बार में मिटाता है। और .worktreeinclude gitignore की गई फ़ाइलें, जैसे .env, हर नए worktree में कॉपी कर देती है, जिससे आपके क्रेडेंशियल उतनी ही बार गुणा होते हैं जितने session आप डिस्पैच करते हैं। इसके ऊपर, कोटा समानांतरता के अनुपात में घटता है (दस एजेंट उसे लगभग दस गुना तेज़ी से खर्च करते हैं), और session लोकल चलते हैं, स्लीप को पार कर जाते हैं पर मशीन बंद होते ही रुक जाते हैं। लेख के आखिर में agent view को समानांतरीकरण के चार आधिकारिक तरीकों के बीच रखा गया है, सबएजेंट, agent teams और डायनेमिक वर्कफ़्लो के साथ, और डिस्पैच से पहले, उसके दौरान तथा उसके बाद के लिए एक ठोस दिनचर्या दी गई है।

बहुत लोग Claude Code का /compact किसी नियम से दबाते हैं, जैसे हर 30 मिनट पर या कॉन्टेक्स्ट 70% पार करते ही, पर आधिकारिक दस्तावेज़ जो सुझाते हैं वह न घड़ी है और न प्रतिशत: वह काम का पड़ाव है। /compact किसी स्वाभाविक पड़ाव पर चलाएँ, जैसे दो टास्क के बीच में, बजाय इसके कि आप टास्क के बीचोंबीच ऑटो-कॉम्पैक्शन के चलने का इंतज़ार करें। यह लेख 8 अगस्त 2026 तक के Claude Code दस्तावेज़ (उस समय नवीनतम रिलीज़ v2.1.226) को प्राथमिक स्रोत मानकर हाथ से कॉम्पैक्ट करने का सवाल स्पेसिफिकेशन से हल करता है। शुरुआत मशीनरी से होती है: कॉम्पैक्शन तीन चरणों में चलती है, यानी पुराने टूल आउटपुट गिराना, ऑटो-कॉम्पैक्शन, और वह /compact जो आप खुद दबाते हैं। दूसरा और तीसरा एक ही प्रक्रिया हैं, इसलिए खुद दबाने से ठीक दो चीज़ें मिलती हैं, समय चुनना और यह बताना कि क्या रखा जाए। बार-बार दबाने से अतिरिक्त कॉन्टेक्स्ट नहीं बचता। इसके बाद आती है इस बात की तालिका कि क्या बचता है। प्रोजेक्ट रूट का CLAUDE.md और आपकी ऑटो मेमोरी डिस्क से दोबारा इंजेक्ट होते हैं, जबकि paths: वाले नियम और सब-डायरेक्टरी की नेस्टेड CLAUDE.md फाइलें तब तक खोई रहती हैं जब तक मेल खाती कोई फाइल दोबारा न पढ़ी जाए, और आपने जो स्किल चलाई थीं उनका पाठ प्रति स्किल 5,000 टोकन तथा कुल 25,000 टोकन की सीमा में दोबारा इंजेक्ट होता है, जिसमें सबसे पुराना पहले गिरता है। लागत के मामले में, कॉम्पैक्शन की कीमत कॉन्टेक्स्ट के आकार से नहीं, बल्कि इससे तय होती है कि prompt cache गर्म है या नहीं। सेशन के बीच दबाएँ तो prefix cache से पढ़ा जाता है, जो सस्ता है; cache की उम्र से लंबे ब्रेक के बाद दबाएँ, यानी सब्सक्रिप्शन पर एक घंटा और API key पर डिफ़ॉल्ट पाँच मिनट, तो पूरा इतिहास बिना cache के दोबारा प्रोसेस होता है, और वही कमांड जितना महँगा हो सकता है उतना हो जाता है। आगे लेख यह भी बताता है कि /compact, /clear, /rewind, /recap और /context में से कैसे चुनें, v2.1.221 से आई /autocompact कमांड ऑटो-कॉम्पैक्शन के बिंदु को 100K से 1M टोकन तक कैसे हिलाती है और उसकी चार जगहों की वरीयता क्या है, वह जाल कि सिर्फ़ एनवायरनमेंट वेरिएबल सादा पूर्णांक लेता है, तथा Not enough messages to compact. और Autocompact is thrashing: the context refilled to the limit... इन दो संदेशों का मतलब और उनसे उबरने के कदम।

Windows पर Claude Desktop खोलने जाइए और उसकी जगह एक डायलॉग आ जाता है — Can't open this app — जो कहता है कि Claude के advanced options में जाकर Repair चुनना पड़ेगा; और जो लिखा है ठीक वही करने से काम बन जाता है। न अनइंस्टॉल, न वह Reset जो डेटा उड़ा देता है। बीच में एक क़दम ज़रूर ऐसा है जहाँ लोग सचमुच अटकते हैं, और यही लेख का केंद्र है: Repair दबाने पर जवाब में यह आ सकता है कि ऐप अभी चल रहा है, जबकि Claude की कोई विंडो कहीं खुली नहीं होती। वजह यह है कि Claude Desktop विंडो बंद करने के बाद भी सिस्टम ट्रे में चलता रहता है, और वही प्रोसेस पैकेज की फ़ाइलें पकड़े रहती है, इसलिए Repair पूरा नहीं हो पाता। इलाज सीधा है — प्रोसेस को साफ़-साफ़ बंद कीजिए, फिर Repair दबाइए। यही तथ्य ख़राबी की वजह की तरफ़ भी इशारा करता है: उसी एक प्रोसेस ने पहले अपडेट बिगाड़ा और फिर Repair को रोका। लेख उस सवाल का जवाब भी देता है जो सबसे पहले पूछा जाता है — क्या सेशन मिट जाते हैं? जवाब तीन हिस्सों में बँटता है। claude.ai की बातचीत का इतिहास Anthropic के सर्वर पर है, उसे कुछ नहीं होता। Claude Code के सेशन %USERPROFILE%\.claude\projects\ में, यानी ऐप पैकेज के बाहर रहते हैं, इसलिए वे Repair, Reset और अनइंस्टॉल तक झेल जाते हैं (एक असली मशीन पर 52 प्रोजेक्ट में 2,977 फ़ाइलें, लगभग 3.0GB मिलीं)। ख़तरे में सिर्फ़ %APPDATA%\Claude वाली ऐप की सेटिंग्स हैं, और Repair उन्हें भी बचा लेता है — Windows यह फ़र्क़ उसी स्क्रीन पर लिखकर बताता है, Repair के नीचे कि ऐप का डेटा प्रभावित नहीं होगा और Reset के नीचे कि ऐप का डेटा मिटा दिया जाएगा। आगे सिर्फ़ पढ़ने वाली PowerShell जाँच, बैकअप का तरीक़ा, न खुलने पर क्रमवार अगले क़दम (vmcompute और hns चल रही हैं या नहीं, फिर -PreserveApplicationData के साथ दोबारा इंस्टॉल), आधे रजिस्टर हुए MSIX वाली अनुमानित वजह और उससे जुड़े GitHub issues (#55465, जिसमें इंस्टॉल कामयाब रहा पर कोई एंट्री पॉइंट नहीं बना, तथा #50285 और #48437 — सभी बिना किसी आधिकारिक सुधार के closed as not planned), दोबारा होने के आसार घटाने के उपाय, और पुराने इंस्टॉलर वाले बिल्ड से तुलना, जहाँ MSIX का ताज़ा रिलीज़ और पुराने फ़ॉर्मैट वाली मशीन दोनों 1.24012.9 निकले। नोट: डायलॉग के पाठ अंग्रेज़ी Windows के मुताबिक़ अक्षरशः दिए गए हैं, क्योंकि हिंदी Windows के ठीक-ठीक शब्दों की पुष्टि किसी आधिकारिक स्रोत से नहीं हो सकी; साथ में यह भी बताया गया है कि डायलॉग पहचानें कैसे।

Claude Code जवाब के बीचोंबीच «API Error: Connection closed mid-response. The response above may be incomplete.» कहकर रुक जाता है। यह प्रॉम्प्ट की गलती नहीं — स्ट्रीमिंग जवाब को ले जा रहा कनेक्शन तब बंद हुआ जब जवाब अभी आ ही रहा था। यह लेख सिर्फ़ आधिकारिक एरर रेफ़रेंस, आधिकारिक changelog और पैकेट कैप्चर से समर्थित असली Issues पर आधारित है। पहले आधिकारिक परिभाषाएँ: Connection closed यानी लिंक कट गया, Response stalled यानी वह चुप हो गया, Server error यानी स्ट्रीम के बीच 5xx आया; और यह भी कि आंशिक आउटपुट जानबूझकर क्यों रखा जाता है (दोबारा भेजने पर वही टूल कॉल दो बार चल सकते हैं) तथा आधिकारिक रिकवरी स्टेप है continue लिखना। फिर कनेक्शन बंद होने की तीन परतें अलग की गई हैं (आपकी मशीन और स्लीप, प्रॉक्सी या VPN का आइडल टाइमआउट, या सर्वर की ओर से बंद होना), और Issue #67766 के रिपोर्टर द्वारा प्रकाशित माप दिए गए हैं: दसों घटनाएँ सर्वर की ओर से साफ़ बंद होना थीं, FIN के 3 से 105 ms बाद एरर दिखी, तब तक जवाब का 7 से 20 KB आ चुका था, रिक्वेस्ट बॉडी 1 से 2.5 MB थी, नया कनेक्शन लगभग 20 ms में सफल रहा, और 23 दिनों के रिकॉर्ड में 171 घटनाओं में 200 एरर मिलीं जिनमें 87 पिछली कॉल के पाँच सेकंड के भीतर थीं। लेख का व्यावहारिक केंद्र changelog की असली प्रविष्टियों की टाइमलाइन है — 2.1.179 आंशिक जवाब बचाता है, 2.1.185 स्टॉल संकेत 10 से 20 सेकंड करता है, 2.1.198 अस्थायी ड्रॉप को बैकऑफ़ के साथ दोहराता है, 2.1.199 स्ट्रीम के बीच सर्वर एरर पर भी आंशिक हिस्सा रखता है, और 2.1.214 पुराने कनेक्शन की एरर के बाद keep-alive पूल निष्क्रिय करता है — जिसे रिपोर्ट किए गए वर्शनों (2.1.173, 2.1.181, 2.1.183) से मिलाया गया है, जो सभी 2.1.198 से पुराने हैं। अंत में जोखिम बढ़ाने वाले हालात, आठ क़दमों की यूज़र चेकलिस्ट, डेवलपर्स के लिए छह दिशानिर्देश, Unable to connect और Prompt is too long से फ़र्क, तथा पुष्ट और अपुष्ट का साफ़ बँटवारा।

Anthropic ने 24 जुलाई 2026 को Claude Opus 5 रिलीज़ किया, और उसका अपना डॉक्यूमेंटेशन इसे Opus 4.8 का क्रमिक सुधार नहीं बल्कि एक step-change बताता है — फिर भी कीमत टस से मस नहीं हुई: प्रति मिलियन टोकन $5 input / $25 output, यानी फ्लैगशिप Fable 5 ($10 / $50) से ठीक आधी। यह लेख आधिकारिक अनाउंसमेंट और डॉक्यूमेंटेशन को कई रिपोर्ट्स से मिलाकर जाँचता है और सामने रखता है: मुख्य स्पेसिफिकेशन (claude-opus-5, 1M context जो डिफ़ॉल्ट भी है और अधिकतम भी, 128K अधिकतम output, knowledge cutoff मई 2026), कीमत के साथ cache दरें और fast mode (2x कीमत पर करीब 2.5x रफ़्तार, सिर्फ़ Claude API), तथा बेंचमार्क (Anthropic अपने टेक्स्ट में खुद कहता है कि Frontier-Bench पर स्कोर Opus 4.8 से दोगुने से ज़्यादा है, CursorBench 3.2 पर यह Fable 5 के 0.5% के भीतर रहता है, ARC-AGI 3 पर दूसरे नंबर से तीन गुना है, और OSWorld 2.0 पर Fable 5 को करीब एक-तिहाई लागत में पीछे छोड़ता है; चार्ट से पढ़े गए मीडिया-स्रोत आँकड़ों में Frontier-Bench 43.3%, ARC-AGI-3 30.2%, GDPval-AA 1,861 और OSWorld 70.6% शामिल हैं)। साथ ही वे जगहें भी, जहाँ यह अब भी पीछे है (DeepSWE v1.1 पर 68.8% बनाम GPT-5.6 Sol का 72.7%, आक्रामक सुरक्षा और लंबी अवधि की बायोलॉजी रिसर्च जहाँ Mythos 5 आगे है, और वे सेटिंग्स जहाँ max effort का स्कोर नीची सेटिंग्स से कम रहा)। इसके बाद लेख API के दो breaking changes समझाता है (thinking अब डिफ़ॉल्ट रूप से ऑन है, इसलिए कसे हुए max_tokens बजट पर जवाब बीच में कट जाता है; thinking बंद करना सिर्फ़ effort high या उससे नीचे पर ही चलता है, xhigh या max पर 400 error मिलता है), पाँच effort लेवल में से चुनाव कैसे करें, नए फीचर जैसे बातचीत के बीच tool बदलना, 512 टोकन की नई cache न्यूनतम सीमा और default fallback मोड, और स्वभाव में आया बदलाव — लंबे जवाब, ज़्यादा टिप्पणी, ज़्यादा delegation और बिना कहे खुद जाँच — इस नियम के साथ कि माइग्रेशन में आप prompt का टेक्स्ट जोड़ते नहीं, हटाते हैं। अंत में यह बताता है कि किसे अभी माइग्रेट करना चाहिए, साथ में छह कदमों की माइग्रेशन चेकलिस्ट।

आप कोई local LLM चलाने के लिए Hugging Face खोलते हैं और वही मॉडल फ़ाइलों की दीवार (Q4_K_M, Q5_K_S, GPTQ, AWQ, IQ3_M) के साथ दिखता है और आप जड़ हो जाते हैं। यह लेख व्यावहारिक रूप से बताता है कि इसे चलाने के लिए कौन-सी क्वांटाइज़्ड फ़ाइल डाउनलोड करें, क्वांटाइज़ेशन क्या है की अवधारणा को दूसरे लेख पर छोड़कर फ़ॉर्मैट चुनने पर ध्यान देता है। चुनाव दो चरणों का है: कौन-सा फ़ॉर्मैट (= किस इंजन पर चलाएँगे), फिर कौन-सी बिट-डेप्थ। सबसे अहम तथ्य यह है कि क्वांटाइज़्ड फ़ाइल केवल उन्हीं इंजनों पर चलती है जो उसके फ़ॉर्मैट को सपोर्ट करते हैं। GGUF एकमात्र लोकल सब-कुछ फ़ॉर्मैट है जो CPU, Mac और आंशिक-GPU पर चलता है (llama.cpp/Ollama); GPTQ/AWQ/EXL2 GPU-पहले हैं (vLLM/TGI); bitsandbytes Transformers में लोड पर बिना कैलिब्रेशन क्वांटाइज़ करता है। GGUF नाम Q4_K_M तीन हिस्से हैं: Q4 (नाममात्र 4-bit, बड़ा = बेहतर और बड़ा), K (सुपर-ब्लॉक्स पर K-quant; साधारण/_0/_1 पुराने), M (S/M/L = कुछ अहम टेंसर्स कितना अपग्रेड होते हैं; असरदार बिट्स लेबल से ऊपर, Q4_K लगभग 4.5 bpw)। IQ परिवार (I-quants) उसी बिट पर और छोटा जाता है पर इन्फ़रेंस में भारी और imatrix (कैलिब्रेशन से आया importance matrix जो अहम वेट्स की रक्षा करता है) चाहिए। GPTQ लेयर-दर-लेयर त्रुटि न्यूनतम करता है; AWQ activations के ज़रिए अहम वेट्स की रक्षा करता है (कोई सार्वभौमिक रूप से बेहतर नहीं)। बिट-डेप्थ के लिए संशय हो तो Q4_K_M (कई मॉडलों के लिए Ollama डिफ़ॉल्ट), VRAM बचा हो तो Q5_K_M/Q6_K, Q8_0 लगभग बिना-हानि पर अनुशंसित नहीं, और IQ2/IQ3 केवल बड़े मॉडल को ठूँसने के लिए। लगभग 4.5 से 5 bpw स्वादिष्ट पट्टी है (एक हेयुरिस्टिक)। फ़ाइलें library=gguf, bartowski/mradermacher (सक्रियता बदलती है), या Ollama टैग model:size-variant-quant से ढूँढें। अंक अनुमानित हैं और मॉडल तथा बिल्ड के अनुसार बदलते हैं।

अब जब "बस AI से पूछ लो" और "पूरा AI से लिखवा लो" डिफ़ॉल्ट बन गया है, असली धार वाला सवाल इसका उल्टा है: क्या यह सचमुच ऐसी स्थिति है जहाँ मुझे AI इस्तेमाल करना चाहिए? यह लेख AI-विरोधी नहीं है; यह "इस्तेमाल न करें" को एक विकल्प बनाए रखने के बारे में है, ठीक इसलिए ताकि आप AI से ज़्यादा से ज़्यादा फ़ायदा उठा सकें. AI डिफ़ॉल्ट रूप से इस्तेमाल की जाने वाली चीज़ नहीं, बल्कि एक औज़ार है जिसे आप जानबूझकर चुनते हैं, और अच्छी तरह इस्तेमाल करना तथा न करना चुनना एक जोड़ी हैं. छह स्थितियाँ जहाँ इसे छोड़ना बेहतर है: 1. ऐसी पढ़ाई जो बुनियाद बनाए (सोचने के लिए लिखने की प्रक्रिया ही लक्ष्य है), 2. गोपनीय या व्यक्तिगत डेटा डालना (शर्तें और प्रतिधारण जाँचे बिना न चिपकाएँ), 3. घातक-अगर-गलत अंतिम निर्णय (चिकित्सा, कानून, सुरक्षा, पैसा बिना सत्यापन के न सौंपें), 4. लागत के लायक न होने वाले हल्के काम, 5. ऐसा काम जहाँ मानवीय भरोसा या रचनात्मकता केंद्र में हो (माफ़ी, भर्ती, रचयिता होना), 6. जब आप एकल विफलता-बिंदु नहीं जोड़ना चाहते (व्यावसायिक निरंतरता). तीन सवालों से जल्दी तय करें: क्या आप आउटपुट खुद सत्यापित कर सकते हैं, क्या यह केवल साझा करने योग्य डेटा है, और क्या यह प्रक्रिया अभी प्रशिक्षित करने लायक है. अगर सत्यापित कर सकते हैं, डेटा साझा करने योग्य है, और प्रशिक्षण नहीं चाहिए, तो AI इस्तेमाल करें; वरना छोड़ें या मानवीय जाँच डालें. हद से ज़्यादा इस्तेमाल के नुकसान (संज्ञानात्मक ऑफ़लोडिंग, प्रशंसनीय गलतियाँ स्वीकारना, निर्भरता) चर्चा के बिंदु हैं, ठोस आँकड़े नहीं. जानबूझकर AI छोड़ना कोई ब्रेक नहीं, बल्कि वह दूसरे-पहलू वाला कौशल है जो जहाँ फ़िट बैठे वहाँ पूरी तरह झोंकने देता है, और AI पर हद से ज़्यादा निर्भरता के खिलाफ़ बचाव है.

Claude Desktop (Windows) को अपडेट करने के तुरंत बाद ऐप लॉन्च करने पर "यह फ़ाइल किसी अन्य प्रोग्राम द्वारा उपयोग में है" दिखता है और यह शुरू नहीं होता — और PC रीस्टार्ट करने तक ठीक नहीं होता। यह Microsoft Store (MSIX) बिल्ड का एक ज्ञात बग है (GitHub #53247 और अन्य)। मुख्य बात: पूरा PC रीस्टार्ट ज़रूरी नहीं — कई मामलों में केवल Windows से साइन आउट करके वापस साइन इन करने से ही यह ठीक हो जाता है (PC रीस्टार्ट नहीं, और Claude से लॉग आउट भी नहीं), क्योंकि इसके पीछे का अनाथ हैंडल प्रति Windows यूज़र सेशन बना रहता है। CoworkVMService को बंद करना या पैकेज को पुनः-रजिस्टर करना काम नहीं करता, ऐसी रिपोर्ट है। डायलॉग के शब्दों के बावजूद, यह सत्यापित है कि यूज़र-स्पेस में कोई फ़ाइल लॉक नहीं है (handle.exe / Process Explorer): असली विफलता AppX/Desktop Bridge की कंटेनर लेयर में, Job Object → Silo रूपांतरण पर है (0x80070020 = ERROR_SHARING_VIOLATION, इवेंट 215/208)। ट्रिगर की दो अनिर्णीत व्याख्याएँ हैं — सर्विस का Job Object को पकड़े रखना (#57221) बनाम स्टार्टअप क्रैश से सफ़ाई न होना (#53247) — और कोई आधिकारिक फिक्स जारी नहीं हुआ है। स्थायी उपाय Squirrel (इंस्टॉलर) बिल्ड पर स्विच करना है। यह एक ही मशीन (Windows 11 Home 10.0.26200) पर आधारित है, GitHub issues के साथ मिलाकर परखा गया; पूरे लेख में भरोसा-लेबल लगाए गए हैं।

Claude Code में लंबे सेशन के दौरान जवाब अचानक «court court court…» यही शब्द दर्जनों से सैकड़ों बार दोहराने लगता है और अंत में «API Error: Response stalled mid-stream. The response above may be incomplete.» दिखाकर रुक जाता है। यह आपकी प्रॉम्प्ट की गलती नहीं, बल्कि दो अलग ज्ञात bug की श्रृंखला है——① मॉडल की पुनरावृत्ति (डिजेनरेशन) लूप और ② स्ट्रीम का बीच में रुकना। यह लेख दोनों की असल वजह, उकसाने वाली स्थितियाँ, तुरंत रोकने का तरीका (Esc → नया सेशन → /clear), डेवलपर्स के लिए API/SDK बचाव और «court/invoke टैग लीक» जैसी मिलती-जुलती त्रुटियों से अंतर को आधिकारिक Issue के आधार पर समझाता है।