पहली बार जब आपने किसी नई मशीन पर octocode index चलाया, तो आपको एक कॉन्फ़िग एरर मिली। जरूरी: एक Voyage API key। उन टीमों के लिए ठीक है जिनके पास पहले से है — पहली बार Octocode आज़माने वाले हर किसी के लिए परेशानी।

0.15.0 इसे ठीक करता है। उपयोगी और तेज़ इंडेक्स पाने के लिए किसी API key की जरूरत नहीं। हाइब्रिड सर्च और रीरैंकिंग डिफ़ॉल्ट रूप से चालू हैं। और Octocode का स्ट्रक्चरल grep अब उन गलत पैटर्न्स से अपने आप रिकवर हो जाता है जो LLMs आमतौर पर जेनरेट करते हैं — शून्य परिणाम देने और चुप रहने की बजाय।

0.14.1 के बाद से 42 कमिट्स। यहाँ वो है जो मायने रखता है।

कोई API Key जरूरी नहीं

0.15.0 की डिफ़ॉल्ट कॉन्फ़िग पूरी तरह ऑफलाइन चलती है। मॉडल पहले उपयोग पर सिस्टम कैश में डाउनलोड होते हैं। उसके बाद: कोई नेटवर्क कॉल नहीं, कोई रेट लिमिट नहीं, कोई मासिक बिल नहीं।

[embedding]
code_model = "fastembed:jinaai/jina-embeddings-v2-base-code"
text_model = "fastembed:nomic-ai/nomic-embed-text-v1.5"

[search.reranker]
enabled = true
model   = "fastembed:jina-reranker-v2-base-multilingual"

[search.hybrid]
enabled = true
default_vector_weight  = 0.6
default_keyword_weight = 0.4

डिफ़ॉल्ट अनुभव अब यह है: रेपो क्लोन करें, octocode index चलाएं, परिणाम पाएं। Voyage, Cohere और Jina API के विकल्प अभी भी वहाँ हैं — टेम्प्लेट में कमेंट किए हुए — अगर आप उन्हें चाहते हैं।

एक सूचना: अपग्रेड के बाद पहला octocode index नए लोकल मॉडल डाउनलोड करेगा, कुल मिलाकर कुछ सौ MB। एक बार की डाउनलोड, फिर कैश हो जाती है।

हाइब्रिड सर्च डिफ़ॉल्ट रूप से चालू

Octocode पहले डेंस वेक्टर सर्च और BM25 के बीच चुनता था। 0.15.0 उन्हें हर क्वेरी में Weighted Reciprocal Rank Fusion के ज़रिए मिला देता है, जो LanceDB के अंदर चलता है।

"find parse_remote" जैसी आइडेंटिफायर-हेवी सर्च में डेंस वेक्टर हार जाते हैं। "फ़ंक्शन जो रिमोट pull सेटअप हैंडल करता है" जैसी पैराफ्रेज़्ड इंटेंट में BM25 हार जाता है। उन्हें मिलाने का मतलब है कि कोई भी तरीका फेल नहीं होता — आपको हर क्वेरी में दोनों का बेस्ट मिलता है।

बैलेंस कॉन्फ़िगर किया जा सकता है:

# कोड-हेवी प्रोजेक्ट — आइडेंटिफायर डॉमिनेट करते हैं
default_vector_weight  = 0.3
default_keyword_weight = 0.7

# डॉक्स-हेवी प्रोजेक्ट — सेमांटिक इंटेंट डॉमिनेट करती है
default_vector_weight  = 0.8
default_keyword_weight = 0.2

एक क्लीनअप नोट: keyword_path_weight, keyword_content_weight जैसे पुराने कॉन्फ़िग फील्ड्स हटा दिए गए हैं। उनका कोई प्रभाव था ही नहीं। उन्हें शामिल करने वाले पुराने कॉन्फ़िग लोड होंगे, लेकिन वैल्यू इग्नोर की जाएगी। इसके बजाय default_vector_weight / default_keyword_weight का उपयोग करें।

स्ट्रक्चरल Grep अब खाली परिणाम नहीं देता

स्ट्रक्चरल सर्च की पहले की समस्या: LLMs अक्सर गलत नोड काइंड्स जेनरेट करते हैं। Python function_definition उपयोग करता है, function_declaration नहीं। Rust function_item उपयोग करता है। LLM जो स्वाभाविक लगता है वह चुनता है, शून्य परिणाम पाता है, और कोई संकेत नहीं क्यों।

अब जब कोई पैटर्न कुछ नहीं मिलाता, Octocode स्वचालित रूप से क्रमशः ढीली व्याख्याओं को आज़माता है — और प्रत्येक भाषा के लिए सही काइंड जानता है। Python में function_declaration function_definition बन जाता है। func, fn, function — सब सही तरीके से रिज़ॉल्व होते हैं, चाहे LLM ने कुछ भी टाइप किया हो।

जब सब कुछ काम नहीं करता, तो चुप्पी की बजाय एक उपयोगी एरर मिलती है:

"Python में function_declaration की बजाय function_definition उपयोग करें"

दूसरा फ़िक्स: बड़े मैच — पूरे क्लास बॉडीज़, बड़े फ़ंक्शन ब्लॉक — पहले सब कुछ डंप कर देते थे और कॉन्टेक्स्ट विंडो को उड़ा देते थे। अब पहली कुछ लाइनें और एक सारांश दिखाते हैं:

src/foo.rs:42:  pub fn handle_request(req: Request) -> Result<Response> {
                    let user = authenticate(&req)?;
                    let payload = req.json()?;
                    if !validate(&payload) {
... (24 more lines)

छोटे मैच बिना बदलाव के पास होते हैं।

GraphRAG अब ट्रैक करता है कौन किसे एक्सटेंड करता है

GraphRAG पहले से फ़ाइलों के बीच कॉल और इंपोर्ट का ग्राफ़ बनाता था। 0.15.0 से, यह इनहेरिटेंस और इंटरफेस रिलेशनशिप भी एक्सट्रैक्ट करता है — C++, Go, Java, JavaScript, TypeScript, PHP, Python, Ruby और Rust में।

हर फ़ंक्शन/क्लास एंट्री में अब शामिल है:

  • extends — सुपरक्लासेस, पैरेंट traits/interfaces, Go में struct embedding
  • implements — इंटरफेस implementations, trait satisfactions, Rust में impl Trait for Type
octocode graphrag get-relationships --node_id src/auth/middleware.rs

अब मौजूदा imports और calls ग्राफ के साथ inheritance और impl edges भी वापस करता है। एक AI एजेंट अब फ़ाइलों को मैन्युअली स्कैन किए बिना "Validator कौन इम्प्लीमेंट करता है?" या "कौन सी क्लासेस BaseHandler एक्सटेंड करती हैं?" का जवाब दे सकता है। टाइप नामों को नॉर्मलाइज़ किया जाता है ताकि क्रॉस-फ़ाइल रिज़ॉल्यूशन जेनेरिक्स और नेमस्पेस्ड टाइप्स के साथ भी काम करे।

अपना इंडेक्स एक्सपोर्ट और इंपोर्ट करें

किसी नई मशीन पर जाने का मतलब पहले पूरा embedder दोबारा चलाना था। एक बड़े रेपो और लोकल मॉडल्स के साथ, इसमें समय लगता है।

# मशीन A पर
$ octocode export
Exported 142.30 MB
/Users/dk/Work/myproject/octocode-abc123-20260520-203708.tar.zst

# फ़ाइल ट्रांसफर करें, फिर मशीन B पर
$ cd /path/to/same/project
$ octocode import octocode-abc123-20260520-203708.tar.zst

आर्काइव में मुख्य इंडेक्स और ब्रांच ओवरले दोनों शामिल हैं। इंपोर्ट एटॉमिक है — फेलियर पर कोई आंशिक स्टेट नहीं। एक्सपोर्ट इंडेक्स लॉक लेता है, इसलिए समानांतर ऑपरेशन प्रतीक्षा करते हैं न कि रेस करते हैं।

बाकी सब कुछ

  • ब्रांच डेल्टा कोहेरेंस — ब्रांच ओवरले अब चुपचाप पुराने मुख्य इंडेक्स पर लागू नहीं होते। Octocode मिसमैच का पता लगाता है और असंगत परिणामों की बजाय स्पष्ट चेतावनी देता है।
  • मेथड्स अब अपनी क्लास का नाम साथ रखते हैं — Suppression.mark_set या Foo.bar खोजने पर अब मेथड सीधे मिलता है। पहले यह तभी काम करता था जब डिस्क्रिप्शन में रिसीवर का उल्लेख हो।
  • बड़े क्लास बॉडीज़ की बेहतर चंकिंग — Python, TypeScript, C++ और Ruby अब मेथड्स को अलग-अलग इंडेक्स करते हैं। 2,000 लाइन की क्लास के लिए एक विशाल चंक के परिणाम अब नहीं आएंगे।
  • मल्टी-क्वेरी कैप 5 से 10 हुई — वे एजेंट जो पहले दो रिक्वेस्ट में बैच करते थे अब एक में कर सकते हैं।
  • C++20 मॉड्यूल फ़ाइलें पहचानी जाती हैं — .cppm, .ixx, .mxx, .ccm, .cxxm, .cc, .cxx, .c++, .hxx कोड के रूप में इंडेक्स होती हैं।
  • अधिक टेक्स्ट फॉर्मेट इंडेक्स होते हैं — yaml, toml, dockerfile, makefile, ini, conf, env, xml, html, sql, csv, tsv, log और अन्य अब टेक्स्ट ब्लॉक के रूप में इंडेक्स होते हैं।
  • डेटाबेस मेंटेनेंस ऑटोमैटिक — हर इंडेक्सिंग रन डेटाबेस को ऑटोमैटिकली कॉम्पैक्ट करता है। इंडेक्स बढ़ने के साथ सर्च तेज़ रहती है।
  • Alpine और musl Linux के लिए स्टैटिक बाइनरी — मिनिमल कंटेनर्स पर libonnxruntime.so की गलती अब नहीं।
  • छोटी बाइनरी, तेज़ एंबेडिंग — बिल्ड प्रोफाइल opt-level = 3 से opt-level = "z" में बदला। बाइनरी काफी छोटी है — और विरोधाभासी रूप से, लोकल एंबेडिंग रन भी तेज़ हो गए। छोटा कोड CPU इंस्ट्रक्शन कैश में बेहतर फिट होता है, जो इस वर्कलोड के लिए aggressive inlining से ज़्यादा मायने रखता है।
  • --mode all के लिए क्रॉस-मोडैलिटी फ्यूज़न — कोड/टेक्स्ट/डॉक्स के बीच पुरानी फिक्स्ड 1/3 स्प्लिट को प्रति-मोडैलिटी RRF से बदला गया है। हर इनपुट लिस्ट अपनी लिस्ट के भीतर रैंक के हिसाब से योगदान देती है — बेहतर मिक्स जो यह दर्शाता है कि मैच वास्तव में कहाँ हैं, बिना एंबेडिंग मॉडल्स के बीच स्केल-असंगतता की समस्याओं के।

अपग्रेड पाथ

  1. पहले अपने मौजूदा इंडेक्स का बैकअप लें: octocode export
  2. अपग्रेड करें:
    brew upgrade muvon/tap/octocode
# या
curl -fsSL https://raw.githubusercontent.com/Muvon/octocode/master/install.sh | sh
  3. मॉडल्स के बारे में फैसला करें: नए लोकल डिफ़ॉल्ट को स्वीकार करें (कोई कॉन्फ़िग बदलाव ज़रूरी नहीं), या Voyage/Cohere/Jina जारी रखने के लिए अपनी पुरानी [embedding] और [search.reranker] कॉन्फ़िग वापस पेस्ट करें।
  4. अगर क्लीन रीइंडेक्स चाहते हैं (अनुशंसित — नई चंकिंग पहले से इंडेक्स की गई फ़ाइलों पर लागू नहीं होगी): octocode clear && octocode index
  5. वैकल्पिक: अपने प्रोजेक्ट के प्रकार के अनुसार default_vector_weight / default_keyword_weight ट्यून करें।

अगर 0.14.x के परिणामों को ठीक वैसे ही रिप्रोड्यूस करने के लिए प्योर वेक्टर रैंकिंग चाहिए, तो [search.hybrid] enabled = false सेट करें। पहली सर्च पर रीरैंकर मॉडल डाउनलोड को [search.reranker] enabled = false से स्किप किया जा सकता है।

Octocode open source (Apache 2.0) है github.com/Muvon/octocode पर। यह Octomind के अंदर कोड सर्च को पावर करता है — MCP सर्वर ही वह तरीका है जिससे वे बात करते हैं।