AI टूल्स की गाइड, तुलना और नवीनतम समाचार

2 अगस्त 2026 को EU AI Act के बाक़ी प्रावधान आम तौर पर लागू हुए, और उसके साथ ही यह दावा अचानक हर जगह दिखने लगा कि AI से लिखे लेख पर लेबल न लगाना अब गैरकानूनी है। छोटा जवाब यह है कि अधिकतर व्यक्तिगत लेखकों और कंपनी ब्लॉग पर प्रकटीकरण का दायित्व पैदा ही नहीं होता। अनुच्छेद 50(4) साफ़ शब्दों में कहता है कि जहाँ सामग्री इंसानी समीक्षा या संपादकीय नियंत्रण से गुज़री हो और कोई उस प्रकाशन की संपादकीय ज़िम्मेदारी उठाता हो, वहाँ यह दायित्व लागू नहीं होता। साथ जुड़ी शर्त यह है कि समीक्षा सारभूत होनी चाहिए और सतही बातों या केवल औपचारिक मंज़ूरी तक सीमित नहीं रहनी चाहिए, इसलिए बिना पढ़े अपने आप पोस्ट कर देने वाला तरीक़ा इसमें नहीं आता। यह लेख बताता है कि प्रदाता (provider) और उपयोगकर्ता (deployer) के दायित्व बिल्कुल अलग क्यों हैं, AI जनित टेक्स्ट का प्रकटीकरण विषय के बजाय प्रकाशन के उद्देश्य पर क्यों तय होता है, डीपफ़ेक का प्रकटीकरण दायित्व और कलात्मक तथा व्यंग्यात्मक कृतियों के साथ किया गया नरम बर्ताव क्या है, चैटबॉट की सूचना कैसी होनी चाहिए, C2PA Content Credentials जैसी मशीन-पठनीय मार्किंग प्रदाता का दायित्व क्यों है, और 2 दिसंबर 2026 तथा 2 फ़रवरी 2027 की समयसीमाएँ क्या हैं। हर बात उतनी ही रखी गई है जितनी क़ानूनी पाठ और यूरोपीय आयोग की सामग्री पर पुष्ट की जा सकी।

OpenAI ने 3 सितंबर 2026 को GPT-6 Astra जारी किया। API बिना किसी गेट के आम तौर पर उपलब्ध है, मॉडल ID gpt-6-astra है, कॉन्टेक्स्ट 1,050,000 टोकन का है, कीमत इनपुट $10 और आउटपुट $50 प्रति दस लाख टोकन है, और नॉलेज कटऑफ 30 अप्रैल 2026 है। लेकिन "जारी हो गया" और "आपके प्लान में इस्तेमाल हो सकता है" दो अलग बातें हैं: ChatGPT Plus की सामान्य चैट स्क्रीन पर यह दिखाई नहीं देता, और वहाँ रास्ता ChatGPT Work तथा Codex है। यह लेख प्लान के हिसाब से उपलब्धता, प्रति-यूनिट दर दोगुनी होने पर भी प्रति टास्क लागत के पलट जाने वाले गणित को देखने का तरीक़ा, OpenAI ने असल में जिन बेंचमार्क के नाम गिनाए वे, Preparedness Framework में पहली बार "Critical" तक पहुँची साइबर क्षमता और उसके चारों ओर खींची गई लकीर, माइग्रेशन में टूटने वाली चार चीज़ें (सैंपलिंग वाले आर्ग्युमेंट हटाना, Responses API, none वाली रीज़निंग एफर्ट का न होना, कैश सेटिंग का नया नाम), तथा Claude Opus 5, Fable 5.1 और Gemini 3.8 Flash से तुलना — सब कुछ सिर्फ़ उतना, जितना प्राथमिक स्रोतों पर पुष्ट किया जा सका। साथ ही यह भी लिखा है कि दूसरी जगहों पर घूम रही "Astra 74.1% बनाम Opus 5 96%" जैसी तुलना तालिका हमने क्यों नहीं दी।

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 Code जवाब के बीच में API Error: Connection lost mid-response. The response above may be incomplete. दिखाकर रुक जाता है, और इस वाक्य को ज्यों का त्यों खोजने पर लगभग कुछ नहीं मिलता, क्योंकि वाक्य ख़ुद नया है। आधिकारिक एरर रेफ़रेंस इसे सीधे लिखता है: v2.1.227 से पहले Connection lost mid-response को Connection closed mid-response के रूप में दिखाया जाता था, और उसी बदलाव में Response stalled mid-stream, The response stopped arriving बन गया तथा Connection closed while thinking, before producing a response, Connection lost before a response was produced बन गया। घटना नई नहीं है, सिर्फ़ स्क्रीन पर दिखने वाला शब्द बदला है; इसीलिए पुराने नाम से लिखी सामग्री आज भी ज्यों की त्यों लागू होती है और issue खोजते समय दोनों वाक्य आज़माने पड़ते हैं। इसी नाम-परिवर्तन से शुरू करके यह लेख सिर्फ़ आधिकारिक दस्तावेज़ और सार्वजनिक Issue पर टिका रहता है। इसमें बीच में कटने वाले चारों संदेशों की आधिकारिक परिभाषा है (Server error, Connection lost, Your computer went to sleep और The response stopped arriving), यह भी कि स्क्रीन पर आ चुका आउटपुट जानबूझकर क्यों रखा जाता है, क्योंकि रिक्वेस्ट दोबारा भेजने पर वही टूल कॉल दो बार चल सकती है, और यह भी कि रिकवरी का तरीक़ा शुरू से दोहराना नहीं बल्कि continue लिखकर भेजना है। फिर आधिकारिक Automatic retries के विभाजन से समझाया गया है कि अपने आप दोबारा कोशिश क्यों नहीं होती: कुछ भी पूरा होने से पहले का कटाव एक्सपोनेंशियल बैकऑफ़ के साथ अधिकतम 10 बार दोबारा भेजा जाता है, सोच के बाद पर आउटपुट से पहले का कटाव अधिकतम 2 बार, और उसके बाद टर्न Connection lost before a response was produced पर ख़त्म हो जाता है, जबकि कोई ब्लॉक पूरी हो जाने के बाद का कटाव दोबारा भेजा ही नहीं जाता। इसके आगे स्ट्रीम टूटने की तीन परतें हैं, यानी अपना डिवाइस और लाइन, प्रॉक्सी तथा गेटवे वाला रास्ता, और सर्वर की ओर के साथ कनेक्शन का दोबारा इस्तेमाल; आसानी से छूट जाने वाली चौथी वजह mTLS सर्टिफ़िकेट रोटेशन और v2.1.232 से उसका दोबारा पढ़ा जाना; तथा नौ कदमों की छँटाई चेकलिस्ट। चार स्ट्रीम निगरानी टाइमर उनके डिफ़ॉल्ट मानों के साथ दिए हैं (first byte 180 सेकंड, event level 300 सेकंड, byte level 180 सेकंड, body idle 5 मिनट) और साथ में CLAUDE_CODE_MAX_RETRIES, CLAUDE_CODE_RETRY_WATCHDOG, API_TIMEOUT_MS तथा दो स्ट्रीम टाइमआउट वेरिएबल, यह साफ़ करते हुए कि रीट्राई की संख्या बढ़ाने से यह ख़ास संदेश कम नहीं होता। एक तुलना तालिका आठ मिलते-जुलते संदेशों को अलग करती है, और दो सार्वजनिक रिपोर्टें, #86473 तथा #85979, दिखाती हैं कि सादा HTTPS और curl पूरे हो जाते हैं जबकि सिर्फ़ CLI ECONNRESET से गिरता है। अंत में जो आधिकारिक रूप से पुष्ट है और जो सिर्फ़ रिपोर्ट है, दोनों अलग किए गए हैं, जिसमें यह भी शामिल है कि v2.1.222 से पहले के वर्शन जवाब पूरा होने पर भी यही सूचना दिखा सकते थे।

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 में अलग रखा गया है, जबकि बाकी चार में वे बीटा सुविधाएँ हैं जो ठीक उन्हीं पैटर्न की जगह लेने के लिए बनी हैं जिन्हें ब्रेकिंग चेंज मना करते हैं।

"क्या AI मेरी नौकरी छीन लेगा" अब इस कहानी के लिए सही सवाल नहीं रहा। UCLA Anderson के Siddiq और Zhang ने Upwork पर 49,610 फ्रीलांसरों और 2.26 मिलियन अनुबंधों को जनवरी 2021 से मार्च 2026 तक देखा, और जो मिला वह यह नहीं था कि काम मौजूद है या नहीं, बल्कि यह कि चुने कैसे जाते हैं: मानव-पूंजी संकेतों पर क्लाइंट का वज़न 7.8% घटा जबकि क़ीमत का वज़न 1.1% बढ़ा, और अनुबंधों की संख्या 7.0% गिरी। सत्यापित प्रमाणपत्र, कार्य-इतिहास, पोर्टफ़ोलियो और क्लाइंट रेटिंग, सबने यह बताने की ताक़त खो दी कि अनुबंध कौन जीतेगा, और जितना हालिया दौर देखिए गिरावट उतनी तीखी है, हालिया चार तिमाहियों में संकेतों पर -10.1% और क़ीमत पर +1.8%। इसी बीच आपूर्ति पक्ष उल्टी दिशा में चल रहा है: Upwork बताता है कि अमेरिका के कुशल ज्ञान-कर्मियों में फ्रीलांस हिस्सा एक ही साल में 28% से 38% हो गया, और 58% पूर्णकालिक कर्मचारी बदलाव पर विचार कर रहे हैं। केंद्र में दो विरोधाभास हैं। पहला, अनुभव नौकरी में ढाल है और ठेके के काम में नहीं, क्योंकि Stanford के अनुसार AI-प्रभावित व्यवसायों में 22 से 25 वर्ष के कर्मियों का रोज़गार लगभग 19% कम है जबकि अनुभवियों में तुलनीय अंतर नहीं, वहीं फ्रीलांसरों पर Organization Science का अध्ययन कहता है कि गिरावट सबसे अनुभवी लोगों में सबसे बड़ी थी। कंपनी एक भूमिका नियुक्त करती है; क्लाइंट एक डिलिवरेबल ख़रीदता है। दूसरा, काम गायब नहीं हुआ, बीच का हिस्सा गायब हुआ: Management Science के अनुसार स्वचालन के लिए सबसे खुली पोस्टिंग 21% घटीं, और जो काम बचे वे अधिक जटिल हैं और ज़्यादा भुगतान करते हैं। लेख केवल सहकर्मी-समीक्षित शोधपत्रों और प्लेटफ़ॉर्म के आधिकारिक अध्ययनों का उपयोग करता है, हर आँकड़ा प्रकाशक तक जाकर जाँचा गया है, Upwork को हितबद्ध पक्ष के रूप में चिह्नित करता है, इस व्यापक रूप से दोहराए गए दावे को सुधारता है कि उसकी फ़रवरी की रिलीज़ ने प्रति घंटा 44% प्रीमियम बताया था (उसमें ऐसा कुछ नहीं है), और शोधकर्ताओं की अपनी चेतावनियाँ साथ रखता है, जिसमें Stanford का यह कहना भी शामिल है कि समय का कुछ हिस्सा AI के अलावा दूसरे कारणों से है। तीन पूर्वानुमानों के साथ भरोसे के लेबल और ग़लत साबित होने की शर्तें हैं, और क्या करें वाला अंतिम अध्याय अनुमान के रूप में चिह्नित है।

अपने ही 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%), सेटअप के चार क़दम, यह क्यों अब नहीं कहा जा सकता कि लोकल क्लाउड के कितने प्रतिशत पर है, और यह कि लोकल मुफ़्त नहीं बल्कि अलग रूप की लागत है।

Remote Control, Claude मोबाइल ऐप या claude.ai/code को उस Claude Code session से जोड़ता है जो आपकी अपनी मशीन पर पहले से चल रहा है, और ज़्यादातर व्याख्याएँ जो बात छोड़ देती हैं वह यह है कि कुछ भी क्लाउड में नहीं जाता: कोड चलाना और फ़ाइल तक पहुँच पूरे समय लोकल ही रहती है, और फ़ोन उस session में झाँकने की खिड़की भर है। यह लेख उसी डिज़ाइन के फ़ायदे और उसकी क़ीमत, दोनों को खोलकर देखता है। आपका लोकल फ़ाइल-सिस्टम, MCP सर्वर, टूल और प्रोजेक्ट कॉन्फ़िगरेशन सब उपलब्ध रहते हैं (@ टाइप करते ही लोकल प्रोजेक्ट के पाथ अपने आप पूरे होते हैं), बातचीत और सबएजेंट की प्रगति टर्मिनल, ब्राउज़र तथा फ़ोन पर सिंक रहती है, और सोया हुआ लैपटॉप या टूटा कनेक्शन झेल लिया जाता है क्योंकि Claude Code उबरते ही फिर जुड़कर कतार में रखे अपडेट पहुँचा देता है। शर्तें दिखने से ज़्यादा सख़्त हैं: Pro, Max, Team या Enterprise (API key समर्थित नहीं), setup-token नहीं बल्कि claude.ai से साइन-इन, api.anthropic.com से सीधा कनेक्शन, और टेलीमेट्री बंद करने वाले चार एनवायरनमेंट वेरिएबल में से कोई सेट न हो, यही वजह है कि DO_NOT_TRACK रखने वाले निजता-सजग लोगों को बताया जाता है कि फ़ीचर उनके अकाउंट पर चालू नहीं है। लेख तीनों प्रवेश-द्वार कवर करता है (मौजूदा बातचीत साथ ले जाने वाला /remote-control, claude --remote-control, और सर्वर मोड अपने --spawn, --capacity 32 तथा --continue फ़्लैग के साथ), साथ ही यह बँटवारा भी कि कौन-सी स्लैश कमांड दूर से चलती हैं और कौन-सी सिर्फ़ लोकल हैं जैसे /resume, पाँच मिनट की वह डायलॉग समय-सीमा जो permission प्रॉम्प्ट पर लागू नहीं होती, और पुश नोटिफ़िकेशन के दो टॉगल। सुरक्षा पर लेख जान-बूझकर स्पष्ट है: कोई इनबाउंड पोर्ट कभी नहीं खुलता, इसलिए नेटवर्क का हमला-क्षेत्र लगभग मिट जाता है और जोखिम अकाउंट पर चला जाता है, QR कोड प्रमाणीकरण नहीं बल्कि छोटा रास्ता है, और डिफ़ॉल्ट दरवाज़ा ठीक एक साइन-इन किया अकाउंट है, जिसकी वजह से passkey सबसे ऊँचे मूल्य का क़दम बन जाता है। ट्रांसक्रिप्ट कितने समय रखा जाता है (5 साल या 30 दिन), फ़ोन खो जाने पर क्या करें, 18 घंटे की साइन-इन खिड़की वाला Trusted Devices, सर्वर मोड का दस मिनट का टाइमआउट, चार घंटे की वापसी-खिड़की, दूरस्थ मशीनों पर tmux की अनिवार्यता, असली त्रुटि संदेशों से जुड़ी समस्या-निवारण तालिका, और Dispatch से तुलना इस लेख को पूरा करते हैं।

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

इस सवाल का जवाब कि "अगर 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 जैसे भीतरी-टूल वाले उत्पादों का तीसरा विकल्प सामने रखता है।

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 कहते हैं), और एक व्यावहारिक रेखा खींचता है: शुरुआत उस काम से कीजिए जिसे वापस लिया जा सके।