AI डेवलपमेंट और प्रोग्रामिंग

Claude Code में "Claude usage limit reached" कोई एरर नहीं, बल्कि Pro/Max सब्सक्रिप्शन उपयोग सीमा का तरीका है। सीमा दो-स्तरीय है: एक रोलिंग 5-घंटे विंडो और एक साप्ताहिक विंडो, और Max में Opus के लिए एक अलग साप्ताहिक कैप भी। यह लेख समझाता है कि कोटा किससे जलता है (सबसे बड़ा कारक मॉडल पसंद है), सीमा से टकराते ही क्या करें, बचा हुआ कोटा कैसे देखें, और सब्सक्रिप्शन बनाम API सीमा में क्या फ़र्क है।

Claude Code या API का "Prompt is too long" एरर बताता है कि आपका इनपुट (बातचीत का इतिहास + फाइलें + टूल डेफिनिशन) मॉडल की कॉन्टेक्स्ट विंडो को पार कर गया है — यह usage limit या max_tokens कटऑफ नहीं है। यह लेख समझाता है कि विंडो को क्या भरता है, 200K और 1M विंडो साइज़ का फर्क, /compact, /clear और subagent से तुरंत कैसे ठीक करें, और इसे भ्रामक एरर से कैसे अलग पहचानें।

Claude Code में MCP सर्वर कनेक्ट न होने की समस्या तीन परिवारों में बँटती है: लोकल सबप्रोसेस लॉन्च फेल्योर, रिमोट ऑथेंटिकेशन, और कॉन्फ़िग फ़ाइल की गलतियाँ। यह लेख बताता है कि /mcp का स्टेटस कैसे पढ़ें, कारण-दर-कारण उपाय, सबसे आम Windows npx जाल का हल, और claude --debug mcp के साथ डायग्नोस्टिक वर्कफ़्लो।

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

किसी विशाल AI को शुरू से दोबारा ट्रेन करना बहुत महँगा है, पर आप इसे बस अपने लिए थोड़ा बदलना चाहते हैं; LoRA (Low-Rank Adaptation) मूल मॉडल को फ्रीज़ करके और सिर्फ़ एक छोटे adapter को ट्रेन करके यह इच्छा पूरी करती है, जिससे ट्रेन होने वाले parameters लगभग 90% घट जाते हैं। LoRA fine-tuning को नाटकीय रूप से सस्ता और तेज़ बनाती है, और Stable Diffusion जैसी इमेज जनरेशन में किरदार या स्टाइल जोड़ने वाली छोटी फ़ाइल के रूप में बेहद लोकप्रिय है। यह लेख इसे एक पैच की उपमा से समझाता है। LoRA, parameter-efficient fine-tuning (PEFT) की अग्रणी तकनीक है: विशाल मूल weights को frozen रखें, हर लेयर में एक छोटा matrix डालें, और सिर्फ़ उसी को ट्रेन करें (W = W0 + BA)। फ़ायदे: ~90% कम params (GPT-3 पैमाने पर 10,000x कम), कम GPU मेमोरी (~3x कम), तेज़ व सस्ती ट्रेनिंग, merge के बाद कोई inference latency नहीं, और कम overfitting। इसकी सबसे बड़ी ताक़त बदलने योग्य adapters हैं: एक साझा बेस रखें और हर उपयोग के लिए few-MB LoRA फ़ाइलें तुरंत बदलें। QLoRA, quantization को मिलाकर 4-bit बेस पर LoRA ट्रेन करती है, मानक LoRA से ~4x कम मेमोरी में, जिससे उपभोक्ता GPU पर भी विशाल मॉडल fine-tune होते हैं। बनाम full fine-tuning, LoRA अक्सर काफ़ी होती है। बेस बनाए रखें, उसे छोटे पैमाने पर स्वाद दें।

एक विशाल 70B model डेटा-सेंटर के GPU rack के बजाय घर के एक gaming PC पर चल सके, यह 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 सुरक्षित रखता है, अक्सर 1-2% अधिक सटीक और तेज़), 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 के प्रदर्शन का 95%+ उसके दसवें हिस्से के आकार और गति पर बनाए रखता है। यह लेख इसे teacher-student की उपमा से समझाता है। कुंजी soft labels हैं: साधारण प्रशिक्षण केवल "उत्तर बिल्ली है" सिखाता है (hard label), जबकि distillation teacher का पूरा संभाव्यता वितरण जैसे "90% बिल्ली, 8% कुत्ता, 2% लोमड़ी" सौंपता है, जिसकी झिझक की मात्रा समृद्ध जानकारी रखती है; एक temperature पैरामीटर संभावनाओं को नरम कर सूक्ष्म संबंध उजागर करता है (वास्तविक उदाहरण: GPT-4o mini, GPT-4o से distilled)। फायदे: तेज़ और सस्ता, ~10x ज़्यादा कॉम्पैक्ट, 95%+ प्रदर्शन बनाए रखते हुए, 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, Mistral और 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-चिह्नित काम पर responses सीमित करते हैं। सुझाव: 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 क्या है?" में अवधारणा समझने के बाद, यह व्यावहारिक अगला कदम है। 2026 के वास्तविक मानक supervisor pattern से शुरुआती लोगों को 5-चरण में बनाना सिखाता है। मुख्य सिद्धांत: पहले एकल agent बनाएँ और सीमा से टकराने पर ही न्यूनतम स्तर पर agents जोड़ें (लगभग 80% उपयोग एक से चल जाते हैं; सीधे-सादे काम में multi से लागत 3-10x बढ़ती है और Google शोध के अनुसार क्रमिक कार्यों में सटीकता −39-70% गिरती है)। multi अपनाने के 3 संकेत: विशेषज्ञता विभाजन, समानांतरता, निर्णय पृथक्करण। supervisor pattern (supervisor पूरा कार्य लेता है, बाँटता है, workers को सौंपता है, परिणाम जोड़ता है) पर Claude Code subagents, LangGraph Supervisor और OpenAI Agents SDK handoffs सभी मिल गए हैं — व्यापक framework समर्थन, ज्ञात failure mode और आसान audit के कारण। 5 चरण: 1) कार्य साफ़-साफ़ विभाजित करें; 2) एक भूमिका + tools + output format वाले workers (अधिकतम 3-5); 3) supervisor डिज़ाइन करें, बुलाने योग्य नाम सूचीबद्ध करें (hard cap); 4) handoff और context साझाकरण तय करें, केवल ज़रूरी सौंपें (मानक A2A); 5) agents जोड़ने से पहले हर handoff मापें, सीमाएँ लगाएँ, evals और guardrails तैयार करें। छद्म-कोड workers, hard-capped supervisor और iteration-bounded loop दिखाता है। आम गलतियाँ और समाधान: over-delegation, token का फूलना, अस्थिरता, सटीकता गिरना, अज्ञात विफलता-बिंदु। साझा सबक: सफलता framework से ज़्यादा prompts, tools और eval harness तय करते हैं। छोटा बनाएँ, मापें, तभी जोड़ें जब फ़ायदेमंद हो।

"एक AI agent जिस जटिल काम को अकेले नहीं संभाल सकता, उसे कई agents में बाँट देना" — यही multi-agent systems की सोच है। यह शुरुआती-अनुकूल गाइड इसकी कार्यप्रणाली, मुख्य पैटर्न और प्रमुख frameworks बताती है, और सबसे ज़रूरी बात, बिना अतिशयोक्ति के असली निर्णय-नियम कि कब कई agents इस्तेमाल करें और कब एक ही काफी है। एक multi-agent system में अलग-अलग भूमिकाओं वाले कई AI एक बड़े काम पर मिलकर काम करते हैं; सब कुछ अकेले करने वाले single agent (जो ~80% use cases के लिए ठीक, सस्ता और debug में आसान है) के मुकाबले यह काम को विशेषज्ञता से बाँटता है ताकि समानांतर निष्पादन और आपसी जाँच हो सके, पर coordination लागत और token खपत ज़्यादा होती है। चार प्रमुख orchestration पैटर्न हैं: orchestrator-worker (लीड बाँटता, workers को समानांतर भेजता, और जोड़ता है; सबसे प्रचलित, audit trail के साथ), sequential handoff (संदर्भ अगले agent को सौंपना), group conversation (agents एक thread में बहस करते हैं, selector तय करता है कौन बोले; सत्यापन के लिए अच्छा), और graph state machine (agents nodes, transitions edges, स्पष्ट state; branching और checkpoints में मज़बूत)। Frameworks 2026 में LangGraph (सबसे बड़ा production आधार), CrewAI (सबसे कम सीखने की मेहनत, prototyping), AutoGen/AG2 (बहस और सत्यापन, रिसर्च), और OpenAI Swarm (हल्के handoffs) में सिमट गए। पर यह रामबाण नहीं: जटिल बहु-क्षेत्रीय कामों पर reasoning benchmarks में +23% तक, फिर भी एक-रास्ते sequential कामों पर Google रिसर्च में single agent बनाम -39-70%, एक agent को वही compute दें तो वह अक्सर बराबरी या बढ़त लेता है, और 10 में से 7 deployments में ~15x token खपत पर बिना ROI लागत बढ़ी (औसत ROI 2.5-3.5x, सही निशाने पर शीर्ष चौथाई 4-6x)। अनुशंसित रास्ता: पहले single बनाएँ, एक ठोस छत पहचानें (धुँधली भूमिकाएँ, समानांतर होने योग्य काम), फिर cost cap और logging के साथ न्यूनतम 2-3 agent लीड-पैटर्न टीम जोड़ें, और मापें कि सटीकता में बढ़त वृद्धि को सही ठहराती है या नहीं। A2A (communication protocol) और MCP (tool connection) multi-agent को सहारा देने वाली बुनियादी तकनीक हैं। 80% के लिए single, सिर्फ़ कठिन हिस्सों के लिए multi। आँकड़े सर्वेक्षणों और रिसर्च से लिए गए, परिस्थिति-निर्भर और दिशासूचक हैं।

अब जब 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+ संगठन production में, 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 जोड़ने से करीब 40% RAG सटीकता सुधार की रिपोर्ट करते हैं, और इसे 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 से ट्यून करें।