0.15.0 ने Octocode को डिफ़ॉल्ट रूप से लोकल-फर्स्ट बनाया: कोई API key जरूरी नहीं, एंबेडिंग्स आपकी अपनी मशीन पर fastembed के ज़रिए चलती हैं। एक रेपो क्लोन करें, octocode index चलाएं, परिणाम पाएं, कुछ भी आपके लैपटॉप से बाहर नहीं जाता।

fastembed उन कुछ मॉडल्स को चलाता है जो यह बंडल करता है, आपके CPU पर, इन-प्रोसेस। शुरुआत करने के लिए बढ़िया — कम बढ़िया तब जब आपको एक बड़ा या नया embedding मॉडल, एक GPU, या एक सर्वर चाहिए जिसे पूरी टीम शेयर करे। local provider ठीक इसी के लिए जोड़ा गया: Octocode को किसी भी OpenAI-कम्पैटिबल embedding सर्वर पर पॉइंट करें — Ollama, LM Studio, vLLM, llama.cpp, LocalAI, text-embeddings-inference — और जो भी मॉडल वह होस्ट करता है उसके साथ इंडेक्स करें।

0.17.1 वह रिलीज़ है जहाँ यह एंड टू एंड काम करता है। provider अब आपके मॉडल की embedding डायमेंशन को अपने आप डिटेक्ट करता है, जो वह हिस्सा है जिसकी इंडेक्सिंग को अपना वेक्टर स्टोर बनाने के लिए ज़रूरत होती है। मॉडल चुनें, हार्डवेयर चुनें, और आपका कोड फिर भी कभी आपके नेटवर्क से बाहर नहीं जाता।

यह पोस्ट local provider के साथ-साथ 0.16.0 के बाद के बाकी बदलावों को कवर करती है (जून राउंड-अप ने आपको वहाँ तक पहुँचाया): read-only MCP मोड और 0.16.1 की AST-प्रिसाइज़ स्ट्रक्चरल सर्च।

अपना खुद का Embedding सर्वर लाएं

कॉन्फ़िग की दो लाइनें:

[embedding]
code_model = "local:nomic-embed-text"
text_model = "local:nomic-embed-text"

local: प्रीफ़िक्स Octocode को बताता है कि embedding रिक्वेस्ट्स ऐसे सर्वर को भेजे जो OpenAI /v1/embeddings API बोलता हो। डिफ़ॉल्ट रूप से यह http://localhost:11434/v1/embeddings पर पॉइंट करता है — Ollama का पोर्ट — इसलिए अगर Ollama पहले से चल रहा है, तो सेटअप करने के लिए और कुछ नहीं:

ollama pull nomic-embed-text
octocode index

कहीं और पॉइंट करना एक environment variable का काम है:

# vLLM, LM Studio, llama.cpp server, LocalAI, text-embeddings-inference —
# anything that exposes POST /v1/embeddings
export LOCAL_EMBED_API_URL="http://gpu-box.internal:8000/v1/embeddings"

# Optional — sent as `Authorization: Bearer <key>` if your server wants one
export LOCAL_EMBED_API_KEY="..."

बस इतना ही पूरा सेटअप है। कोई SDK नहीं, कोई provider-स्पेसिफिक ग्लू नहीं।

कोई डायमेंशन कॉन्फ़िगर करने की ज़रूरत नहीं

अलग-अलग embedding मॉडल अलग-अलग चौड़ाई के वेक्टर बनाते हैं — 384, 768, 1024 — और वेक्टर स्टोर को अपना इंडेक्स बनाने के लिए वह चौड़ाई पहले से पता होनी चाहिए। एक OpenAI-कम्पैटिबल सर्वर इसे कहीं विज्ञापित नहीं करता, इसलिए Octocode इसे आपके लिए पता कर लेता है: जब यह पहली बार आपके मॉडल के लिए एक provider बनाता है, तो यह एक छोटी probe रिक्वेस्ट भेजता है, रिस्पॉन्स से सीधे वेक्टर चौड़ाई पढ़ता है, और बाकी रन के लिए उसे कैश कर लेता है। फिर इंडेक्स उसी डायमेंशन के आसपास बनाया जाता है।

व्यावहारिक नतीजा: आपका सर्वर जो भी मॉडल सर्व कर सकता है वह बस काम करता है। प्रति-मॉडल कुछ भी लुक अप या सेट करने की ज़रूरत नहीं। nomic-embed-text को एक बड़े code मॉडल से बदलें और Octocode अगले इंडेक्स पर नई चौड़ाई के हिसाब से अनुकूलित हो जाता है — एकमात्र शर्त एक री-इंडेक्स है, क्योंकि अलग-अलग मॉडल्स के वेक्टर आपस में तुलनीय नहीं होते।

fastembed बनाम local — कौन सा?

दोनों लोकल हैं। फ़र्क इस बात का है कि मॉडल कौन चलाता है।

fastembed: local:
चलता है इन-प्रोसेस (ONNX, आपके CPU पर) एक अलग सर्वर जिसे आप मैनेज करते हैं
मॉडल्स वह क्यूरेटेड सेट जो Octocode बंडल करता है जो भी आपका सर्वर होस्ट कर सकता है
हार्डवेयर इस मशीन का CPU जहाँ भी सर्वर रहता है — GPU, एक शेयर्ड बॉक्स
सेटअप शून्य — मॉडल्स पहले उपयोग पर डाउनलोड होते हैं आप Ollama/vLLM/आदि चलाते हैं

fastembed चुनें जब आपको शून्य-सेटअप और एक ठोस डिफ़ॉल्ट चाहिए। local चुनें जब आप उससे आगे बढ़ चुके हों:

  • एक मॉडल जो fastembed बंडल नहीं करता — एक नया code embedding मॉडल, एक बड़ा, कुछ डॉमेन-ट्यून्ड। अगर आपका सर्वर इसे सर्व कर सकता है, तो Octocode इसके साथ इंडेक्स कर सकता है।
  • असली हार्डवेयर। एक बड़े मोनोरेपो को लैपटॉप CPU पर embed करना धीमा है। LOCAL_EMBED_API_URL को एक GPU सर्वर पर पॉइंट करें और embedding आपके लैपटॉप की बजाय वहाँ चलती है।
  • टीम के लिए एक सर्वर। एक ही Ollama या vLLM इंस्टेंस चलाएं; हर डेवलपर का Octocode उसी पर पॉइंट करता है। कंसिस्टेंट वेक्टर, मॉडल अपग्रेड करने के लिए एक जगह।

और वह प्रॉपर्टी जो इन दोनों के बीच नहीं बदलती: यह सेल्फ-होस्टेड, प्राइवेट कोड सर्च है — आपका कोड आपके नेटवर्क के अंदर ही रहता है। वही गारंटी जो 0.15.0 ने दी थी, अब बंडल किए गए मॉडल्स या आपके लैपटॉप के CPU में बंधे बिना।

Read-Only MCP मोड

डिफ़ॉल्ट रूप से, जब कोई AI एजेंट Octocode के MCP सर्वर से कनेक्ट होता है, तो सर्वर अब आपके मौजूदा इंडेक्स पर सर्च सर्व करता है और उसे कभी छूता नहीं। कोई बैकग्राउंड इंडेक्सर नहीं, कोई फ़ाइल वॉचर नहीं, आपके असिस्टेंट के कनेक्ट होते ही कोई अप्रत्याशित री-इंडेक्स शुरू नहीं होता।

यह mcp_index टॉगल है, और false डिफ़ॉल्ट है:

[index]
# false (default): MCP serves search, view_signatures, and structural_search
#   over the EXISTING index, read-only. No background indexing or file watcher.
# true: MCP keeps the index fresh in-process with a background indexer + watcher.
mcp_index = false

read-only को डिफ़ॉल्ट क्यों रखा गया? इंडेक्सिंग और सर्विंग अलग-अलग काम हैं। आप इंडेक्स CI में, एक git हुक पर, या हाथ से करते हैं — जानबूझकर, जब कोड बदलता है। MCP सर्वर का काम है एजेंट के सवालों का तेज़ और अनुमानित तरीके से जवाब देना, न कि एक फ़ाइल वॉचर शुरू करना और आपके रेपो को दोबारा embed करना सिर्फ़ इसलिए कि एक एडिटर ने किसी फ़ाइल को छुआ। read-only का मतलब है कम idle रिसोर्स उपयोग, कोई contention नहीं, और जिस पल कोई टूल कनेक्ट होता है उसी पल कोई अनपेक्षित काम नहीं।

index CLI कमांड अप्रभावित है — octocode index इंडेक्स करता है, हमेशा की तरह। mcp_index सिर्फ़ उस इन-प्रोसेस इंडेक्सर को गेट करता है जिसे MCP सर्वर अन्यथा चलाता।

read-only मोड के लिए एक छोटा सा टच भी है: अगर कोई semantic search खाली वापस आती है (क्योंकि इंडेक्स पुराना है या अभी बना नहीं है), तो Octocode एक-लाइन का नज जोड़ देता है जो एजेंट को structural_search और view_signatures की ओर ले जाता है, बजाय इसके कि वह शून्य में semantic search को बार-बार आज़माता रहे।

पुराना हमेशा-ताज़ा व्यवहार चाहिए — एक लंबे समय तक चलने वाला सर्वर जो खुद को अपडेट रखता है? mcp_index = true सेट करें और बैकग्राउंड इंडेक्सर तथा वॉचर वापस आ जाते हैं।

स्ट्रक्चरल सर्च, अब AST-प्रिसाइज़ (0.16.1)

0.16.1 को अपनी खुद की पोस्ट नहीं मिली, इसलिए इसका ज़िक्र करना जरूरी है: Octocode के MCP सर्वर को एक उचित structural search टूल मिला, जो semantic search और grep से अलग है।

Semantic search "payment retry कहाँ रहता है?" के लिए बढ़िया है। Grep लिटरल स्ट्रिंग्स के लिए बढ़िया है। Structural search बीच के सवालों के लिए है — इस कोड शेप को खोजें, फ़ॉर्मैटिंग या नामकरण की परवाह किए बिना — और सिंबल्स के लिए:

  • सिंबल डेफ़िनिशन और रेफ़रेंस वाइल्डकार्ड सपोर्ट के साथ — "handle_* कहाँ डिफ़ाइन है, और कौन इसे कॉल करता है?"
  • स्मार्ट और रिलैक्स्ड मैचिंग स्ट्रैटेजी। 0.15.0 में स्ट्रक्चरल grep सुधारों की तरह, यह तब रिकवर हो जाता है जब अनुरोधित नोड काइंड भाषा के लिए गलत हो, बजाय कुछ न लौटाने के।
  • मेटावेरिएबल कंस्ट्रेंट्स — मैच को regex और रिलेशनल फ़िल्टर्स से संकीर्ण करें, सिर्फ़ रॉ पैटर्न्स से नहीं।
  • ब्रेडक्रंब ट्रैकिंग ताकि हर मैच आपको बताए कि वह किस class/function/module के अंदर नेस्टेड है, भाषाओं के पार (Swift शामिल)।
  • पेजिनेशन और रिक्वेस्ट कैशिंग ताकि एक एजेंट पूरे स्कैन को दोबारा चलाए बिना बड़े रिज़ल्ट सेट्स के पन्ने पलट सके।

अंदर ही अंदर यह ट्री को gitignore-अवेयर और समानांतर रूप से वॉक करता है, लिटरल-टोकन प्रीफ़िल्टरिंग और AST पाथ के खाली आने पर एक lexical फ़ॉलबैक के साथ — बड़े रेपो पर तेज़, और यह चुपचाप मैच नहीं चूकता। एक AI एजेंट के लिए, यह सटीक कोड स्ट्रक्चर्स खोजने और सिंबल्स को ट्रेस करने का एक प्रिसाइज़, नेविगेबल तरीका है।

बाकी सब कुछ

view_signatures एक स्ट्रिंग के रूप में एक फ़ाइल लेता है। एजेंट (और इंसान) एक फ़ाइल को एक-एलिमेंट वाली array में रैप करने की बजाय एक प्लेन स्ट्रिंग के रूप में पास कर सकते हैं। सबसे आम केस के लिए कम घर्षण।

टूल डेफ़िनिशन अब हार्डकोडेड नहीं हैं। MCP सर्वर की टूल लिस्ट हाथ से मेंटेन करने की बजाय जेनरेट होती है, जो स्कीमा और इम्प्लीमेंटेशन को एक-दूसरे से अलग होने से रोकता है।

डिपेंडेंसी और CI क्लीनअप। Rust डिपेंडेंसीज़ बंप की गईं, रिलीज़ पाइपलाइन शेयर्ड रीयूज़ेबल वर्कफ़्लोज़ में माइग्रेट हुई। कोई व्यवहार बदलाव नहीं — बस एक साफ़-सुथरा, अधिक भरोसेमंद बिल्ड।

अपग्रेड

# Homebrew
brew upgrade muvon/tap/octocode

# Universal installer
curl -fsSL https://raw.githubusercontent.com/Muvon/octocode/master/install.sh | sh

# Cargo
cargo install octocode --version 0.17.1

अगर आप fastembed से खुश हैं, तो करने को कुछ नहीं — आपका कॉन्फ़िग और इंडेक्स काम करते रहते हैं। अपने खुद के embedding सर्वर पर स्विच करने के लिए:

  1. एक सर्वर शुरू करें जो OpenAI embeddings API बोलता हो (जैसे ollama serve) और एक मॉडल लोड करें।
  2. config.toml में code_model / text_model को local:<model> पर सेट करें। अगर सर्वर Ollama के डिफ़ॉल्ट पोर्ट पर नहीं है तो LOCAL_EMBED_API_URL को सर्वर पर पॉइंट करें।
  3. री-इंडेक्स करें — वेक्टर मॉडल के साथ बदलते हैं: octocode clear && octocode index।

चाहते हैं कि आपका MCP सर्वर पुराने वर्ज़न की तरह बैकग्राउंड में इंडेक्स करता रहे? mcp_index = true सेट करें। अन्यथा read-only डिफ़ॉल्ट लागू हो जाता है — CLI या CI से इंडेक्स करें, और सर्वर को सर्व करने दें।

Octocode open source (Apache 2.0) है github.com/Muvon/octocode पर। यह Octomind के पीछे का कोड-सर्च इंजन है — और अब आप इसके द्वारा जेनरेट की गई हर embedding को उस हार्डवेयर पर चला सकते हैं जिसे आप कंट्रोल करते हैं, जो भी मॉडल आप चुनें।