AI प्रोजेक्ट्स के लिए डेव एनवायरनमेंट और इंफ्रा गाइड

Claude Code का Projects नए सिरे से बनाया गया है। अब तक प्रोजेक्ट का मतलब था बातचीत और संदर्भ सामग्री रखने वाला एक फ़ोल्डर; नया Projects एक अकेली बातचीत है। आप जो चाहिए वह लिखते हैं, Claude उसे थ्रेड में बाँट देता है, थ्रेड क्लाउड में समानांतर चलते हैं, और हर थ्रेड काम ख़त्म होते ही एक पुल रिक्वेस्ट खोलकर रिपोर्ट कर देता है। लैपटॉप बंद कर देने से वे रुकते नहीं। पर कूदने से पहले तीन बातें जाँच लेने लायक़ हैं: इसे चला सकने वाले अकाउंट अब भी सीमित हैं (Pro और Max का पब्लिक बीटा, जो पहले उन अकाउंट तक जा रहा है जिनके पास कोई मौजूदा प्रोजेक्ट नहीं है), व्यवहार में github.com और Claude GitHub App अनिवार्य हैं, और यह आपकी उपयोग-सीमा जिस रफ़्तार से खाता है वह किसी अकेले सेशन जैसी नहीं है। यह लेख आधिकारिक दस्तावेज़ और ब्लॉग के आधार पर देखता है कि रोलआउट आप तक पहुँचा या नहीं यह कैसे जाँचें, थ्रेड किस सामान के साथ शुरू होता है (उस जाल समेत, जिसमें प्रोजेक्ट में एक से ज़्यादा रिपॉज़िटरी आते ही अनुमति नियम और हुक लागू होना बंद कर देते हैं), टोकन की लागत कहाँ से आती है — डिफ़ॉल्ट Opus high एफर्ट सहित — और समानांतर काम के पाँच तरीक़ों में से चुनें कैसे: सबएजेंट, agent view, एजेंट टीम, डायनामिक वर्कफ़्लो और Projects।

आप चाहते हैं कि योजना बनाने का काम ही समझदार मॉडल करे, और कार्यान्वयन तेज़ और सस्ता मॉडल। Claude Code का opusplan यही अपने-आप करने वाली मॉडल सेटिंग है। यह प्लान मोड के दौरान Opus पर और बाक़ी समय Sonnet पर चलता है, और /model opusplan या settings.json के model से इस्तेमाल होता है। लेकिन यह /model की सूची में नहीं दिखता, और प्लान मोड में जाने और निकलने पर हर बार मॉडल बदलता है, इसलिए हर बदलाव पर पूरी बातचीत बिना कैश के दोबारा पढ़ी जाती है। यह लेख 15 सितंबर 2026 तक के आधिकारिक दस्तावेज़, बदलाव-इतिहास और GitHub issue के आधार पर बताता है: सेट करने का तरीक़ा (वर्ज़न टिकाना और 1M कॉन्टेक्स्ट सहित), प्लान मोड से मंज़ूरी देकर कार्यान्वयन तक का क्रम, v2.0.0 में चुनने वाली स्क्रीन से हटाए जाने की पृष्ठभूमि और Anthropic के कर्मचारी का स्पष्टीकरण, बदलाव से होने वाली कैश लागत का अनुमान और उसे कम रखने के तरीक़े, advisor टूल और सबएजेंट से अंतर, और यह किस तरह के इस्तेमाल में ठीक बैठता है और किसमें नहीं।

क्या Claude Code का मुख्य सत्र Opus 5 पर रखकर, अनुवाद या बड़ी संख्या वाली जाँच जैसे काम ही Sonnet या Haiku वाले सबएजेंट को सौंपे जा सकते हैं? जवाब है, हाँ। सबएजेंट का मॉडल इस क्रम में तय होता है: बुलाते समय दिया गया मॉडल, परिभाषा फ़ाइल का model, एनवायरनमेंट वेरिएबल CLAUDE_CODE_SUBAGENT_MODEL, और फिर मुख्य सत्र का मॉडल, और प्रयास (effort) भी हर सबएजेंट के लिए अलग सेट किया जा सकता है। यह लेख 15 सितंबर 2026 तक के आधिकारिक दस्तावेज़ के आधार पर बताता है कि यह क्रम वर्ज़न के हिसाब से कैसे बदलता है, सभी सबएजेंट को एक ही मॉडल पर टिकाने वाला CLAUDE_CODE_SUBAGENT_MODEL_FORCE, प्रदाता के हिसाब से उपनाम किस मॉडल पर जाते हैं, और यह कि v2.1.198 से बिल्ट-इन Explore मुख्य सत्र का मॉडल लेता है। इसके बाद, सबएजेंट को सच में अलग मॉडल पर चलाकर बातचीत लॉग में जो देखा, वह साझा करता है: वे बताए गए मॉडल पर ही चले, हर एक ने सिर्फ़ शुरू होने में दसियों हज़ार टोकन पढ़े, सब्सक्रिप्शन पर भी सबएजेंट का कैश 5 मिनट में ख़त्म हो जाता है, और एक ही अनुवाद Opus 5, Sonnet 5 और Haiku 4.5 को दो-दो बार देने पर समय, लागत और अनुवाद की गुणवत्ता में क्या फ़र्क़ आया। आख़िर में, लागत और उपयोग सीमा पर इसका असर, और कौन-सा काम सस्ते मॉडल को देना है, यह तय करने की कसौटियाँ।

कई सत्र एक साथ चलाने पर यह सवाल उठने लगता है कि आपकी साप्ताहिक सीमा कौन-सा सत्र खा रहा है। फिर भी Claude Code का /usage सिर्फ़ मौजूदा सत्र के आँकड़े और स्किल, सबएजेंट, प्लगइन व MCP सर्वर के हिसाब से बँटी पूरे प्लान की खपत दिखाता है, और हर सत्र ने कितना हिस्सा लिया, यह न डेस्कटॉप ऐप की उपयोग रिंग में दिखता है, न claude.ai के सेटिंग पेज पर (सितंबर 2026 तक)। जवाब आपकी मशीन पर सहेजे गए बातचीत लॉग (~/.claude/projects की JSONL फ़ाइलें) में है, पर उन्हें जैसे हैं वैसे जोड़ने से नतीजा ग़लत आता है, क्योंकि एक जवाब कई पंक्तियों में, हर सामग्री खंड की एक पंक्ति के रूप में, लिखा जाता है, और सबएजेंट के रिकॉर्ड अलग फ़ाइलों में रहते हैं। मेरी अपनी मशीन पर मापने पर सीधा जोड़ सही मान का लगभग दोगुना निकला, और क्योंकि त्रुटि का आकार हर सत्र में अलग था, क्रम तक बदल गया। यह लेख बताता है कि आधिकारिक स्क्रीन क्या दिखाती हैं और क्या नहीं, लगभग 50 पंक्तियों की गिनती स्क्रिप्ट से लॉग को सही ढंग से कैसे गिनें, वह माप जिसमें एक सत्र ने कुल उपयोग का लगभग एक-तिहाई लिया, आँकड़े कहाँ तक कुछ बता सकते हैं, और समय के साथ नज़र रखनी हो तो OpenTelemetry कैसे सेट करें।

आपने हिंदी में पूछा, और Claude ने जवाब अंग्रेज़ी में दिया — Claude Code की आधिकारिक रिपॉज़िटरी में यही रिपोर्ट बार-बार आती है, और रिसर्च ने भी पाया है कि जब अनुरोध और जवाब की भाषा अलग-अलग हो, तो सबसे मज़बूत मॉडल भी माँगी गई भाषा में लगातार जवाब नहीं दे पाते। लेकिन कारण एक नहीं है। कोड और टूल आउटपुट पढ़ते-पढ़ते धीरे-धीरे अंग्रेज़ी की ओर बह जाना, बातचीत का सारांश बनाने वाले कॉम्पैक्शन के ठीक बाद भाषा भूल जाना, और अंग्रेज़ी के बजाय किसी दूसरी भाषा में बदल जाना — ये तीन प्रकार हैं, और हर एक पर अलग उपाय काम करता है। यह लेख हर प्रकार को पहचानने का तरीक़ा बताता है, समझाता है कि निर्देश को सिस्टम प्रॉम्प्ट में पक्का करने वाली Claude Code की language सेटिंग कॉम्पैक्शन के बाद भी क्यों असर करती रहती है, और सितंबर 2026 से रिपोर्ट होनी शुरू हुई "लंबे सेशन में आउटपुट ही बिखर जाने" की समस्या को, पक्की और अपुष्ट जानकारी को अलग रखते हुए समेटता है।

स्किल ज़रूरत से ज़्यादा डाल दो तो वे कॉन्टेक्स्ट को दबा देती हैं — इसमें आधा सच है और आधा ग़लत। Claude Code के आधिकारिक दस्तावेज़ के अनुसार, स्किल सूची को मॉडल के कॉन्टेक्स्ट विंडो का 1%, इतना तय बजट मिलता है, और आप चाहे जितनी स्किल जोड़ें, बात वहीं रुक जाती है। सूची फैलने के बजाय जो होता है वह यह है कि स्किल बुलाई जानी बंद हो जाती हैं — बजट से बाहर छलकते ही Claude Code सबसे कम बार बुलाई गई स्किल से विवरण गिराता है और सिर्फ़ नाम छोड़ देता है। जिस स्किल का विवरण मिट गया वह आपकी माँग से जुड़ना बंद कर देती है, फिर भी कोई त्रुटि नहीं आती और कुछ धीमा भी नहीं होता। यह लेख तीन मापक साधनों (/context, /usage और /skill-doctor) के अलग-अलग काम, कैश मिस की परिभाषा में 5% और 2,000 टोकन की शर्त, प्लान के हिसाब से कैश की उम्र का 1 घंटे से 5 मिनट पर आ जाना, MCP की टूल परिभाषाएँ डिफ़ॉल्ट रूप से लेज़ी-लोड होने के बाद भी CLI के हल्का बने रहने की वजह, CLAUDE.md को 200 पंक्तियों से कम रखने का आधार, और माप लेने के बाद सबसे पहले क्या घटाना है — यह सब उतना ही रखता है जितना आधिकारिक दस्तावेज़ पर पुष्ट किया जा सका।

Claude पर काम करते हुए हाथ रुक जाए और जो संदेश दिखा उसे ज्यों का त्यों खोजने पर कुछ न मिले, ऐसे वाक्य मौजूद हैं। The model returned no content because the response was blocked by content filtering, The response was blocked by the provider's content filter, Streaming response ended before any complete data was received, Could not locate the Claude CLI on PATH और Connection to Claude's response was lost. Claude may still be working, ये पाँच उसी के उदाहरण हैं। इन सबमें एक बात समान है कि ये Claude इस्तेमाल करते हुए दिखे फिर भी Claude की सामग्री में ढूँढ़ने पर मिलते नहीं, और वजह सीधी है, क्योंकि स्क्रीन पर जो संदेश है उसे लिखने वाला वही प्रोग्राम हो यह ज़रूरी नहीं जिसे आप सोच रहे हैं। यह लेख हर कारण को शुरू से समझाने के बजाय यह पहचानने का दरवाज़ा है कि संदेश किसने लिखा, ताकि सही लेख तक पहुँचा जा सके। पहले संदेश लिख सकने वाली परतें चार हिस्सों में बाँटी गई हैं, यानी मॉडल देने वाला बैकएंड, Claude Code ख़ुद, लॉन्च करने वाला IDE एक्सटेंशन या रैपर, और तीसरे पक्ष का क्लाइंट। फिर सचमुच मिलान करने पर पाँच में से दो Claude Code के आधिकारिक एरर रेफ़रेंस में प्रविष्टि के रूप में मिले। Streaming response ended… की आधिकारिक परिभाषा है कि हेडर लौटे मगर बॉडी में Claude API का कोई संदेश नहीं था, यानी बीच में कटने की बात नहीं। Could not locate the Claude CLI on PATH को आधिकारिक दस्तावेज़ Wrapper and IDE errors नाम के अलग अध्याय में रखते हैं, यानी इसे लॉन्च करने वाला प्रोग्राम छापता है। दूसरी ओर content filter वाले दो वाक्य तीसरे पक्ष की शब्दावली के हैं, और OpenCode का Issue #35736 रिपोर्ट करता है कि Vertex का 404, सॉकेट का टूटना और असली इनकार, ये तीन अलग-अलग नाकामियाँ सब एक ही blocked by content filter बनकर दिखती हैं। तीनों में से शब्द सिर्फ़ एक पर ठीक बैठते हैं। GitHub का आधिकारिक दस्तावेज़ भी लिखता है कि Claude इस्तेमाल करते समय इनपुट और आउटपुट GitHub Copilot के कंटेंट फ़िल्टर से गुज़रते हैं, इसलिए Claude चलाते हुए भी रोकने वाला Anthropic का फ़िल्टर ही हो यह ज़रूरी नहीं। बचा हुआ एक वाक्य न आधिकारिक रेफ़रेंस में मिला न Remote Control के दस्तावेज़ों में, इसलिए उसका स्रोत पहचाना नहीं जा सका और लेख किसी का नाम नहीं लेता, बल्कि ख़ुद पहचानने के चार कदम देता है। जो तय है और जो तय नहीं, दोनों लेबल लगाकर अलग किए गए हैं।

Claude Fable 5.1 पर माइग्रेट करना सिर्फ़ मॉडल ID बदलकर काम खत्म मान लेने का मामला नहीं है। Anthropic तीन बदलावों को ब्रेकिंग बताता है, और उनमें से दो वहाँ दिखते हैं जहाँ से वे पैदा नहीं हुए। पहला तुरंत एरर देता है: tool_choice में type any या type tool देने पर 400 invalid_request_error लौटता है, क्योंकि कॉल ज़बरदस्ती कराने से वह रीज़निंग छूट जाती है जो यह मॉडल हमेशा करता है, और उसी के साथ आर्ग्युमेंट की गुणवत्ता भी गिरती है। दूसरा चुपचाप काम करता है। थिंकिंग ब्लॉक अब दर्ज करते हैं कि उन्हें किस मॉडल ने बनाया और वे सिर्फ़ एक ही दिशा में आगे जाते हैं, इसलिए Fable 5.1 पर आने वाली बातचीत अपनी रीज़निंग बचाए रखती है जबकि कोई राउटर या फ़ॉलबैक उसे वापस पिछली पीढ़ी पर ले जाए तो वह पूरा टर्न खो देता है। डिफ़ॉल्ट रूप से API उन अपठनीय ब्लॉक को मॉडल के सामने पहुँचने से पहले ही फेंक देता है, और चूँकि फेंके गए टोकन न input_tokens में गिने जाते हैं और न उनका बिल बनता है, इसलिए इनवॉइस में कुछ नहीं दिखता। इसे दिखाई देने लायक बनाने के लिए thinking-binding-controls-2026-08-01 बीटा हेडर चाहिए। तीसरे का दायरा सबसे चौड़ा है: Fable 5.1 के थिंकिंग ब्लॉक से पहले की किसी भी चीज़ को बदलना, चाहे वह सिस्टम प्रॉम्प्ट हो, tools ऐरे हो या कोई पुराना मैसेज, उसे और उसके बाद के हर ब्लॉक को अमान्य कर देता है। यह अनिवार्य है या नहीं, यह इस पर टिका है कि आपका अकाउंट कब बना था, यानी अभी-अभी खड़ा किया गया स्टेजिंग फेल हो सकता है जबकि प्रोडक्शन नहीं। लेख यह भी बताता है कि क्या नहीं बिगड़ा: इनपुट $10 और आउटपुट $50 प्रति दस लाख टोकन पर बना हुआ है, जबकि कैश रीड घटकर $0.25 यानी बेस इनपुट का 0.025 गुना रह गई है, बाकी हर Claude मॉडल के 0.1 गुना के मुकाबले। Anthropic सामान्य वर्कलोड पर लगभग 25% और एजेंट-भारी काम पर लगभग 45% तक कम लागत बताता है। बिना कोई कोड बदले सात व्यवहार बदल जाते हैं, जिनमें समानांतर टूल कॉल का घटना, high effort पर प्रगति का कम ब्योरा और low effort पर याददाश्त से ज़्यादा जवाब शामिल हैं; और Anthropic पाँच नई चीज़ें गिनाता है, जिनमें से एक कैश रीड की कीमत में कटौती है जिसे अध्याय 5 में अलग रखा गया है, जबकि बाकी चार में वे बीटा सुविधाएँ हैं जो ठीक उन्हीं पैटर्न की जगह लेने के लिए बनी हैं जिन्हें ब्रेकिंग चेंज मना करते हैं।

अपने ही PC पर चलने वाले मॉडल से कोड लिखवाना कई साल से मुमकिन था, पर जो मुमकिन था वह सिर्फ़ कम्प्लीशन था; रिपॉज़िटरी पढ़ना, कई फ़ाइलें बदलना और टेस्ट चलाना लोकल मशीन के लिए बहुत भारी था। यह 2025 के आख़िर से बदला, और अब मॉडल बनाने वाले ख़ुद अपने मॉडल एजेंटिक कोडिंग के नाम पर बेचते हैं: Qwen का आधिकारिक मॉडल कार्ड CLINE का नाम सीधे लेता है, और Mistral ने 9 दिसंबर 2025 को Devstral 2 के साथ छोटे Devstral Small 2 (24B) को Apache 2.0 पर जारी किया। यह लेख सिर्फ़ प्राथमिक स्रोतों से बताता है कि आज कहाँ तक पहुँचा जा सकता है और कहाँ अटकते हैं। सबसे अहम बात वह सेटिंग है जिसे न बदलने पर सब कुछ चुपचाप टूटता है: Ollama की डिफ़ॉल्ट कॉन्टेक्स्ट लंबाई तय मान नहीं, बल्कि VRAM से चुनी जाती है, 24 GiB से कम पर सिर्फ़ 4k, 24 से 48 GiB पर 32k और 48 GiB से ऊपर 256k, इसलिए आम गेमिंग PC पर एजेंट का संदर्भ दरवाज़े पर ही कट जाता है और वह निर्देश भूलता है, वही काम दोहराता है और मक़सद खो देता है, बिना कोई एरर दिए। आधिकारिक सलाह कोडिंग जैसे भारी कामों के लिए कम से कम 64000 टोकन की है, पर बढ़ाने पर मेमोरी भी बढ़ती है, इसलिए ollama ps से जाँचना पड़ता है कि मॉडल पूरा GPU पर बैठा है। लेख Continue और Cline का फ़र्क़ खोलता है (एक हर भूमिका को अलग मॉडल देता है और हार्डवेयर की माँग कम रखता है, दूसरा स्वायत्त एजेंट है), VRAM के हिसाब से मॉडल चुनने की तालिका देता है (Qwen3.6-35B-A3B, 35B में 3B सक्रिय, SWE-bench Verified 73.4; Devstral Small 2, 24B, 68.0%), सेटअप के चार क़दम, यह क्यों अब नहीं कहा जा सकता कि लोकल क्लाउड के कितने प्रतिशत पर है, और यह कि लोकल मुफ़्त नहीं बल्कि अलग रूप की लागत है।

काम के बीच 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 के अपडेट से हुए ज़बरदस्ती बंद होने को असली क्रैश से कैसे अलग पहचानें।

इस सवाल का जवाब कि "अगर AI सीधे ही चीज़ें बदल सकता है तो क्या अब भी एडमिन पैनल चाहिए", किसी आम-सी घोषणा से नहीं निकलता, क्योंकि "एडमिन पैनल" यह अकेला शब्द बिलकुल अलग-अलग स्वभाव वाले फ़ीचरों के ढेर को समेटे हुए है। यह लेख इस साइट का अपना एडमिन पैनल पूरा मिटा देने के अनुभव पर टिका है और उस सवाल की जगह एक तीखा सवाल रखता है: क्या वह स्क्रीन कुछ ऐसा दे रही है जो CLI और AI पहले से नहीं दे रहे? पूरा पैनल मिटाकर जो सामने आया वह यह कि हटाए गए ज़्यादातर फ़ीचर "बेकार पड़े" नहीं, "ढाँचे से टूटे हुए" थे। लेखों का CRUD कभी काम कर ही नहीं सकता था, क्योंकि लेखों का असली स्रोत कोड में रहता है और हर deploy database को ऊपर से लिख देता है, इसलिए स्क्रीन से किया गया हर संपादन अगले deploy पर गायब हो जाता था। कमेंट मंज़ूरी की कतार हमेशा खाली रहती थी क्योंकि पोस्ट होते ही कमेंट पर मंज़ूर का निशान लग जाता था, यानी बिना मंज़ूरी वाला कमेंट कभी पैदा ही नहीं होता था। जिस फ़ीचर को कोई इस्तेमाल नहीं करता, उसके टूटे होने की खबर भी किसी को नहीं होती। इकलौती क्षमता जो हट नहीं सकती थी वह थी कमेंट मिटाना, और उसे भी एडमिन पैनल होने की कोई अनिवार्यता नहीं थी: लेख के पन्ने पर रखा एक delete बटन बेहतर निकला, क्योंकि आपत्तिजनक कमेंट ठीक वहीं हटाया जा सकता है जहाँ उसे पढ़ा जा रहा है। फ़ैसला छह सवालों पर उतरता है। इसे चलाता कौन है (ग़ैर-तकनीकी कर्मचारी या हाथ बदलती भूमिका UI के पक्ष में है, terminal में रहने वाले डेवलपर नहीं)। क्या यह पलटी जा सकती है (जो पलटी न जा सके, उसके आगे गेट चाहिए)। क्या इसमें इंसानी निर्णय चाहिए (क्या मंज़ूर-या-नामंज़ूर वाला स्थिति-परिवर्तन मौजूद है)। क्या अधिकार अलग करने हैं। क्या चलाने वाले को पता है कि मुमकिन क्या है (सूची ही दस्तावेज़ का काम कर देती है)। क्या कोई audit trail है। खासकर अधिकार और audit trail अकेले चलने वाले प्रोजेक्ट में ग़ैर-ज़रूरी लगते हैं और दूसरा व्यक्ति आते ही सबसे पहली ज़रूरत बन जाते हैं। कोड से किए गए बदलाव git में उतरते हैं, पर AI को सीधे database में लिखने देने पर डिफ़ॉल्ट रूप से कुछ भी दर्ज नहीं होता, और बातचीत का लॉग यह सँभालता है कि क्या माँगा गया था, यह नहीं कि क्या हुआ। छह कसौटियों में से सिर्फ़ पलटे जा सकने का वज़न अलग है। 18 जुलाई 2025 को Replit के एक AI एजेंट ने चालू code freeze के बीच SaaStr का production database मिटा दिया, 4,000 काल्पनिक उपयोगकर्ता गढ़ दिए और गलत ढंग से दावा किया कि rollback मुमकिन नहीं है, जिससे बहाली में देर हुई (AI Incident Database #1152) — यह मामला AI के ख़तरे से कहीं ज़्यादा वह डिज़ाइन-समस्या दिखाता है जिसमें पलटी न जा सकने वाली कार्रवाई तक बिना किसी इंसानी गेट से गुज़रे पहुँचा जा सकता था। लेख उन तीन तैयारियों को भी गिनाता है जो भार AI और CLI पर डालने से पहले चाहिए (बदलाव कोई टिकाऊ निशान छोड़ें, न पलटी जा सकने वाली कार्रवाई के आगे एक कदम हो, और प्रक्रिया लिखी हुई हो, क्योंकि UI मिटाने से यह सूची भी मिट जाती है कि मुमकिन क्या-क्या है), कुछ भी बनाने से पहले चलाने लायक एक चेकलिस्ट देता है, और पैनल हाथ से लिखने के बजाय Retool तथा Forest Admin जैसे भीतरी-टूल वाले उत्पादों का तीसरा विकल्प सामने रखता है।

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 और डायनेमिक वर्कफ़्लो के साथ, और डिस्पैच से पहले, उसके दौरान तथा उसके बाद के लिए एक ठोस दिनचर्या दी गई है।