Ory Ships a Local Semantic Search Engine That Makes Claude Code Faster and Cheaper
Claude Code's default code discovery method is brittle. It uses grep, glob, and find, all of which depend on exact string matches. When a codebase is small, that works fine. As the project grows, Claude guesses file and function names, misses, and retries. Each failed guess costs tokens, adds latency, and inflates API bills. Ory built a tool to fix this. Ory Lumen is a local semantic search engine that plugs into Claude Code as an MCP server, letting the model find code by meaning rather than exact text.
The core issue is that LLMs do not maintain a persistent map of a codebase. Every session starts fresh. The agent re-reads files, re-discovers structure, and rebuilds context from scratch. For small projects this overhead is negligible. For large monorepos it becomes a real cost problem. Aeneas Rekkas, Ory's founder and CTO, noticed this firsthand as Ory's own codebase grew. Claude Code sessions got longer and more expensive because the agent kept opening files to inspect them one by one.
How Lumen Works Under the Hood
Lumen runs entirely on local hardware. There are no API calls to external embedding services. The embedding backend uses either Ollama or LM Studio with the ordis/jina-embeddings-v2-base-code model. The index lives at ~/.local/share/lumen/
On startup, Lumen walks the project and chunks files into semantic units like functions, methods, and types. Go code uses the native AST parser. All other languages use tree-sitter grammars. The chunks are embedded and stored in SQLite with sqlite-vec for vector search. When Claude needs to find relevant code, it calls semantic_search and gets back matching chunks without opening files.
The re-indexing strategy uses a Merkle tree built over file hashes. On subsequent sessions, only changed files get re-chunked and re-embedded. For large codebases, the initial index takes time but re-indexing after that drops to seconds. This makes it practical for active development where files change frequently.
Benchmark Results Across Eight Languages
Ory evaluated Lumen with a SWE-bench-style harness. Real GitHub bugs from real open-source projects. Claude fixes them with and without Lumen. A blind judge rates patches against the known-correct fix. The benchmark suite covers Go, JavaScript, PHP, Python, Ruby, Rust, TypeScript, and C++, all at hard difficulty.
Across all eight languages, Lumen reduced costs in every single task. Quality stayed the same, zero regressions. The average cost reduction was 26%, and average time reduction was 28%. The most consistent signal was output token reduction, meaning Claude spends less time exploring and more time acting when it has semantic search available.
JavaScript showed the biggest gains: 33% cost reduction, 53% time reduction, and 66% output token reduction, all while maintaining Perfect quality. Rust hit the highest cost savings at 39% with a 34% time reduction. TypeScript and PHP both cut costs by 27% and time by roughly a third. Python saved 20% on cost and 29% on time. Go and C++ showed smaller improvements, 12% and 8% cost reduction respectively, but still maintained quality. C++ actually increased output tokens by 42% on a feature task, though quality remained the same.
One notable detail: on a Rust task that was too hard for both approaches, Lumen still reduced the cost of failure. The agent failed faster and cheaper instead of burning through expensive retries.
Installation and Setup
Ory launched a Claude plugin marketplace alongside Lumen. Installing takes two commands inside Claude Code:
```bash
/plugin marketplace add ory/claude-plugins
/plugin install lumen@ory
```
The plugin downloads its binary from the latest GitHub release, indexes the project on next session start, and registers the semantic_search tool. Claude picks it up without extra configuration. The only prerequisite is having Ollama installed and pulling the embedding model:
```bash
ollama pull ordis/jina-embeddings-v2-base-code
```
Two built-in skills ship with the plugin: /lumen:doctor runs a health check, and /lumen:reindex forces a full re-index after large refactors.
Why Local-First Matters for Code Search
The decision to keep everything local is deliberate. Sending source code to an external embedding API should be an opt-in engineering choice, not a default. Lumen runs on local hardware with open-source models. Embeddings never leave the machine. This also makes it usable in air-gapped environments, which matters for companies that run self-hosted infrastructure.
The tradeoff is that local embedding is slower than cloud-based alternatives. But the benchmarks show the time savings from better code discovery more than offset the embedding overhead. For most projects, the net result is faster sessions and lower costs.
What This Means for AI-Assisted Development
The pattern Ory identified applies broadly. As codebases grow, agents that rely on exact-match search degrade in both speed and cost. Semantic search changes the economics by letting the agent reason about code structure instead of pattern-matching file names. The 26% average cost reduction and 28% time reduction across eight languages make a strong case for this approach.
Lumen is a new project with rough edges, as Ory acknowledges. The benchmarks are reproducible, and the full methodology and raw data are published. For teams spending significant money on AI coding assistants, the math is straightforward: better code discovery means fewer wasted tokens, faster task completion, and lower bills.