Cohere vs Voyage vs Jina vs Qwen3: The Retrieval Model You Can Actually Un-Choose

At a glance

Two hosted APIs and two sets of open weights, and the split does not run where you would expect.

Why this decision is cheap, and why that matters

We argued in the embeddings comparison that the embedding model is the component you cannot cheaply un-choose: vectors from two models sit in different spaces, so switching means re-embedding the corpus, re-tuning every threshold, and re-labelling a golden set whose relevance judgements were made against different neighbours.

The reranker is the exact inverse, and for a structural reason. It is called after retrieval, on a candidate list, and it returns an ordering. It writes nothing. It stores nothing. Swap it and the only artefact that changes is a score distribution — which does mean re-tuning your cut-off, and nothing else. A team can run two rerankers in shadow on live traffic in an afternoon, which is a sentence you cannot write about any other part of a retrieval stack.

That asymmetry should change how you shop. Lock-in risk is what usually justifies a long evaluation, and here there is none, so the correct posture is to pick quickly, measure on your own queries, and re-check in six months when the leaderboard has reordered again. What it should not do is send you to the leaderboard, because the axis the leaderboard measures is the one where your choice matters least.

Cohere Rerank 4 — the flat-rate one

What shipped

Cohere announced Rerank 4.0 in December 2025 in two tiers: rerank-v4.0-pro at $0.0025 per search and rerank-v4.0-fast at $0.002, both trained with a 32,768-token context. That context is the headline upgrade over rerank-v3.5, which ran at 4,096 tokens and $2.00 per 1,000 searches.

The pricing unit is the product

A "search" is one query plus its candidate list, and the charge does not vary with how many candidates you passed or how long they are. Rerank a hundred snippets or twenty long sections, the invoice is identical. For a workload with long documents this is the most forgiving pricing model in the category, and it makes cost forecasting trivial in a way per-token pricing never is.

One wrinkle survives from the older model and is worth knowing before it appears on a bill. When a query-plus-document pair exceeds the model's context, the document is auto-chunked and processed across multiple inferences, and each chunk counts against the request's document budget — the endpoint's limit is expressed as documents multiplied by maximum chunks per document staying under 10,000. At v3.5's 4,096-token context this triggered constantly; at v4's 32,764-token chunk size it almost never does. If you are still on v3.5, check whether your "flat" per-search cost is quietly a per-500-tokens cost.

Where it fits

Cohere is the boring, correct default for a team that wants reranking to be a solved line item: available on the major clouds, wide language coverage, no GPU, no licence question. Independent benchmarking has also consistently placed it among the fastest hosted options.

Voyage rerank-2.5 — the one you can talk to

What shipped

Voyage AI released rerank-2.5 and rerank-2.5-lite on 11 August 2025 as, by their description, the first rerankers with instruction-following. Both support a 32K-token query-document pair with up to 8K for the query itself, and both are priced per token: $0.05 per million for rerank-2.5, $0.02 for the lite variant.

Instructions are the differentiator worth testing

Every other model in this comparison takes a query and a list. Voyage takes a query, a list, and a natural-language instruction about what relevance means for this request — "prefer documents from the last quarter", "rank by procedural applicability, not topical similarity". For an agent this is genuinely new capability rather than a convenience, because an agent's notion of relevance changes between steps of the same task: the same corpus, reranked for "what does the policy say" and then for "what did we actually do", is two different orderings that a single static reranker cannot produce.

Voyage reports rerank-2.5 and -lite as 7.94% and 7.16% more accurate than Cohere Rerank v3.5 across 93 datasets, with a further ~8% from supplying instructions. Those are vendor-published numbers against a now-superseded competitor model, and should be read as "this class of gain is available", not as a current head-to-head.

Where it fits

Reach for Voyage when relevance is conditional on something the query text does not carry, and when your candidates are short. On the agent-shaped workload below it is the cheapest hosted option by a factor of two to five.

Jina Reranker v3.5 — the fast one with the licence problem

What shipped

jina-reranker-v3 is a 0.6B-parameter listwise reranker built on Qwen3-0.6B, using what its authors call "last but not late" interaction: the query and up to 64 candidates go into a single 131K-token context under causal attention, and one forward pass yields contextual embeddings for each candidate. It reports 61.94 nDCG@10 on BEIR at roughly a tenth the size of generative listwise rerankers. Version 3.5 arrived in July 2026 with hybrid attention and self-distillation: 63.20 nDCG@10 on BEIR, 1.22× to 1.56× faster than v3 across context lengths, and a 9.6-point nDCG@10 jump on semi-structured retrieval. It is a drop-in replacement with an unchanged request schema.

Listwise is the architectural bet

Scoring candidates in isolation is the standard cross-encoder design and it has a known weakness: a document's relevance often depends on what else is available. Listwise scoring lets the model see the field before ranking it, which is why the largest v3.5 gains show up on semi-structured data where near-duplicate rows have to be separated. The cost is a ceiling — 64 candidates per pass — and a batching model that behaves differently from a pointwise reranker's under load.

Then read the licence

jina-reranker-v3.5 is published under CC BY-NC 4.0. Non-commercial. The weights are downloadable, the paper is public, the model is excellent, and you may not put it in your product without talking to Jina about terms — while the hosted API remains available on commercial terms. This is the single most consequential fact in the comparison and it appears in none of the leaderboards, because a leaderboard has no column for "may I use this". If your evaluation shortlist was assembled from a benchmark table, check the licence of everything on it before you get attached.

Qwen3-Reranker — the one you can actually deploy

What shipped

Qwen3-Reranker comes in 0.6B, 4B and 8B sizes as part of the Qwen3 Embedding series, covering over 100 languages, released under Apache 2.0 on Hugging Face and ModelScope. It takes an instruction field alongside the query, so instruction-conditioned relevance is available here too, self-hosted.

The licence is the feature

Apache 2.0 with no non-commercial clause and no vendor relationship is a different kind of asset from a model you rent. It can go in an air-gapped deployment, into a regulated environment where an outbound API call is a compliance event, or into a product you ship to customers who run it themselves. Nothing else in this comparison can do all three.

The bill arrives as latency

The larger sizes are not fast. Independent testing has clocked Qwen3-Reranker-4B at over a second per query, against 188ms for the 0.6B-parameter Jina v3 — a gap that is nearly invisible in a chat product and brutal in an agent, for the reason in the next section. Start at 0.6B and only climb if your own evaluation says the accuracy is worth the milliseconds.

Cross-cutting: the billing unit flips the ranking

The two hosted models do not merely charge different amounts, they charge on different axes, and the crossover sits right in the middle of normal usage. On the agent shape — a hundred short candidates from a hybrid search, roughly 200 tokens each — Voyage rerank-2.5 costs about a dollar per thousand reranks against Cohere Rerank 4 Fast's two, and the lite variant costs forty cents. Change nothing but the shape of the candidates — twenty sections of three thousand tokens, the profile of a document-QA system — and Voyage becomes the expensive one at three dollars while Cohere has not moved, because a flat per-search charge has no opinion about document length.

The practical consequence is that no reranker is cheaper than another in general, and any comparison that does not state its candidate profile has told you nothing. Work out your own two numbers — candidates per rerank, tokens per candidate — before reading anyone's pricing page, including this one. The self-hosted pair sit outside this arithmetic entirely: their cost is a GPU you are renting anyway, which becomes decisive above roughly a million reranks a month and irrelevant below a hundred thousand.

Cross-cutting: latency is multiplied, not paid once

In a search box, a reranker runs once and a few hundred milliseconds disappears into the page load. In an agentic retrieval loop, the model reformulates its query and searches again — five, twenty, forty times across a task — and the reranker's latency is multiplied by every one of those. Third-party benchmarking puts Jina Reranker v3 at 188ms, hosted Cohere Rerank 3.5 at around 600ms including the network round-trip, and Qwen3-Reranker-4B above a second. Across forty retrievals that is the difference between adding seven seconds to a task and adding forty.

Three consequences follow. Self-hosting a small reranker next to your index removes a network hop that can be a third of the hosted latency, which is a stronger argument for open weights than the token cost is. Fewer, better retrievals beat more, cheaper ones once the multiplier is in play. And a reranker's latency belongs in your agent's step budget as a line item, not as an implementation detail — treat it the way latency budgeting treats every other hop.

Read those latency figures as directional. They come from different harnesses on different hardware with different candidate counts, and none of them is your workload. They are reliable enough to tell you which order of magnitude you are in, which is the decision they need to support.

Cross-cutting: relevance, and why it is not the deciding axis

On public retrieval benchmarks these models are close, and the ordering is unstable. jina-reranker-v3.5 reports 63.20 nDCG@10 on BEIR against v3's 61.94; Qwen3-Reranker-0.6B sits near 59 on the same leaderboard while the 8B variant scores above jina-v3; Cohere and Voyage publish relative gains rather than comparable BEIR figures at all. The honest summary is a band of two to four nDCG points, reordering by domain and by language.

Set that against the effect sizes elsewhere in the pipeline. Adding any competent reranker to a dense-only retrieval stack is routinely worth ten points or more. Fixing a chunker that splits mid-table is worth more than the entire spread between these four. If you are choosing between rerankers before you have hybrid search and structure-aware chunking, you are optimising the smallest term in the equation.

Which is the argument for treating relevance as a qualifier rather than a ranking. Confirm on your own labelled queries that a candidate model is in the band, then decide on the axes that actually separate them: what the bill scales with, how many milliseconds it adds per hop, and whether the licence lets you ship it.

When to pick which

Further reading

On this wiki:

• Hybrid search and reranking — where the reranker sits and what it is fixing.
• Agentic retrieval — the loop that multiplies the latency.
• Chunking and vector search — the upstream fix that is usually worth more.
• Small and local models — why reranking is the canonical self-host job.
• The embedding model you cannot cheaply un-choose — the mirror image of this decision.

Project sources:

• Cohere Rerank documentation
• Voyage AI: rerank-2.5 and rerank-2.5-lite
• jina-reranker-v3: Last but Not Late Interaction for Listwise Document Reranking
• jina-reranker-v3.5 on Hugging Face
• Qwen3 Embedding: Advancing Text Embedding and Reranking Through Foundation Models