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

Claude Code में "You've hit your session limit · resets 3:45pm" कोई एरर नहीं, बल्कि सब्सक्रिप्शन उपयोग सीमा का तरीका है। आधिकारिक संदर्भ में चार रूप हैं: session (रोलिंग 5-घंटे विंडो), weekly (साप्ताहिक विंडो), और Opus व Sonnet (सिर्फ़ एक मॉडल परिवार के कैप); चूँकि सेशन और साप्ताहिक सीमा सभी मॉडलों में साझा हैं, मॉडल बदलने से एक्सेस वापस नहीं आता। यह लेख समझाता है कि हर संदेश का क्या मतलब है और पुराने "Claude usage limit reached" से पाठ कैसे बदला, कोटा किससे जलता है, और सीमा से टकराते ही क्या करें: Opus/Sonnet कैप पर /model से मॉडल बदलें, रीसेट का इंतज़ार करें (v2.1.234 से अपने-आप), /usage-credits से उपयोग क्रेडिट लें या pay-as-you-go API पर जाएँ। साथ ही /usage से बचा कोटा कैसे देखें और कौन-से मिलते-जुलते संदेश आपकी सीमा नहीं हैं।

Claude Code में "Prompt is too long" तब दिखता है जब इतिहास, फ़ाइलों और टूल के परिणामों सहित कुल इनपुट कॉन्टेक्स्ट सीमा से बड़ा हो जाता है। यह लेख लंबे इतिहास को संक्षिप्त करने, पहले बड़े इनपुट को घटाने और प्रमाणीकरण त्रुटि जैसे संक्षेपण की विफलता के मूल कारण को ठीक करने के बीच अंतर बताता है। MCP डेफ़िनिशन डिफ़ॉल्ट रूप से ज़रूरत पड़ने पर लोड होती हैं और 1M की उपलब्धता मॉडल, कनेक्शन और प्लान पर निर्भर करती है। सीधे API उपयोग में टोकन गिनने और जवाब रुकने के कारण भी समझाए गए हैं।

Claude Code में MCP सर्वर कनेक्ट न हो तो स्टेटस, कनेक्शन का तरीका और Issue का विवरण साथ देखें। failed सिर्फ stdio स्टार्टअप विफलता नहीं, HTTP संचार विफलता या तय प्रमाणीकरण हेडर का अस्वीकार होना भी दिखा सकता है। यह लेख Connection closed का अर्थ, एनवायरनमेंट वेरिएबल और अपरिभाषित संदर्भ, प्रोजेक्ट कॉन्फ़िगरेशन और स्वीकृति, Windows में npx का स्टार्टअप, डिबग लॉग और दोबारा कनेक्ट करने के बाद आवश्यक ऑपरेशन की जाँच समझाता है। शून्य टूल होना हमेशा त्रुटि नहीं है और सर्वर का अलग से शुरू होना सफल MCP कनेक्शन की गारंटी नहीं देता।

Claude Code में कभी-कभी एक tool call कच्चे टेक्स्ट के रूप में लीक हो जाता है — सबसे आगे एक बेमतलब शब्द "court" या "call" के साथ — और कमांड कभी एक्जीक्यूट नहीं होती। यह आपके एनवायरनमेंट की गलती नहीं, बल्कि एक मॉडल-साइड गड़बड़ी है जिसमें Claude (Opus 4.8 / 4.7 परिवार) tool call के कंट्रोल टोकन को टूटे रूप में जनरेट कर देता है। हार्नेस उसे fail-closed तरीके से खारिज करता है, इसलिए गलत कमांड चलने का कोई खतरा नहीं; असली खतरा है स्व-विषाक्तता से बनने वाली "चेन"। यह लेख तंत्र, दो मूल कारण, आम गलतफहमियाँ, उपयोगकर्ता/डेवलपर समाधान, मिलती-जुलती त्रुटियों से फर्क, और आधिकारिक स्थिति को Anthropic के दस्तावेज़ों और असली issues के आधार पर समझाता है।

ChatGPT या Claude का account बिना बुरी नीयत के भी रुक सकता है, और दूसरे account से लौटना हालात बिगाड़ता है। हमने 4 अक्टूबर 2026 तक OpenAI (ChatGPT, Codex) और Anthropic (Claude, Claude Code) की शर्तें — Terms of Use, Usage Policies, Consumer Terms और Usage Policy — और उनके help center पूरे पढ़े और बताया: हर कंपनी के आधिकारिक रोक के कारण; हर मामले की शर्त के साथ क्या न करें (account साझा करना, interface को script से चलाना, jailbreak, ban से बचना, असमर्थित देश से VPN के ज़रिए Claude, distillation, दोबारा बेचना, बड़ी संख्या में account बनाना); personal plan का login दूसरे tools में इस्तेमाल करने पर Anthropic की भाषा फ़रवरी 2026 और अब में कैसे बदली (ख़ुद Agent SDK चलाना अपेक्षित है, token किसी और की service को देना मना है); उल्लंघन न होने पर भी आने वाली चेतावनियाँ और जाँच; कई accounts के स्वामित्व और इस्तेमाल का अंतर (9 अक्टूबर का अपडेट: OpenAI का आधिकारिक switcher, Anthropic की phone-verification सीमा, usage limit के बाद manual switching पर ख़ास जवाब की ज़रूरत और साझा करने, दोबारा बेचने व ban से बचने से इसका अंतर); आठ बातों की checklist; और appeal के steps (OpenAI: email का link या openai.com/form/appeal; Anthropic: ban हुए account से claude.ai पर login; चेतावनी: usersafety@anthropic.com)।

किसी विशाल AI को शुरू से दोबारा ट्रेन करना बहुत महँगा है, पर आप इसे बस अपने लिए थोड़ा बदलना चाहते हैं; LoRA (Low-Rank Adaptation) मूल मॉडल को फ्रीज़ करके और सिर्फ़ एक छोटे adapter को ट्रेन करके यह इच्छा पूरी करती है, जिससे ट्रेन होने वाले parameters मूल मॉडल के 1% से भी कम रह जाते हैं। LoRA fine-tuning को नाटकीय रूप से सस्ता और तेज़ बनाती है, और Stable Diffusion जैसी इमेज जनरेशन में किरदार या स्टाइल जोड़ने वाली छोटी फ़ाइल के रूप में बेहद लोकप्रिय है। यह लेख इसे एक पैच की उपमा से समझाता है। LoRA, parameter-efficient fine-tuning (PEFT) की अग्रणी तकनीक है: विशाल मूल weights को frozen रखें, हर लेयर में एक छोटा matrix डालें, और सिर्फ़ उसी को ट्रेन करें (W = W0 + BA)। इसका आधार यह परिकल्पना है कि low rank काफ़ी है, जिसकी पुष्टि मूल paper के प्रयोगों ने की (हालाँकि गणित और प्रोग्रामिंग में यह पूरी ट्रेनिंग से पीछे रहती है, ऐसी रिपोर्ट भी है)। फ़ायदे: params मूल के 1% से कम (मूल paper के GPT-3 175B में लगभग 10,000 में 1), ट्रेनिंग के दौरान कम GPU मेमोरी (उसी प्रयोग में 1.2TB → 350GB), तेज़ व सस्ती ट्रेनिंग, merge के बाद कोई inference latency नहीं, और मूल क्षमताएँ कम भूलना। इसकी सबसे बड़ी ताक़त बदलने योग्य adapters हैं: एक साझा बेस रखें और हर उपयोग के लिए छोटी LoRA फ़ाइलें तुरंत बदलें। QLoRA, quantization को मिलाकर 4-bit बेस पर LoRA ट्रेन करती है: 16-bit में पूरी ट्रेनिंग के लिए 780GB से ज़्यादा माँगने वाला 65B मॉडल 48GB के एक GPU पर, और 33B मॉडल 24GB के उपभोक्ता GPU पर fine-tune होता है; paper की तुलना में नतीजे 16-bit तरीक़ों के बराबर रहे (33B और 65B पर पूरी ट्रेनिंग की बराबरी जाँची नहीं गई, यह paper ख़ुद कहता है)। बनाम full fine-tuning, LoRA अक्सर काफ़ी होती है। बेस बनाए रखें, उसे छोटे पैमाने पर स्वाद दें। आँकड़े मूल paper आदि की प्रयोग-शर्तों के हैं, केवल दिशा-सूचक।

एक विशाल 70B model डेटा-सेंटर के GPU rack के बजाय घर के एक PC पर चल सके (consumer GPU में जो हिस्सा न समाए, उसे CPU और main memory संभालें), यह quantization से संभव होता है, जो model के weights की numerical precision घटाकर आकार और memory नाटकीय रूप से कम करता है। जहाँ model distillation ज्ञान को एक अलग छोटे model में ले जाती है, वहीं quantization उसी model को हल्का बनाता है। यह लेख इसे फोटो-compression की उपमा से समझाता है। quantization, FP16/FP32 दशमलव के रूप में संग्रहित weights को INT8 (8-bit) या INT4 (4-bit) integers से बदलता है, प्रति weight bytes घटाते हुए (FP32=4, INT8=1, INT4=0.5); RAW फोटो को JPEG में compress करने जैसा, आप थोड़ी precision की कुर्बानी देकर बड़ी कमी पाते हैं, और हैरानी इस बात की है कि आप कितना कम खोते हैं। memory पर, 4-bit, FP16 की लगभग एक-चौथाई लेता है: एक 70B model ~140GB से ~35GB तक गिरता है, और एक 8B model 4-bit पर ~4.5-5GB का होता है, जो midrange 8GB-VRAM GPU में लोकल उपयोग के लिए समाता है (LLMs का लोकतंत्रीकरण)। accuracy पर, INT8 लगभग बिना नुकसान है और INT4 सामान्य Q&A/सामान्य-ज्ञान tasks पर कथित तौर पर 4% से कम घटता है, पर गणित, code generation और कठिन reasoning के लिए नुकसान ज़्यादा साफ़ दिखता है (यह perplexity में थोड़ी वृद्धि के रूप में दिखता है), इसलिए task के लिए bit-width चुनें। मुख्य तरीके: GPTQ (सटीक 4-bit का अग्रदूत), AWQ (सबसे महत्वपूर्ण ~1% weights सुरक्षित रखता है; GPTQ से बेहतर है या नहीं, यह मूल्यांकन पर निर्भर), GGUF (llama.cpp/Ollama format, Q2_K-Q8_0, CPU+GPU hybrid, लोकल के लिए), और QLoRA (4-bit base साथ LoRA, consumer-GPU fine-tuning के लिए)। यह distillation (एक अलग छोटे model में जाना) और fine-tuning (task ज्ञान जोड़ना) से अलग है, और तीनों आमतौर पर मिलाए जाते हैं (एक distilled model को quantize करें; एक quantized base को fine-tune करें)। शुरू करने के लिए, एक command में Ollama के साथ एक GGUF model चलाएँ, VRAM के अनुसार Q4/Q8 चुनें, और code या सटीक गणित के लिए INT4 से बचें। अधिकांश प्रमुख model पहले से quantized आते हैं, इसलिए आप बस उन्हें download करके इस्तेमाल करते हैं। समझदारी बनाए रखें, सिर्फ़ वज़न घटाएँ। आँकड़े सार्वजनिक सामग्री से उद्धृत, दिशा-सूचक।

एक विशाल, उच्च-प्रदर्शन वाली AI स्मार्ट तो है पर भारी और महंगी; model distillation (knowledge distillation) इसे एक बड़े teacher model का ज्ञान छोटे student model में स्थानांतरित करके हल करता है, और कहीं छोटे आकार व ज़्यादा गति पर teacher के क़रीब का प्रदर्शन बनाए रखता है। यह लेख इसे teacher-student की उपमा से समझाता है। कुंजी soft labels हैं: साधारण प्रशिक्षण केवल "उत्तर बिल्ली है" सिखाता है (hard label), जबकि distillation teacher का पूरा संभाव्यता वितरण जैसे "90% बिल्ली, 8% कुत्ता, 2% लोमड़ी" सौंपता है, जिसकी झिझक की मात्रा समृद्ध जानकारी रखती है; एक temperature पैरामीटर संभावनाओं को नरम कर सूक्ष्म संबंध उजागर करता है (वास्तविक उदाहरण: बड़े models के आउटपुट से छोटे models को प्रशिक्षित करने वाली OpenAI की 2024 की API सुविधा)। फायदे: तेज़ और सस्ता, कहीं ज़्यादा कॉम्पैक्ट, teacher के क़रीब का प्रदर्शन (TinyBERT: 7.5 गुना छोटा, 96.8% से अधिक), edge पर चलता है, विशेषीकरण में मज़बूत। दो तरीके: white-box (weights और आंतरिक प्रतिनिधित्वों तक पूरी पहुँच, गहरा स्थानांतरण; अपने या OSS models के लिए) और black-box (केवल आउटपुट/API responses दिखते हैं; किसी दूसरी कंपनी की API को teacher बनाना terms का उल्लंघन कर सकता है)। यह quantization (उसी model की weight precision संपीड़ित करना) और fine-tuning (मौजूदा model को किसी task के लिए आगे प्रशिक्षित करना) से अलग है — distillation ज्ञान को एक अलग छोटे model में ले जाता है, और तीनों को मिलाया जा सकता है। कानूनी/ToS हकीकत 2026 का बड़ा मुद्दा था: तकनीक वैध है, पर OpenAI, Anthropic और xAI में anti-competitive distillation खंड हैं जो आउटपुट का उपयोग प्रतिस्पर्धी models बनाने के लिए करना प्रतिबंधित करते हैं, इसलिए किसी प्रतिबंधित API से प्रतिस्पर्धी distill करना terms का उल्लंघन कर सकता है। OpenAI बनाम DeepSeek विवाद (OpenAI ने आरोप लगाया कि DeepSeek से जुड़ी accounts ने प्रतिबंध दरकिनार कर distillation के लिए आउटपुट हासिल किए, जबकि DeepSeek की terms कथित तौर पर अपने आउटपुट distill करने की अनुमति देती हैं) दिखाता है कि आकलन इस पर निर्भर है कि किसकी API terms लागू होती हैं, और Claude Fable 5/Mythos 5 distillation-चिह्नित requests को कम सक्षम Opus model पर भेज देते हैं। सुझाव: teacher के रूप में अपना या लाइसेंस प्राप्त OSS model इस्तेमाल करें, commercial API इस्तेमाल करने से पहले anti-distillation खंड जाँचें, और तय करें कि उपयोग "प्रतिस्पर्धी model विकसित करना" तो नहीं है। स्मार्टनेस बड़े model से, संचालन छोटे से — पर आप teacher किसे चुनते हैं यह तकनीकी और कानूनी रूप से परिणाम बदल देता है। आँकड़े सार्वजनिक सामग्री से उद्धृत, दिशात्मक।

AI observability वह तकनीक है जो दिखाती है कि production में आपके LLMs और agents असल में क्या करते हैं — कौन-सा model, कौन-से tools व searches, क्या लौटाया, और कितना समय व लागत — ताकि कुछ टूटने पर आप कारण तक पीछे जा सकें। सामान्य app monitoring से निर्णायक अंतर: AI 50ms में 200 OK लौटा सकता है और फिर भी आत्मविश्वास से hallucinate कर सकता है, इसलिए अधिकांश AI विफलताएँ infrastructure नहीं, गुणवत्ता विफलताएँ हैं। तीन स्तंभ: traces, metrics, logs. उद्योग मानक OpenTelemetry GenAI conventions इन्हें vendor-neutral schema में संभालते हैं। यह लेख observability बनाम evals का अंतर, देखने योग्य metrics, और प्रमुख tools (LangSmith/Langfuse/Phoenix/MLflow/AgentOps/OpenTelemetry) समझाता है।

"Multi-agent system क्या है?" के बाद का व्यावहारिक भाग। मूल नियम: पहले एक agent से बनाएँ और सीमा से टकराने पर ही न्यूनतम रूप में agents जोड़ें (Google Research के अध्ययन में सख़्ती से क्रमवार काम पर सभी multi-agent setups 39–70% ख़राब रहे, और Anthropic के अनुसार multi-agent systems एक chat से लगभग 15 गुना tokens इस्तेमाल करते हैं)। आधार ढाँचा supervisor pattern है: Claude Agent SDK में subagents, OpenAI Agents SDK में agents as tools। 5 चरणों (विभाजन, workers परिभाषित करना, supervisor डिज़ाइन, handoff, मापना) के अलावा, दोनों SDK के आधिकारिक दस्तावेज़ों पर आधारित न्यूनतम कोड (एक supervisor के साथ researcher और reviewer), हर भूमिका के tools सीमित करने का तरीका, तीन परतों की सीमाएँ (maxTurns, max_turns, ख़र्च), handoff कब चुनें, भूमिकाओं का अच्छा और बुरा बँटवारा, और Anthropic की असली विफलताएँ (सरल सवाल पर 50 subagents, दोहराई गई research) उनके समाधान के साथ।

अब जब AI एजेंट आम हो चुके हैं, अगली चुनौती है एजेंट्स को आपस में कैसे सहयोग करवाया जाए। अगर MCP किसी एजेंट को उसके tools से जोड़ता है, तो A2A (Agent2Agent) एक एजेंट को दूसरे एजेंट से जोड़ता है — एक open standard जिससे अलग-अलग vendors और frameworks पर बने AIs एक साझा परंपरा के ज़रिए खोज, संवाद और सहयोग कर सकें। Google ने इसे अप्रैल 2025 में रिलीज़ किया, उसी जून में Linux Foundation को दान किया, और 2026 में यह v1.0 तक पहुँचा। यह शुरुआती गाइड बताती है कि A2A क्या है (कंपनियों की व्यापारिक साझेदारी के शिष्टाचार जैसा), यह क्यों ज़रूरी है (विशेषज्ञ एजेंट काम को रिले करते हैं — एक planning एजेंट से hotel-booking एजेंट से payment एजेंट तक), MCP से इसका अंतर (MCP vertical है, agent ↔ tools; A2A horizontal है, agent ↔ agent; दोनों को एक साथ लगाना ही standard दो-स्तरीय सेटअप है), यह कैसे काम करता है (एक Agent Card — /.well-known/agent-card.json पर रखा एक JSON "विज़िटिंग कार्ड" — से क्षमताएँ discover होती हैं, फिर एक Task working, input-required, completed जैसी states के साथ request ले जाता है, और एक Artifact result लौटाता है, यह सब HTTP, Server-Sent Events, और JSON-RPC 2.0 पर होता है, जबकि एजेंट अपने आंतरिक हिस्से छिपे रखते हैं), तथा इसकी वर्तमान स्थिति और implementation (अप्रैल 2026 तक, 150+ समर्थक संगठन, 22,000+ GitHub stars, पाँच भाषाओं में SDKs — Python, JavaScript, Java, Go, .NET — और Microsoft, Salesforce, SAP, ServiceNow शामिल)। याद रखने का तरीका: tools से जुड़ना = MCP, peers से जुड़ना = A2A।

आपने RAG तो बना लिया, पर search की क्वालिटी औसत है — ठीक यहीं reranking काम आती है। Reranking, embedding (vector) search से मोटे तौर पर जुटाए गए candidates को query से उनकी relevance के आधार पर फिर से score करती है और उन्हें फिर से क्रम में लगाकर सिर्फ़ टॉप वाले रखती है; यह एक कदम किसी RAG सिस्टम के जवाब की क्वालिटी को नाटकीय रूप से बदल सकता है। यह शुरुआती गाइड बताती है कि reranking क्या है (पहली-छँटाई-और-आख़िरी-इंटरव्यू वाली उपमा), यह क्यों ज़रूरी है (embedding search query और दस्तावेज़ों को अलग-अलग vector में बदलता है, इसलिए relevance को सिर्फ़ मोटे तौर पर आँकता है, और ख़राब क्रम सीधे जवाब की क्वालिटी घटाता है — शोध दिखाते हैं कि reranking retrieval की सटीकता काफ़ी बढ़ा सकती है, और इसे hybrid search पर चढ़ाना 2026 का मानक है), two-stage retrieval कैसे काम करती है (recall के लिए तेज़ embedding search से "व्यापक रूप से जुटाएँ," फिर precision के लिए reranker से "समझदारी से छाँटें," फिर टॉप को LLM को सौंपें), reranker ज़्यादा सटीक क्यों है (bi-encoder query और दस्तावेज़ को अलग-अलग vector में बदलता है, तेज़ पर अनुमानित; cross-encoder उन्हें एक साथ feed करके 0–1 relevance score देता है, सटीक पर भारी — इसलिए तेज़ bi-encoder से जुटाएँ और सटीक cross-encoder से छाँटें), और मॉडल व implementation (API प्रकार जैसे Cohere Rerank, Voyage, Jina; open-source जैसे BGE reranker, mixedbread, FlashRank; और LLM-आधारित scoring जैसे RankLLM — बस 50–100 retrieve करें और टॉप 5 तक छाँटें)। सिद्धांत: व्यापक रूप से जुटाएँ, समझदारी से छाँटें, और संख्याओं को AI evals से ट्यून करें।