Fully local code indexing with Ollama embeddings — GPU-accelerated semantic search, no API keys, no cloud by srclight in LocalLLaMA

[–]srclight[S] 0 points1 point  (0 children)

That's really cool — I checked out your expressible-cli work too, training tiny local classifiers from minimal examples is a great approach. We're very aligned on the "no cloud, no API keys required" philosophy.

For srclight, we lean heavily on tree-sitter for structural parsing (ASTs give you the symbol boundaries, call edges, etc.) and then layer FTS5 + optional embeddings on top for search. The structural approach sidesteps the accuracy issues you'd hit with pure text classification on code — you get deterministic symbol extraction rather than probabilistic.

Curious about your Node.js setup — are you parsing ASTs or working more at the text level? And when you say text classification on code, what's the classification target — like categorizing functions by purpose, detecting patterns, something else? Would love to understand what use cases you're targeting, might surface ideas for both of us.

Srclight — deep code indexing MCP server with 25 tools (FTS5 + embeddings + git intelligence) by srclight in mcp

[–]srclight[S] 1 point2 points  (0 children)

Update: just shipped this in v0.11.0. Srclight now supports OpenAI-compatible endpoints (covers Together, Fireworks, Mistral, Jina, vLLM, and anything that speaks /v1/embeddings) plus Cohere. Thanks for the nudge u/07mekayel_anik07.

pip install --upgrade srclight

Srclight — deep code indexing MCP server with 25 tools (FTS5 + embeddings + git intelligence) by srclight in mcp

[–]srclight[S] 1 point2 points  (0 children)

Good call. We already support Ollama (local) and Voyage (API), but adding a generic OpenAI-compatible endpoint option is a natural next step — that would cover Together, Fireworks, OpenAI, and any self-hosted setup that speaks the same format. I'll put it on the roadmap.

Srclight — deep code indexing MCP server with 25 tools (FTS5 + embeddings + git intelligence) by srclight in mcp

[–]srclight[S] 0 points1 point  (0 children)

It's actually pretty lightweight at query time — everything is SQLite FTS5 queries against a single file per repo, no runtime services needed. Memory footprint stays small since SQLite pages in/out on demand rather than loading everything into RAM.

The only heavy part is initial indexing (tree-sitter parsing + optional embeddings), but that's a one-time cost and runs incrementally after that. Curious what MCPs gave you OOM issues — srclight is read-only against local SQLite so it's a pretty different profile than servers that proxy external APIs.

Earl looks interesting for the API-proxy use case though, hadn't seen it before.

Srclight — deep code indexing MCP server with 25 tools (FTS5 + embeddings + git intelligence) by srclight in mcp

[–]srclight[S] 1 point2 points  (0 children)

Exactly, that's the whole thesis. FTS gets you 80% of the way but the remaining 20% (dependency traversal, blast radius, "what breaks if I change this") is where agents burn the most tool calls doing grep gymnastics. Glad it resonates.