# Why We Upgraded Code Search to voyage-4-large

Canonical source: https://maguyva.ai/blog/upgrading-code-search-to-voyage-4-large

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Date: 2026-06-09 · Author: Maguyva Team

> We moved our code embeddings to voyage-4-large — currently top of the public RTEB code retrieval leaderboard. The honest version: the trade we make, what we actually index, and why we pay for premium embeddings.

> *Benchmark numbers in this post reflect the RTEB leaderboards at publication (June 2026). Leaderboards move; treat the rankings as a snapshot, not a permanent fact.*

Semantic search is only as good as the embeddings underneath it.

When an agent asks Maguyva "where do we handle retries," it is not grepping for the word "retry." It is asking for the *meaning* — the backoff loop, the circuit breaker, the thing that wraps a flaky call. That question gets answered by a vector model that turns code into a point in space and finds the neighbors. Pick a better model and every semantic query in the product gets quietly sharper.

So we changed ours. As of June 2026, Maguyva's code embeddings run on **`voyage-4-large`**, replacing `voyage-code-3`.

## The Benchmark

We did not make this call on vibes. The public [Retrieval Embedding Benchmark (RTEB)](https://embedding-benchmark-rteb.hf.space/code) ranks embedding models on real retrieval tasks, and on its **Code** leaderboard `voyage-4-large` sits at **#1 overall (90.86)** — ahead of `gemini-embedding-2-preview` (90.26) and, notably, ahead of the model we were already using, `voyage-code-3` (89.73, #3).

That is a small absolute gap. But it is a gap in the right direction, on a public benchmark, on the exact task we care about: retrieving code by meaning.

## The Trade We Accept: Binary Quantization

Here is the part most "we upgraded our model" posts leave out.

Maguyva does not store full-precision vectors. We store **binary-quantized** embeddings: each 2048-dimensional vector collapses to a 2048-bit signature — **256 bytes per vector**. Those signatures are searched with Hamming distance, indexed and partitioned per tenant.

That is a deliberate trade. Binary quantization gives up some retrieval precision in exchange for dramatically smaller storage and fast, cheap distance math with no separate vector database to operate. For a product that indexes whole repositories per workspace, that economics matters more than squeezing out the last fraction of a benchmark point.

`voyage-4-large` fits this design without forcing a migration of the storage layer: it produces 2048-dimensional output, same as `voyage-code-3`, so our `bit(2048)` columns and Hamming search path did not change. The model got better; the schema stayed put.

## Code Was Just the Start

Maguyva is a code-intelligence tool. But we're also customer zero, and we point it at something else: the markdown that lives in our repos alongside the code. Architecture decision records, runbooks, contracts, finance and policy docs — all of it version-controlled in Git, all of it behind the same MCP server, a semantic index over the *documents*, not just the source.

That is exactly why voyage-4-large's breadth matters. On the same RTEB family of leaderboards it is **#1 on finance, #1 on healthcare, and #1 on overall text retrieval** — ahead of Google's Gemini Embedding, Cohere's Embed v4, and OpenAI's text-embedding-3-large. (Voyage is a co-creator of RTEB, so we read it as a strong public signal rather than a perfectly neutral referee — but it is benchmarked head-to-head against every major commercial model, on private hold-out sets.) The same index that finds the right function for an agent finds the right clause in a contract or the right line in a policy — and on those domains, voyage-4-large isn't a compromise, it's the leader.

## Why We Pay for Premium Embeddings

There's a cheaper way to do search, and a lot of it is free. Lexical search — BM25 and its kin — matches keywords, runs locally, and costs nothing. Open-source embedding models like BGE, Nomic, and embeddinggemma give genuinely *decent* semantic retrieval, and you can self-host them for the price of a GPU. Maguyva uses the free side too: every query fuses text, AST, graph, and semantic search. What we don't cheap out on is the semantic layer.

We pay per token for premium embeddings — `voyage-4-large` — instead of self-hosting a free model, for two reasons. First, keyword search alone can't answer "where do we handle retries" when the code says `backoff` and `circuit breaker` and never says the word "retry" — meaning is the whole point of the embedding, and on the domains we serve the open models trail the premium ones: a couple of points behind on general text, and further behind in niches like code, contracts, and finance. Second, in our experience retrieval quality shapes the final answer more than the model on the other end does — a strong agent handed the wrong context still answers wrong, and it never sees the document it was never given.

So premium embeddings are a per-token bill that scales with every repo and document we index — and we pay it on purpose. For the outcome our users get, the right function or the right clause, we think that trade is worth it.

## The Honest Part

Voyage's own documentation still labels `voyage-code-3` as the code-optimized model. So why move?

Because we read the public benchmark, not just the vendor's model table, and the benchmark put `voyage-4-large` on top for code retrieval. This was a forward-looking call: take the newer, generally stronger model and validate it against a public leaderboard on the tasks that matter. We're comfortable making that bet because the evidence is broad — voyage-4-large doesn't just win on code, it leads on finance, healthcare, and overall retrieval too.

## The Quiet Floor

Every tool we expose — semantic search, task-context gathering, grounded Q&A — bottoms out in retrieval. When the retriever improves, the agent on the other end gets better evidence, makes fewer wrong turns, and grounds its answers in the right code — or the right clause, or the right policy. A sharper embedding model is not a flashy feature. It is the floor under everything else, and we just raised it. You won't notice. That's the point.