Repository navigation
Semantic Indexing #3184
Description
Does opencode use semantic indexing of the codebase like kilo or cursor?
Reacted by Meowster, D-James-GH, nastyagrifon, gt-solaris, mungo, Azarattum, Damian Tarnawski, Piotr Nowakowski, Imamuzzaki Abu Salam, Simon Powell and 2 more
Metadata
Metadata
Assignees
Labels
No labels
Activity
rekram1-node commentedon Oct 14, 2025
No. The current Opencode agents work off direct filesystem reads and standard text search (e.g., ripgrep) inside the workspace. There’s no vector store or persistent semantic index like Kilo or Cursor provide
AngDrew commentedon Oct 17, 2025
it actually possible with external MCP to index the codebase
maiduohuahuaba commentedon Jan 20, 2026
Yes, it is definitely possible! I'm very interested in this approach. Could you please recommend any specific projects or tools that are good for getting started with codebase indexing using external MCP?
ericmacedo commentedon Jan 25, 2026
@maiduohuahuaba
I recently came across this project, but I haven’t had a chance to try it out yet.
maiduohuahuaba commentedon Feb 15, 2026
Oh, thank you very much! I was extremely busy with work recently and didn’t pay much attention to my email. Today, I tried grepai on a company project, and the results were excellent—it can precisely locate business logic code using natural language.
dhruvkej9 commentedon Feb 20, 2026
@thdxr @rekram1-node Can we now get semantic knowledge for agents? As now we have sqlite already so it is possible using "sqlite-vec" extension to also do vector embeddings. (Openclaw also does something like this currently)
cdbattags commentedon Mar 7, 2026
Hehe I have something cooking
sagarmk commentedon Mar 9, 2026
Since someone mentioned sqlite-vec is now an option with the SQLite integration, I can confirm this approach works extremely well for code search. I built a semantic search plugin that uses exactly this stack: sqlite-vec for vector storage, FTS5 for keyword indexing, embeddings via Ollama locally.
The key insight that made it work well for code specifically: pure vector search alone gives you maybe 85% accuracy because it misses exact function names and imports. Adding BM25 keyword matching and a separate identifier boosting pass pushes that to around 98% in my benchmarks. The three scores get blended with configurable weights.
For chunking I do a simpler approach than tree-sitter: fixed size chunks with overlap, but each chunk carries metadata about which file and line range it covers. Works surprisingly well and avoids the complexity of maintaining tree-sitter grammars for every language.
Storage is a single SQLite file with two virtual tables: one sqlite-vec for embeddings, one FTS5 for keywords. Queries hit both and merge results. Fast enough that search feels instant even on 100k+ line codebases.
The whole thing runs with Ollama using nomic-embed-text or mxbai-embed-large. No cloud dependency.
Implementation here if useful as reference: https://github.com/sagarmk/beacon-plugin
github-actions commentedon May 8, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
dhruvkej9 commentedon May 8, 2026
Would be great if added