# बिना स्थानीय इंडेक्सर के AI एजेंट्स को बड़े repo का संदर्भ देना

Canonical source: https://maguyva.ai/hi/blog/large-repo-context-without-a-local-indexer

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Date: 2026-08-14 · Author: Maguyva Team

> अपने लैपटॉप पर स्थानीय इंडेक्सर चलाए बिना, क्लाउड से पूछे जा सकने वाले बड़े रिपॉज़िटरी के मैप के साथ कोडिंग एजेंट्स को कैसे दें।

बड़े रिपॉज़िटरी संदर्भ विंडो में फिट नहीं होते, और अगर आपने कभी लैपटॉप-आधारित इंडेक्सर को किसी वास्तविक monorepo पर चलाया है, तो आप जानते हैं कि यह वहाँ भी आराम से फिट नहीं होता — RAM बढ़ जाती है, पहला इंडेक्सिंग एक घंटे लेता है, और आपका एजेंट फिर भी अगला सत्र यह अनुमान लगाते हुए शुरू करता है कि कौन सी फ़ाइलें महत्वपूर्ण हैं।

सामान्य उत्तर है एडिटर के बगल में एक इंडेक्सर चलाना, और जो repo एक मशीन पर आराम से फिट होता है उसके लिए, यह एक अच्छा जवाब है। अगर आपका monorepo पहले से ही Cursor में तेज़ी से इंडेक्स होता है और वही एकमात्र जगह है जहाँ आपको मैप चाहिए, तो इस लेख में जोड़ने के लिए कुछ नहीं है — इसे छोड़ दें।

यह लेख दूसरे मामले के बारे में है — जब एक एजेंट को एक बड़े repo का उद्धृत करने योग्य मैप चाहिए, और आप उसे पाने के लिए स्थानीय इंडेक्सर नहीं चलाना चाहते।

## स्थानीय इंडेक्सर कब गलत टूल बन जाता है

एक स्थानीय इंडेक्स मानता है कि कोड उसी मशीन पर रहता है जो इसे पूछती है, और असली monorepo पैमाने पर, वह धारणा एक ही एडिटर के भीतर भी खिंचती है। repo केवल उससे बड़ा है जितना आप अपने लैपटॉप पर 'गर्म' रखना चाहते हैं: आप एक पैकेज में काम कर रहे हैं जबकि ब्लास्ट रेडियस तीन डायरेक्टरी दूर है, और उस दो-मिलियन-लाइन ट्री के लिए पहला ठंडा इंडेक्स कुछ ऐसा नहीं है जिसे आप दो बार गुज़रना चाहते हैं — चाहे आपकी अपनी मशीन पर हो, या उस CI रनर पर जिसने पहले कभी वह ट्री क्लोन नहीं किया। या एक टीममेट को आपके जैसे ही मैप पूछने में सक्षम होना चाहिए, बिना अपनी मशीन को उसी इंडेक्स से जूझने का इंतज़ार किए।

इनमें से कोई भी एक अच्छे एडिटर इंडेक्सर को छोड़ने का कारण नहीं है। यह एक होस्टेड मैप भी रखने का कारण है जिसे आपका कोई भी एजेंट MCP के ज़रिए पूछ सकता है।

और वह पैमाना समस्या 'चिपकाने के लिए बहुत सारी फ़ाइलें' से गहरी है। एक बड़े ट्री पर, दिलचस्प सवाल लगभग कभी 'मुझे यह फ़ाइल दिखाओ' नहीं होता — यह होता है कौन सी फ़ाइल, कौन सा सिंबल, कौन कॉल करता है, कौन सा टेस्ट। एक एजेंट जो `src/` सूचीबद्ध करके और पहले तीन परिणाम पढ़कर शुरू करता है, वह `apps/api` में हैंडलर और `packages/sdk` में जनरेट किए गए क्लाइंट को खुशी-खुशी मिस कर देगा। आपको जो चाहिए वह है पूरे ट्री से बनी पुनर्प्राप्ति, फिर रैंक की गई, फिर उद्धृत।

## 'बड़े repo का संदर्भ' का असल में क्या मतलब है

फ़ाइलों को प्रॉम्प्ट में डालना संदर्भ नहीं है — यह छोटे और खराब तरीके से किया गया ट्री का प्रतिलिपिकरण है। आपके एजेंट को वास्तव में जो चाहिए वह है सवाल पूछना और उद्धृत जवाब पाना: यह सिंबल कहाँ परिभाषित है और इसे कौन कॉल करता है, मैं जो मॉड्यूल बदलने वाला हूँ उस पर क्या निर्भर करता है, कौन सी टेस्ट फ़ाइलें इस व्यवहार को कवर करती हैं, और वह ट्री *अभी* कैसा दिखता है, पिछली तिमाही नहीं।

वे जवाब आपके repo से बने इंडेक्स से आने चाहिए, किसी और के repo के बारे में मॉडल की याददाश्त से नहीं, और वह इंडेक्स एजेंट की संदर्भ विंडो के बाहर कहीं रहना चाहिए। इस समस्या के लिए, यह आपके लैपटॉप के बाहर भी कहीं रहना चाहिए।

एक और चीज़ जो इंस्ट्रक्शन फ़ाइलें आपके लिए नहीं कर सकतीं: `CLAUDE.md` और `AGENTS.md` कन्वेंशन और व्यवहार के लिए सही जगह हैं, लेकिन वे दो-मिलियन-लाइन ट्री के लिए जीवित, रैंक की गई, उद्धरण योग्य मैप नहीं हैं। व्यवहार के लिए नियमों का उपयोग करें; तथ्यों के लिए repo इंटेलिजेंस का उपयोग करें।

## हम क्लाउड में मैप बनाते हैं, आप इसे किसी भी क्लाइंट से पूछते हैं

Maguyva एक रिमोट MCP कोडबेस संदर्भ परत है। आप GitHub कनेक्ट करते हैं, अपनी repo चुनते हैं, और चले जा सकते हैं जबकि क्लाउड पाइपलाइन ट्री को पार्स करती है, सिंबल और ग्राफ़ एज बनाती है, और रैंक किया गया मैप बनाए रखती है — कभी भी स्थानीय इंडेक्सर की ज़रूरत नहीं।

जब आप कोड पुश करते हैं, बदली हुई फ़ाइलें क्रमिक रूप से पार्स होती हैं, और ग्राफ़ व रैंकिंग परतें एक शेड्यूल पर फिर से बनाई जाती हैं: मुफ़्त योजना पर दैनिक, भुगतान योजनाओं पर प्रति घंटा। हर स्नैपशॉट टाइमस्टैम्प किया जाता है, ताकि आपका एजेंट बता सके कि यह ट्री का कौन सा संस्करण पढ़ रहा है। यहाँ ईमानदार सीमा असिंक्रोनाइज़्ड स्थानीय काम है — जो बदलाव केवल आपकी वर्किंग ट्री में मौजूद हैं, कभी पुश नहीं हुए, वे अभी तक होस्टेड मैप में नहीं हैं।

फिर आप उस क्लाइंट के MCP कॉन्फ़िग में एक API कुंजी जोड़कर, जिसे आप पहले से उपयोग करते हैं, कनेक्ट करते हैं। 24 दस्तावेज़ीकृत MCP क्लाइंट्स के लिए सेटअप गाइड मौजूद हैं, और कोई भी अन्य MCP-संगत क्लाइंट जो मानक कॉन्फ़िगरेशन का समर्थन करता है, वह भी कनेक्ट हो सकता है। अगर Cursor वह जगह है जहाँ आप रहते हैं, [Cursor पेज](/hi/for-cursor) उस पथ को नक्शा करता है; वही सर्वर Claude Code, VS Code, Windsurf, Codex CLI और बाकियों को जवाब देता है।

आप एडिटर नहीं बदल रहे। आप अपने एजेंट को एक टूल सतह दे रहे हैं — सर्च, सिंबल, dependency विश्लेषण, फ़ाइल पुनर्प्राप्ति और रिपॉज़िटरी संदर्भ में 11 MCP टूल — जो 279 से अधिक भाषाओं और टेक्स्ट-आधारित तकनीकों को कवर करता है, जिसका मतलब है उससे कहीं ज़्यादा जितना आपने उस monorepo पर सोचा था जो बहुत पहले एक-भाषा होना बंद कर चुका है।

जवाब आधारित होकर वापस आते हैं, फ़ाइल पथों के रूप में लाइन नंबरों के साथ। Semantic, structural, graph, और text सर्च एक रैंक किए गए परिणाम में मिल जाते हैं, ताकि 'parseConfig पर क्या निर्भर करता है' जैसे सवाल आपको केवल grep का ढेर या एक ही semantic उद्धरण न दें, बल्कि उन कुछ जगहों को दें जो वास्तव में मायने रखती हैं।

## एक ठोस गाइड

पूरी कंपनी को इंडेक्स करके शुरू न करें। यह वह पथ है जो काम करता है:

1. एक ऐसी repo चुनें जिसे आप पहले से अच्छी तरह जानते हैं — एक पैकेज जिसे आप मैन्युअल रूप से आंक सकते हैं, वह आपके पास मौजूद सबसे बड़े ट्री से ज़्यादा मूल्यवान है।
2. मुफ़्त में शुरू करें: 3 रिपो, 50 हज़ार इंडेक्स की गई लाइनें, सभी 11 टूल, कोई मासिक क्वेरी कोटा नहीं। अगर आपका प्रतिनिधि repo बड़ा है, तो [मूल्य निर्धारण पेज](/hi/pricing) इंडेक्स की गई कवरेज के अनुसार वर्कस्पेस स्तर ($0, $19, $49, $149) सूचीबद्ध करता है — सीट गिनती के अनुसार नहीं।
3. GitHub कनेक्ट करें और पहले इंडेक्सिंग के पूरा होने का इंतज़ार करें। आप स्थानीय रूप से कुछ भी संकलित नहीं कर रहे हैं।
4. अपना MCP क्लाइंट कनेक्ट करें — कुछ कॉन्फ़िग लाइनें। Maguyva एक रिमोट MCP सर्वर है, इसलिए कोई प्लगइन नहीं, कोई एक्सटेंशन नहीं, और कोई दूसरा एडिटर नहीं अपनाना है।
5. एक सवाल पूछें जिसे आप सत्यापित कर सकते हैं। 'parseConfig पर क्या निर्भर करता है?' या 'लॉगिन सत्र समाप्ति कहाँ संभाली जाती है?' फिर उद्धृत `file.ext:line` परिणाम खोलें और अपने सामने के ट्री से जाँचें।
6. उस उद्धरण के संपर्क में टिके रहने के बाद ही, आप एजेंट को संपादित करने देते हैं।

अगर पहली repo अच्छी तरह फिट बैठती है और आपकी ट्री बड़ी है, तो अपनी इंडेक्स की गई लाइनों और पुनर्निर्माण दर के अनुसार वर्कस्पेस को बढ़ाएँ। मनुष्य और एजेंट एक ही उपयोगकर्ता गिनती साझा करते हैं — Maguyva सीट्स के बजाय प्रति वर्कस्पेस चार्ज करता है — इसलिए लूप में तीसरा एजेंट जोड़ने से आपको कुछ अतिरिक्त नहीं मिलता।

एक्टिवेशन टेस्ट किसी भी पहली रन के लिए [दस्तावेज़ीकरण](/hi/docs) की सिफारिश के समान है: उस repo को इंडेक्स करें जिसे आप पहले से जानते हैं, एक सवाल पूछें जिसे आप सत्यापित कर सकते हैं। बड़ा repo उस टेस्ट को नहीं बदलता; यह केवल पहली ग़लत फ़ाइल को अधिक महंगा बनाता है।

## कनेक्ट होने के बाद क्या देखें

तीन चीज़ों पर नज़र रखें। ताज़गी: भुगतान योजनाएँ प्रति घंटा फिर से बनती हैं, मुफ़्त योजना दैनिक, और वह स्थानीय काम जो पुश नहीं हुआ वह मैप में नहीं होगा — यही व्यापार है जो आप स्वीकार कर रहे हैं। स्कोप: उन रिपो के प्रतिनिधि सेट को इंडेक्स करें, हर आर्काइव किए गए फ़ोर्क को नहीं; मुफ़्त स्तर जानबूझकर इतना बड़ा बनाया गया है कि यह जानने के लिए कि जवाब रखने लायक हैं या नहीं। और सत्यापन: एक बड़े repo का मैप जो पथ और लाइन नंबर उद्धृत नहीं कर सकता, वह केवल एक धीमा अनुमान इंजन है, इसलिए अपने एजेंट को पैच भेजने से पहले स्थान दिखाने के लिए कहें।

फिर वही टेस्ट चलाएँ जो आप एक छोटे repo पर चलाते। उस repo को इंडेक्स करें जिसे आप पहले से जानते हैं। एक सवाल पूछें जिसे आप सत्यापित कर सकते हैं। अगर मैप सही है, तो आपका एजेंट ठंडे ट्री से शुरू करना बंद कर देता है।

`// no laptop got hot building this map.`