Cora Code Brain Mode: FTS5 meets vector search

Code search is a solved problem if your codebase is small. Open your editor, hit Ctrl+Shift+F, and grep handles the rest. But once a project crosses a few hundred thousand lines, plain text search starts missing things. You search for "rate limiter" and get zero hits because the code calls it ThrottleGuard. You search for ThrottleGuard and find the struct, but not the middleware that wraps it or the config that tunes it. Grep only understands strings, not semantics or structure.

Brain Mode in Cora Code (v0.8.2, MIT, Rust crate cora-code) runs three search engines in parallel and fuses their results. This post covers how each engine works, why they complement each other, and how fusion combines them.

The code search problem

A good code search tool needs to handle three kinds of queries, and no single algorithm handles all three.

First, exact matches. You type fn parse_header and want every file containing that exact string. Fast, deterministic, oblivious to meaning.

Second, semantic matches. You type "function that retries failed HTTP requests" and want the retry loop in http_client.rs, even though none of those words appear in the code.

Third, structural relationships. You find a function and also want its callers, its callees, and the trait it implements. This is a graph traversal problem, not a text or vector problem.

Brain Mode runs all three. FTS5 handles exact matches. Vector search handles semantic matches. Graph BFS handles relationships.

FTS5 for exact matches

Cora Code uses SQLite FTS5 as its exact-match engine. Every indexed symbol and doc comment gets a row in an FTS5 table. Its inverted index means lookups are proportional to matching documents, not total corpus size.

The strength is precision: search for ThrottleGuard and FTS5 finds every occurrence. No embedding model matches that for identifier search, because embeddings compress strings into vectors and lose exact character sequences.

The weakness is recall on conceptual queries. Search for "rate limiting" and FTS5 returns nothing if the code uses "throttle" or "backpressure." That gap is what vector search fills.

Vector search for semantic matches

Brain Mode embeds every code chunk into a 256-dimensional vector using a code-aware embedding model, stored in a usearch HNSW index. When a query comes in, it embeds the query and runs KNN search by cosine similarity.

The embedding for "function that retries failed HTTP requests" lands close to the actual retry loop, even if none of those words appear in the code. The model learned that retry loops, exponential backoff, and HTTP error handling are semantically related.

The trade-off is precision. A search for ThrottleGuard might return RateLimitMiddleware at rank 2 and BackoffStrategy at rank 3. Semantically related but not what you asked for. For exact identifier lookup, FTS5 is more reliable.

usearch with HNSW trades a small amount of recall for a large speedup over brute-force KNN. Query latency stays under 10ms for indexes with tens of thousands of chunks.

Graph BFS for relationships

The third signal is structural. Cora Code builds a code graph during indexing with symbols as nodes (functions, structs, traits, modules) and relationships as edges (calls, implementations, imports, re-exports).

When Brain Mode finds initial candidates from FTS5 and vector search, it runs breadth-first search along graph edges to include structurally related code that neither text nor vector search would surface.

If FTS5 finds ThrottleGuard, graph BFS also returns the middleware that calls ThrottleGuard::check(), the config struct that feeds it parameters, and the trait it implements. These neighbors are invisible to FTS5 (no matching text) and invisible to vector search (not semantically similar). But they are exactly what a developer needs to understand the code in context.

RRF fusion

Each engine produces a ranked list. FTS5 ranks by BM25. Vector search ranks by cosine similarity. Graph BFS ranks by hop distance. These scores are on different scales, so you cannot add them up.

Brain Mode uses Reciprocal Rank Fusion (RRF) with k=60. For each result, it computes 1 / (k + rank) from each list, then sums those scores. The k=60 constant dampens the advantage of top-ranked results so a rank-1 hit in one engine does not overwhelm rank-2 and rank-3 hits in another.

RRF needs no score calibration. BM25 and cosine similarity are not comparable, but RRF only uses ranks. It also rewards agreement: a chunk near the top of two or three lists gets a higher fused score than one in only one list. A chunk that FTS5 ranks first, vector search ranks third, and graph BFS finds at hop 1 will outrank a chunk that only FTS5 found.

The fused list is what Brain Mode returns, whether through the CLI or the MCP server with its 15 tools.

Performance

The three engines run in parallel. FTS5 and HNSW KNN each complete in single-digit milliseconds. Graph BFS is bounded to a configurable depth, usually 2 hops. RRF fusion is trivial: a few hundred scores summed in microseconds.

End-to-end, Brain Mode returns results in under 50ms. All indexes are local, no network round-trips. The embedding model runs locally too (BYOK, your configured provider).

When to use Brain Mode

Brain Mode is the default search in Cora Code. Use it when exploring an unfamiliar codebase, searching by concept, or needing to understand how code connects to the rest of the project.

If you know the exact identifier and want every occurrence, plain FTS5 is faster. Brain Mode adds value when the query is ambiguous, conceptual, or structural. That is most queries in practice.

The 12 deterministic code review rules and the MCP server with 15 tools both lean on Brain Mode. When a review rule checks whether a function has tests, Brain Mode finds the function, its tests, and related helpers in one fused pass.

Brain Mode is available in Cora Code v0.8.2 on crates.io and GitHub. Crate cora-code, MIT license.