Kilo Code Brings Semantic Codebase Indexing Out of Experimental
Published on 04.06.2026
Codebase Indexing Is Back in Kilo Code
TLDR: Kilo Code has graduated codebase indexing from experimental to general availability, giving the AI agent a semantic search tool backed by embeddings and Tree-sitter chunking. It is opt-in, local-friendly, and built largely by a community contributor. If you work in large or unfamiliar codebases, this is worth paying attention to.
Summary: There is a specific kind of pain that every developer has felt when dropped into a large, unfamiliar codebase. You know what you are looking for conceptually, but you have no idea what the repo calls it. The retry logic might live in a class called BackoffCoordinator, or it might be scattered across a handful of utility functions with no obvious name. You burn context, run grep after grep, and eventually triangulate your way to the right file. It is tedious, and when you hand that work to an AI agent, the token cost of that guessing loop adds up fast.
That is the problem Kilo Code is addressing with the return of codebase indexing. The feature landed via a major contribution from community member shssoichiro, went through weeks of review and stabilization from the Kilo team, and is now available by default in the latest version. What it gives you is a semantic_search tool for the Kilo agent. Instead of running repeated greps, the agent can describe what it wants conceptually and get back relevant files and line ranges in a single call.
The canonical example in the announcement is a marketplace app that uses four different words for the same concept: "customer" in the UI, "kunde" in a German integration, "person" in a CRM schema, and "user" in the auth layer. With grep, an agent needs four separate searches and then has to reason about which results are actually related. With semantic search backed by embeddings, a single query like "customer identity validation" can surface all four because the index understands meaning, not just string matching. That is not a trivial improvement. That is a qualitatively different capability for navigating code at scale.
The implementation uses Tree-sitter to parse code into semantic chunks, functions, classes, and methods, and falls back to line-based chunking for file types it does not have a dedicated parser for. Markdown gets its own parser. Binary files, images, anything over 1MB, node_modules, vendor directories, and files covered by .gitignore or .kilocodeignore are all filtered out. Once an index is built, it stays current incrementally through hash-based caching and re-indexing only changed files. Git branch switches are handled too, so the index tracks the project you are actually working in.
To use it, you need two things: an embedding provider and a vector store. The fastest path is LanceDB as the store combined with either the hosted Kilo provider if you have Kilo tokens, or a free Mistral BYOK key if you do not. The settings UI walks you through the choices without requiring you to hand-edit config files, which I appreciate. The feature is explicitly opt-in and will not start indexing a repo just because an API key exists. That is the right call. You enable it per-project or globally, you wait for the index to reach "Complete" status, and then you start using it.
Key takeaways:
- Semantic search complements, not replaces, exact grep-style search. Use it when you know the concept but not the vocabulary. Use grep when you know the exact symbol or string.
- The feature is opt-in and will not auto-index repos. You choose when and where to enable it, which keeps it from silently chewing through embedding API calls.
- Embedding providers supported include a hosted Kilo option and Mistral BYOK, with local options like Ollama also available for teams that want to keep everything on-premise.
- The implementation is a community contribution from shssoichiro, which is worth noting. A large, production-quality feature landing via an external contributor is a signal about the health of the project.
- The recommended evaluation path is to try it on a codebase where you have already felt the pain of conceptual search, not a toy repo where grep works fine.
Why do I care: As someone who thinks about how AI agents navigate code, this feature addresses a real bottleneck. The context window is finite and precious. An agent burning three hundred tokens on a multi-step grep discovery loop to find retry logic is an agent that has less room to do the actual reasoning once it finds the target. Semantic search front-loads the orientation work cheaply. The opt-in model is sensible given that embedding calls cost money and local embedding setup has real friction. My one watch-out: semantic search quality is only as good as the embedding model and chunking strategy. Tree-sitter chunking is a solid foundation, but large functions that span many behaviors can still produce noisy results. I would treat this as a useful first pass, not a definitive answer, and always read the code before touching it.