Semble - एजेंट्स के लिए ऐसा कोड सर्च जो grep की तुलना में 98% कम टोकन इस्तेमाल करता है

• Semble एक code search library है, जिसे इस तरह बनाया गया है कि एजेंट natural language और code queries से ज़रूरी code snippets तुरंत ढूंढ सकें
• grep+read की तुलना में यह लगभग 98% कम टोकन इस्तेमाल करता है, और पूरी file पढ़ने के बजाय सिर्फ़ संबंधित chunks लौटाता है
• यह औसत repository को लगभग 250ms में index करता है और queries का जवाब लगभग 1.5ms में देता है, तथा CPU पर API key, GPU या external service के बिना चलता है
• benchmark 19 भाषाओं की 63 repositories पर लगभग 1,250 queries के साथ किया गया, और इसमें दिखाया गया कि Semble ने CodeRankEmbed Hybrid quality का 99% हासिल किया, जबकि indexing 218 गुना तेज़ थी
• token efficiency benchmark में Semble ने औसतन 98% कम टोकन इस्तेमाल किए और सिर्फ़ 2k टोकन में 94% recall तक पहुंच गया, जबकि grep+read 100k context window पर 85% recall तक पहुंचा
• इसे MCP server के रूप में Claude Code, Cursor, Codex, OpenCode और MCP-compatible agents में इस्तेमाल किया जा सकता है, और repositories ज़रूरत पड़ने पर clone और index की जाती हैं, जबकि session के दौरान index cache में रहता है
• यह Bash-आधारित उपयोग को भी support करता है, इसलिए AGENTS.md या CLAUDE.md में semble search और semble find-related workflows डाले जा सकते हैं, और Claude Code तथा Codex CLI के subagents के लिए यही तरीका ज़रूरी है
• CLI local path और https:// Git URL दोनों ले सकता है, और अगर path छोड़ा जाए तो current directory default के रूप में इस्तेमाल होती है
• इसे Python library के रूप में भी इस्तेमाल किया जा सकता है, इसलिए SembleIndex.from_path, SembleIndex.from_git, search, find_related के साथ custom tools में search integrate किया जा सकता है
• अंदरूनी रूप से यह tree-sitter का उपयोग करके files को code-aware chunks में बांटता है, फिर Model2Vec के potion-code-16M embeddings और BM25 को मिलाकर Reciprocal Rank Fusion से score जोड़ता है
• ranking में symbolic queries के लिए lexical weighting, definition chunk boost, identifier stemming match, same-file relevance, और test, legacy, example, .d.ts के लिए downweighting का उपयोग होता है
• static embedding model इस्तेमाल करने की वजह से query के समय transformer forward pass नहीं होता, इसलिए CPU पर millisecond-level search संभव है
• semble savings हर search पर लौटाए गए chunks से जुड़े unique files के पूरे character count और लौटाए गए snippets के character count की तुलना करके token savings का अनुमान लगाता है, और यह statistics ~/.semble/savings.jsonl में सेव करता है
• package को PyPI के semble से install किया जा सकता है, और MCP उपयोग के लिए uvx --from "semble[mcp]" semble फ़ॉर्म इस्तेमाल किया जाता है
• license MIT है

[GN⁺]

Hacker News की राय

• ऐसे टूल इस्तेमाल करने पर मैंने देखा है कि जैसे coder, AI टूल्स पर ज़्यादा निर्भर होने पर मूर्ख हो जाते हैं, वैसे ही AI खुद भी मूर्ख हो जाती है
  agent-टाइप AI पहले से ही code navigation या search में काफ़ी optimized path ढूंढने लायक स्मार्ट है, लेकिन ऐसे टूल जोड़ देने पर search results लगभग हमेशा पूरी detail की जगह सिर्फ pointers देते हैं, इसलिए यह ज़रूरत से ज़्यादा aggressive ढंग से चलने लगती है
  मैंने सरलता के लिए Pi से एक कुछ जटिल project में पूरा gathering/search path trace करवाया, तो codebase-memory-mcp में 85k/4.4k input/output tokens लगे, मेरी सामान्य setting में 67k/3.2k, और बिना किसी टूल के 80k/3.2k थे
  result quality और information amount समान थे, और यह टूल छोटा फ़र्क होने के बावजूद उल्टा बदतर निकला
  मेरी सामान्य setting बस AGENTS.md और CLAUDE.md में एक पंक्ति डालने की है: “PROJECT.md से शुरू करो”
  PROJECT.md में project का 2-3 पंक्तियों का विवरण, संबंधित files और एक-पंक्ति के विवरण, सावधानियाँ, और LLM के लिए सिर्फ यह पंक्ति रहती है: “अगर update करना उचित हो तो इस file को update करो. इस file का उद्देश्य project का एक मोटा अंदाज़ा देना है, और ज़रूरत पड़ने पर वहीं से आगे explore कराना है”

  • “agent-टाइप AI पहले से ही code navigation या search में highly optimized path ढूंढने जितनी स्मार्ट है” — यह बात मेरे अनुभव से मेल नहीं खाती
    काम पर हम पहले Augment Code इस्तेमाल करते थे, जिसमें pre-indexed code पर natural-language queries का जवाब देने वाला MCP-जैसा Context Engine था
    बाद में हम Claude Code पर आ गए, लेकिन अजीब बात है कि range-read tool होते हुए भी यह अपनी memory में बचे line ranges के आधार पर sed से file पढ़ने की कोशिश करता है
    मुझे नहीं पता कि इसे सच में highly optimized path कहना चाहिए या नहीं
  • codebase-memory-mcp और semble बिल्कुल एक जैसी चीज़ें नहीं हैं, लेकिन यह तुलना दिलचस्प है, इसलिए मैं इसे अपनी verification task list में डालूंगा और हो सके तो benchmark में भी जोड़ूंगा
    अगर आपको यही तुलना semble के साथ करने का मौका मिले, तो वह सच में बहुत उपयोगी feedback होगा. ऐसे “real-world” scenarios को benchmark करना या reproduce करना मुश्किल होता है

• दिलचस्प है. मैं भी इस क्षेत्र में काम कर रहा हूँ, लेकिन मेरा approach अलग था
  index बनाने के बजाय, मैंने पूरे codebase और सामान्य text पर ranking और code-structure awareness के साथ एक अधिक स्मार्ट grep बनाया, और क्योंकि ज़्यादातर समय performance issues पर लगाया, यह बहुत तेज़ चलता है
  इसे https://github.com/boyter/cs के साथ comparison target के रूप में जोड़ना चाहिए और देखना चाहिए कि LLMs मेरे पूछे जाने वाले सवालों पर क्या पसंद करते हैं
  यह भी MCP देता है, लेकिन search index नहीं बनाता. यह default BM25 की जगह code-semantic variants इस्तेमाल करता है, इसलिए ranking कैसी आएगी यह देखने में दिलचस्पी है
  यह टूल “authentication कैसे काम करती है” जैसी query के लिए ज़्यादा उपयुक्त लगता है, और cs authenticate --only-declarations करने के बाद file contents पर, यानी match location code में है या comment में, और file की overall complexity के आधार पर results को weight देता है
  star कर दिया है, नज़र रखूँगा

• मुझे पता है यह टूल AI के लिए है, लेकिन नए codebase या अपने codebase को explore करते समय इसे खुद इस्तेमाल करने में मेरी ज़्यादा दिलचस्पी है
  जब किसी चीज़ को refactor करने के लिए यह देखना हो कि कहाँ-कहाँ बदलाव चाहिए, तब पूरा खाका देखने में यह उपयोगी लगता है
  LSP भी ऐसा काम करता है, लेकिन लगता है यह टूल एक कदम आगे जा सकता है

• मैंने Pi और GPT 5.5 के साथ कुछ evaluations किए
  RTK on / headroom on / दोनों on / दोनों off टेस्ट किया, और सभी में standard Pi system instructions थे, AGENTS.md नहीं था
  ठीक-ठीक कौन से tests थे याद नहीं, लेकिन वे लोगों द्वारा इस्तेमाल किए जाने वाले कुछ standard agent evals थे, जिनमें एक Python और एक TypeScript था, जो मेरी भाषाएँ हैं
  मैं यह दावा नहीं करता कि यह thorough test था या अच्छा test था. अगर मैंने एक दिन AGENTS.md और Pi system prompt/tool instructions को tune करने में लगाया होता, तो शायद बेहतर results आते. Eval चलाते समय मैंने एक बात सीखी कि ऐसे subtle differences result को काफ़ी बदल सकते हैं
  लेकिन दोनों off वाला setup साफ़ तौर पर बेहतर था, इतना कि 3 rounds के बाद मैंने test रोक दिया
  समस्या यह थी कि कभी-कभी context usage कम हुई, लेकिन completion तक पहुँचने के turns बढ़ गए, इसलिए कुल conversation cost और ज़्यादा हो गई
  इससे मुझे बहुत तीव्रता से यह महसूस हुआ कि बहुत से लोग ऐसे tools share करते हैं, लेकिन या तो कोई eval नहीं होता, या उसे reproduce करना संदिग्ध रूप से मुश्किल होता है, या फिर इस टूल की तरह बहुत benchmarks होते हुए भी गलत चीज़ मापी जाती है
  यह टूल grep से कम tokens इस्तेमाल करता है, यह सही है और benchmark भी यह साबित करता है, लेकिन असली बात वह नहीं है. असली बात यह है कि agent इस टूल का इस्तेमाल करके वही quality वाला काम तेज़ी से और कम cost में कर पाता है या नहीं

  • अभी पूरे AI industry में testing की कमी है
    यह सिर्फ इस टूल की समस्या नहीं है, बल्कि codebase या development flow में AI जोड़ने वाली हर चीज़ की समस्या है
    AI से पहले भी “यह कितनी तेज़ और अच्छी तरह develop हुआ” इसे मापने वाले tests नहीं थे, और अब भी नहीं जोड़े गए हैं
  • AI में “क्योंकि हम कर सकते थे, इसलिए हमने यह नहीं सोचा कि करना चाहिए या नहीं” बहुत बार होता दिखेगा

• मैं असली agent benchmarks देखना चाहूँगा. जैसे Claude Code या Copilot CLI में grep हटाकर उसकी जगह यह टूल डाल दिया जाए
  मैंने RTK और कई LSP implementations देखे हैं, और models को grep पर इतना मज़बूत reinforcement मिला हुआ है कि वे दूसरे रूप के results पर भरोसा नहीं करते और बार-बार retry या reread करते हैं
  इसलिए model दूसरे tool results पर भरोसा नहीं करता, और token savings पूरी तरह ख़त्म हो जाती है

  • मैंने global CLAUDE.md (~/.Claude के नीचे) में grep की जगह LSP इस्तेमाल करने को लिख दिया, उसके बाद यह समस्या नहीं रही
  • Codex CLI RTK को काफ़ी अच्छी तरह चलाता है. कम से कम GPT 5.5 xhigh में तो ऐसा था
    लेकिन जब यह find के कुछ खास CLI flags जैसी चीज़ें support नहीं करता, तब command का पूरा output भेजने के बजाय error message देता है, जो खटकता है
    फिर agent tokens बर्बाद करते हुए retry करता है, या उससे भी बुरा, prompt की वजह से डर जाता है कि RTK के बिना command नहीं चलानी चाहिए, और कोशिश ही नहीं करता
  • हमें भी ऐसे benchmarks में रुचि है, और model के लिए इसे आसान बनाने के लिए prompt और description optimization के साथ यह roadmap में शामिल है
    यह सिर्फ एक anecdote है, लेकिन हम खुद भी यह टूल इस्तेमाल कर रहे हैं, और अभी तक यह काफ़ी अच्छा चला है
    Anthropic models इस टूल को call करते हैं और results पर भरोसा करते दिखते हैं
  • token savings धीरे-धीरे और महत्वपूर्ण होती जा रही है, लेकिन यह भी महत्वपूर्ण है कि agent results पर भरोसा करे और search बंद करे
    सिर्फ search output मत देखिए, पूरे agent loop को मापना चाहिए
  • कम से कम Codex, अगर आप कहें कि grep अक्सर बहुत धीमा है इसलिए rg इस्तेमाल करो, तो मान लेता है, लेकिन RTK जोड़ने पर RTK के ज़रिए grep चलाने लगता है, जो थोड़ा परेशान करता है

• idea अच्छा लगा, इसलिए थोड़ा आज़माया
  test browsercode(https://github.com/browser-use/browsercode) repository पर किया, और prompt था: “सिर्फ semble CLI इस्तेमाल करो, और बताओ कि Browsercode, default OpenCode tools के अलावा agent को कौन से tools देता है. Tool input/output की exact schema दो, और वे क्या करते हैं और कैसे काम करते हैं इसका संक्षिप्त सार भी दो”
  इसमें मैंने https://github.com/MinishLab/semble#bash-integration का AGENTS.md snippet चिपकाया
  बिना Semble वाले test में यही सवाल बदलकर सिर्फ rg और fd CLI इस्तेमाल करने को कहा
  दोनों मामलों में मैंने Pi और gpt-5.4 medium इस्तेमाल किया, और बाकी settings बहुत minimal रखीं. मैंने यह भी verify किया कि वास्तव में एक तरफ सिर्फ rg और fd, और दूसरी तरफ सिर्फ semble ही इस्तेमाल हुआ
  Semble के बिना model context का 10.9% और API credits में $0.144 लगे, जबकि Semble के साथ 9.8% और $0.172 लगे
  result answers भी लगभग एक जैसे थे, यानी काफ़ी करीब
  मैंने OpenCode repository पर एक और test किया, जहाँ सवाल था: “उस point से path trace करो जहाँ OPENCODE_EXPERIMENTAL_EXA environment variable 1 पर set होता है, वहाँ से लेकर OpenCode agent को दिए जाने वाले system prompt या tools में दिखने वाले final परिणाम तक”
  ऊपर जैसे ही instructions और docs शामिल किए
  non-Semble version थोड़ा अधिक detailed था, और इसने यह भी cover किया कि web search provider के रूप में Exa या Parallel enable होने पर tool call path Exa को call करता है या नहीं, लेकिन असली सवाल का जवाब दोनों versions ने सही दिया
  Semble version ने context 14.7% / API cost $0.282 इस्तेमाल की, जबकि non-Semble version ने 19.0% / $0.352 इस्तेमाल किए
  context efficiency के मामले में Semble स्पष्ट रूप से जीता, लेकिन यह ध्यान देने लायक है कि non-Semble version लगभग दोगुनी तेजी से खत्म हुआ
  बेशक, यह सिर्फ मेरा हल्का-सा प्रयोग था, इसलिए results बदल सकते हैं

• “grep से 98% कम tokens इस्तेमाल करता है” — क्या इसका मतलब यह मान लिया जाए कि grep इतना wasteful है कि model हर बार 98% बेकार कचरा पढ़ रहा है?
  यह दावा representative नहीं लगता, या फिर context का अधिकांश हिस्सा model को देने से काटते समय कुछ और छूट रहा है

  • 98% की तुलना सिर्फ grep output से नहीं, बल्कि grep+read loop से है
    जब agent किसी अपरिचित codebase से टकराता है, तो आम तौर पर पहले cat file करता है या पूरी file पढ़ता है. कम से कम मेरा अनुभव यही रहा है
    अगर आप agent को भरोसेमंद तरीके से सिर्फ grep -C N करके वहीं रुकवा रहे हैं, तो आपकी setting जानने में सच में दिलचस्पी होगी. मेरे हिसाब से उस result की quality उपयोगी context के लिए बहुत कम होती है
  • Claude के साथ यह समस्या थी कि node_modules में hit होने वाली चीज़ों के कारण वह सैकड़ों kilobytes output पढ़ लेता था
    ripgrep मदद करता है, इसलिए किसी memory file में बस एक पंक्ति जोड़ना कि वही इस्तेमाल करो, समझ में आता है
  • grep हर matching line output करता है
    जब LLM search करता है, तो noise बहुत आ सकता है, और संभव है कि वह specific तरीके से खोज न पाए, इसलिए उसे ऐसा search करना पड़े
    goal-directed search token count घटा सकता है
    लेकिन यह comparison शायद ज़रूरी हिस्से ही पाने बनाम पूरा codebase पढ़ने की तुलना जैसा लग रहा है

• feedback के तौर पर कहूँ तो, codex-cli जब MCP के ज़रिए इसे call करता है तो अटक जाता है
  semble process भी zombie की तरह बचा रहता है और हमेशा के लिए रुका रहता है. कारण नहीं पता, और logs में भी कुछ नहीं है
  skill के ज़रिए CLI-call वाले तरीके से बुलाने पर GPT 5.5, ripgrep की आदत होने जैसी स्थिति में, search terms बहुत ज़्यादा फेंकने की कोशिश करता है
  यह कितना effective है पता नहीं, और GitHub की छोटी docs और agent instructions से यह साफ़ नहीं होता कि optimal क्या है
  और bash के लिए install करते समय GitHub के बाहर की connections से जुड़े कुछ errors भी आए. पता नहीं उनका इस hang से संबंध है या नहीं
  इसके अलावा, मेरा agent बाद में ripgrep भी चलाने की कोशिश करता है, तो यह duplicate जैसा लगता है. यह भरोसे की समस्या जैसा व्यवहार करता है
  अगर agent skill की ज़्यादा विस्तृत explanation हो, तो शायद agent को सही usage की ओर guide किया जा सके

  • विस्तृत feedback के लिए धन्यवाद
    अगर आप setup details के साथ issue खोल सकें तो अच्छा होगा. यह निश्चित रूप से ऐसी चीज़ है जिसे हम investigate और fix करना चाहेंगे
    कई queries फेंकने वाली समस्या भी बहुत अच्छा feedback है, और इसे रोकने के लिए हम prompt और instructions update करेंगे और संबंधित tests भी जोड़ेंगे
    install के दौरान बाहरी connection errors शायद uv के PyPI से dependencies लाने के कारण थे, और वे hang की वजह नहीं होने चाहिए

• idea अच्छा लग रहा है
  एक related समस्या यह भी है कि छोटे codebases में Claude कई बार पूरे codebase को एक साथ context में डालकर बहुत कम tokens में काम कर सकता है, फिर भी कुछ खोजने में बहुत समय बर्बाद करता है
  एक ठीक-ठाक workaround यह है कि start hook से पूरी directory context में डाल दी जाए
  फिर Claude हर task पर “अँधेरे में टटोलने” वाला चरण छोड़ देता है
  बड़े repositories में model को stubs वाला overview देने वाला एक शानदार project भी देखा था, लेकिन नाम भूल गया

  • शायद aider? https://aider.chat/2023/10/22/repomap.html
  • सही बात है. Agents को आम तौर पर यह अच्छी तरह नहीं पता होता कि वे किन चीज़ों को देख रहे हैं, जैसे files की संख्या या file sizes
    लेकिन छोटे codebase में ढूंढी जाने वाली चीज़ें भी ढूंढना आसान होता है, इसलिए search फिर भी cost reduction में मदद कर सकता है

• इन समाधानों की बड़ी समस्या यह है कि ज़्यादातर AI पहले से ही training की वजह से grep और search को बहुत अच्छी तरह इस्तेमाल करते हैं
  AI को कोई नया tool देने पर वह tool उसकी cognitive capacity का कुछ हिस्सा छीन लेता है
  इंसान आम तौर पर ऐसे tools इस्तेमाल करना “सीख” लेते हैं, लेकिन LLM की learning fixed होती है, और उसमें पहले से grep जैसे मौजूदा tools पर बहुत गहरी proficiency होती है
  उदाहरण के लिए AI पहले से tree जैसे Linux commands से codebase explore करना जानता है, और यह भी पर्याप्त रूप से trained है
  एक और समस्या यह है कि ऐसे tools की usefulness दिखाने वाले examples बनाना आसान है, लेकिन वास्तव में यह साबित करना कठिन है कि ऐसे tool से पैदा हुई cognitive कमी को long-running execution में मिलने वाला लाभ offset कर देता है
  मेरा पहला intuition यही है कि लंबे execution में deployable intelligence का net loss होगा, और agent मौजूदा tools इस्तेमाल करने की तुलना में बदतर हो जाएगा
  इसका उल्टा साबित करना आसान समस्या नहीं है, लेकिन शायद कोशिश करने लायक चुनौती हो सकती है