Claude 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 कैसे सेट करें।

हर बार "पहले निष्कर्ष बताएँ" या "हिंदी में जवाब दें" कहने की ज़रूरत नहीं: हर बातचीत पर अपने आप लागू होने वाले निर्देश-फ़ील्ड में एक बार लिख देना काफ़ी है। ChatGPT में इसका नाम "कस्टम निर्देश", Claude में "Instructions for Claude" और Gemini में "Gemini के लिए निर्देश" है, लेकिन स्क्रीन पर नाम, जगह और लिखे जा सकने वाले अक्षरों की संख्या तीनों में अलग है। ChatGPT में Free और Go पर 1,500 अक्षर और Plus और ऊपर के प्लान पर 5,000 अक्षर (जुलाई 2026 में बढ़ाई गई) की सीमा है, जबकि Claude और Gemini ने सीमा प्रकाशित नहीं की है। यह लेख तीनों कंपनियों की आधिकारिक सहायता से जगह और सीमा की जाँच करता है, और Anthropic की आधिकारिक प्रॉम्प्ट गाइड के आधार पर असरदार लिखने का तरीका और उदाहरण दिखाता है। साथ ही, प्रोजेक्ट के अंदर, Gem के अंदर, अस्थायी चैट और कंपनी वाले अकाउंट जैसी उन स्थितियों को, जिनमें आधिकारिक सहायता के अनुसार निर्देश असर नहीं करते, एक जाँच-सूची में समेटता है।

आपने हिंदी में पूछा, और Claude ने जवाब अंग्रेज़ी में दिया — Claude Code की आधिकारिक रिपॉज़िटरी में यही रिपोर्ट बार-बार आती है, और रिसर्च ने भी पाया है कि जब अनुरोध और जवाब की भाषा अलग-अलग हो, तो सबसे मज़बूत मॉडल भी माँगी गई भाषा में लगातार जवाब नहीं दे पाते। लेकिन कारण एक नहीं है। कोड और टूल आउटपुट पढ़ते-पढ़ते धीरे-धीरे अंग्रेज़ी की ओर बह जाना, बातचीत का सारांश बनाने वाले कॉम्पैक्शन के ठीक बाद भाषा भूल जाना, अंग्रेज़ी के बजाय किसी दूसरी भाषा में बदल जाना, और सितंबर 2026 के आख़िर से Opus 5.5 में अचानक बढ़ा "टूल के बीच के सिर्फ़ छोटे संदेशों का अंग्रेज़ी में आना" — ये चार प्रकार हैं, और हर एक पर अलग उपाय काम करता है। यह लेख हर प्रकार को पहचानने का तरीक़ा बताता है, समझाता है कि निर्देश को सिस्टम प्रॉम्प्ट में पक्का करने वाली Claude Code की language सेटिंग कॉम्पैक्शन के बाद भी क्यों असर करती रहती है, सेटिंग से भी न रुकने वाले प्रकार 4 पर असर करने की रिपोर्ट वाला हुक क्या है, लेखक के रिकॉर्ड में बीच के संदेशों में अंग्रेज़ी लगभग 11% से लगभग 50% तक कैसे बढ़ी, और सितंबर 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 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, Part of the response never arrived और The response stream was malformed), यह भी कि स्क्रीन पर आ चुका आउटपुट जानबूझकर क्यों रखा जाता है, क्योंकि रिक्वेस्ट दोबारा भेजने पर वही टूल कॉल दो बार चल सकती है, और यह भी कि रिकवरी का तरीक़ा शुरू से दोहराना नहीं बल्कि 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 में अलग रखा गया है, जबकि बाकी चार में वे बीटा सुविधाएँ हैं जो ठीक उन्हीं पैटर्न की जगह लेने के लिए बनी हैं जिन्हें ब्रेकिंग चेंज मना करते हैं।

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.1 और Opus 5.5 हमेशा सोचते हैं (बंद नहीं हो सकता), Sonnet 5.5 पर thinking डिफ़ॉल्ट रूप से चालू है और disabled पर 400 आता है, पर between_tools से सिर्फ़ शुरुआती thinking बंद होती है (effort high या उससे नीचे), Legacy मॉडल Opus 5 और Sonnet 5 पर thinking डिफ़ॉल्ट रूप से चालू है (Opus 5 पर बंद करना सिर्फ़ effort high या उससे नीचे पर संभव), Opus 4.8 / 4.7 पर explicit adaptive सेट करना पड़ता है, और Haiku 4.5 / Sonnet 4.5 जैसे सिर्फ़ extended thinking वाले मॉडल आज भी budget_tokens को ही एकमात्र mode के रूप में इस्तेमाल करते हैं। गहराई का नियंत्रण अब output_config: {"effort": ...} के पाँच स्तरों (ज़्यादातर मॉडलों पर डिफ़ॉल्ट high, Opus 5.5 और Haiku 5.5 पर medium) में है, और 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.5/5/4.8, Claude Code में /fast से toggle)। हर बात Anthropic के आधिकारिक Thinking, Extended thinking और Fast mode documentation पर आधारित है।