Why not vector search?

[BradKML]

This might sound like an amateur question, but worth having in the Readme. Why is fuzzy search (like the ones in fzf better than the usual ChromaDB or whatever is out there) when it comes to getting needed information that is somewhat vague in definition e.g. documentation? https://github.com/LuotoCompany/cursor-local-indexing

[johnhuang316]

Great question! Because I wanted something lightweight that just works without heavy setup.

Most of my code searches are pretty straightforward - finding function definitions, seeing where something gets called, or searching for partial symbol names. When I search for "getUserData", I want getUserData(), getUserDataAsync(), etc. - not semantically similar functions that might not be what I need.

The performance difference is pretty significant too - fuzzy search gives me results in 10-50ms with consistent results, while vector search takes 100-500ms and can vary based on context.

Vector search definitely has its place for conceptual queries like "how does auth work?", but for day-to-day development I usually know part of what I'm looking for already.

I am planning to expand the index structure to help LLMs analyze projects better - more relationship mapping, enhanced call graphs, better dependency organization. Still keeping it lightweight and structure-based though.

You're right that tools like ChromaDB have made vector databases much more accessible, so I'm keeping an open mind about hybrid approaches for specific use cases.

That's my two cents on it, anyway.

[BradKML]

10x slowdown, thus vector indexing should only be done in downtime (I guess) and then pull stuff up from lightweight machines need further optimization based on the use case of documentation vs code.

If only documentation needs to be indexed, then the documentation should update based on code changes, making it as close to "live" as possible when indexing. But then it would require some kind of standard prompt structure to encapsulate the intricacies of the codebase across different languages like Python vs TS vs Rust vs Golang...

Yeah, if I have a say in the matter, tools like LocalIssues or TaskMaster or Memory would need to be mixed in, no matter it is Claude Code (or whatever copycat there is), Cusor/Windsurf, or RooCode/Cline/KiloCode... or even OpenHands and other agents. Still figuring out how they can interconnect.

Personal shortlist to see what is up at the moment

• https://github.com/Davidyz/VectorCode
• https://github.com/anrgct/autodev-codebase
• https://github.com/helixml/kodit

[johnhuang316]

Hi @BradKML ,
You're right, the sync issue is the problem.

My approach is to rely on the LLM to figure out it needs a fix. I wrote a detailed docstring for the refresh_index tool, basically as instructions for the model.

@mcp.tool()
def refresh_index(ctx: Context) -> str:
    """
    Manually refresh the project index when files have been added/removed/moved.
    
    Use when:
    - Files were added, deleted, or moved outside the editor
    - After git operations (checkout, merge, pull) that change files
    - When find_files results seem incomplete or outdated
    - For immediate refresh without waiting for auto-refresh rate limits
    
    Important notes for LLMs:
    - This tool bypasses the 30-second rate limit that applies to auto-refresh
    - Always available for immediate use when you know files have changed
    - Performs full project re-indexing for complete accuracy
    - Use when you suspect the index is stale after file system changes
    
    Returns:
        Success message with total file count
    """

So the theory is, when the file index is obviously stale, the LLM should read that description and decide to call the tool itself to fix it.

But it's not a hardcoded rule—it's totally up to the model's judgment. So it's not 100% reliable.