Quick answer: Superlinked SIE is the best Cohere Rerank alternative for teams that must keep
documents in their own environment, because reranking runs on your GPUs beside the embedder under
Apache 2.0. Jina Reranker is the nearest hosted drop-in, Voyage suits domain-specific relevance,
Mixedbread publishes weights that self-hosted servers already carry, and Infinity is the lightest
container.
The relevance regression was discovered by a customer, on a Friday. Anyone who has moved a reranker
between providers knows why that story is common. Reranking is the last step before the answer, its
effect is invisible in aggregate metrics, and a model swap that looks fine on a test set can reorder
exactly the queries your most demanding users run.
So this article is organised around the switch rather than around the category. If you are choosing a
reranker for the first time, the companion piece comparing reranking tools generally is the better
starting point. If you are already on Cohere Rerank and want out, maybe for cost, for latency, or because
the documents cannot leave, then the interesting questions are what changes on the day, how you prove
relevance did not regress, and what you take on that Cohere was handling.
Worth naming what you are leaving. Cohere publishes dedicated-instance pricing that most of this market
does not. $5.00 dollars per hour or $3,250 per month for a medium Rerank 3.5, 4 Fast, or 4 Pro instance.
$10.00 dollars per hour or $6,500 per month for a large Rerank 4 Pro. It also supports private deployment
for enterprise customers. Any alternative should be measured against that, not against a strawman. As
throughout this series, the subject is the model doing the reranking rather than the vector database
holding your index.
Superlinked SIE
Apache 2.0, self-hosted, and the GPUs and the Kubernetes cluster are on your side of the boundary. The
switch Superlinked offers is not one hosted vendor for another. It moves the
relevance step onto hardware you control, so the candidate documents being scored never leave your
environment.
For a pipeline that already self-hosts embedding, this is close to free in infrastructure terms. Score
is one of the engine's three primitives, so the reranker runs on the same cluster and the same pooled
GPUs, loading on demand and evicting least-recently-used alongside everything else. The
catalog lists Qwen/Qwen3-Reranker-4B, BAAI/bge-reranker-v2-m3,
and mixedbread-ai/mxbai-rerank-large-v2 among its rerankers, which spans the range most teams
evaluate.
Models outside the catalog are added with a small YAML file naming Hugging Face weights, provided the
architecture matches a shipped adapter. Cross-encoders are on that list, which is the relevant one for
reranking.
Honest take: Leaving a hosted reranker means owning relevance evaluation permanently. Cohere ships a
model that is good out of the box and improves without your involvement; a self-hosted reranker is a
model choice, an evaluation harness, and a regression suite that somebody maintains from now on. That is
a real cost and it is the honest price of the switch. What you get for it is the second retrieval hop
running inside your own boundary on GPUs you already own, which for teams that self-host the embedder is
usually the arrangement they wanted in the first place.
Jina Reranker
Hosted API with open weights across part of the family, commercial, and nothing to operate. This is the
nearest drop-in on the page: a hosted reranking endpoint that replaces one API call with another, which
makes it the lowest-effort switch available.
jina-reranker-v3 is the current model, using a late-interaction approach to scoring. If your embedder
is also Jina, the consolidation is genuine. You get one provider, one key, one bill, and rate limits
shared across both stages at 100 thousand tokens per minute free, 2 million on paid, and 50 million on
premium.
Two things to check before committing. Dollar rates are not published on the model pages, which makes a
cost-driven migration harder to justify in advance than it should be. And because Jina publishes open
weights for several models, the comparison here is specifically with the hosted API rather than with the
models. Some can be run yourself, but that is a different decision with a different cost structure.
Voyage AI rerank
Hosted API, commercial, nothing to run. rerank-2.5 is the current generalist reranker from Voyage AI,
now published as Voyage AI by MongoDB. It is the alternative to pick when the motivation for leaving
Cohere is quality on a specific domain rather than cost or data locality.
Voyage builds specialised models, and reranking is where specialisation pays most visibly, because
judging relevance in context is precisely the task where domain knowledge separates a good model from an
adequate one. For legal, financial, or code corpora it belongs on any serious evaluation shortlist.
The practical cautions are two. Pricing is not published, so the comparison against Cohere's very public
dedicated-instance rates cannot be made without contacting them. And the Atlas Embedding and Reranking
API is currently in preview with an explicit instruction not to use it in production during that period,
a statement about that endpoint rather than about the models, and worth clarifying for whichever surface
you intend to call.
Mixedbread
A hosted multimodal search platform, with models that also exist as open weights. Mixedbread offers a
unified API across text, PDFs, tables, images, and video in more than a hundred languages, and it
announces mxbai-rerank-v3-listwise as its current listwise reranker.
There is a fact about this vendor worth stating explicitly, because it changes how the comparison should
be read. mixedbread-ai/mxbai-rerank-large-v2 is in Superlinked's model catalog. Mixedbread publishes
reranking models good enough that a rival inference server ships them, and the comparison on this page is
therefore with the hosted platform, not with the weights. If you self-host, you may well end up running
their model regardless of which server you choose.
The limits are informational. Neither pricing nor model licensing is published on the vendor's site at
the depth this comparison requires, so both need confirming directly before the platform enters a
decision. The models themselves need no such caveat, since other people are already serving them.
Infinity
MIT-licensed, self-hosted, and a container is the whole deployment. For a team leaving a hosted reranker
and wanting the smallest possible replacement, this is it, and there is no meaningful competition for
that particular position.
Rerankers and embedders run in the same process, so both retrieval stages share one container and one
card. Any model from Hugging Face can be deployed without a catalog check, which matters for teams
migrating to a specific model they have already evaluated, and the backends span PyTorch, ONNX,
TensorRT, and CTranslate2 across CUDA, ROCm, CPU, AWS Inferentia, and Apple silicon.
What comes with the small size is the absence of a platform. There is no autoscaling, no multi-node
deployment, and no operational tooling around it, so anything beyond one container is your own
engineering. For a reranking workload with predictable volume, that is often genuinely sufficient.
Xinference
Apache 2.0, run on hardware you own, with a cluster to operate. It fits this migration when reranking is
not the only thing being brought in-house: the same control plane covers rerankers, embedders, language
models, and audio behind one OpenAI-compatible interface.
Because the API follows the OpenAI convention across every model type, the migration work resembles the
one you are already doing, such as changing a base URL and a model name, rather than adopting a new
integration pattern per model. Several execution engines sit underneath, so hardware coverage stays
broad, and multi-node deployment is supported without a Kubernetes-native platform.
The recurring caution applies. GPU memory behaviour across many simultaneously registered models is not
documented, and for a migration that puts a reranker onto a card already holding an embedder, that is the
specific thing that determines success. Test it with your models before the cut-over rather than after.
Frequently asked questions
As a search engineer, how do we prove relevance did not regress after switching?
Build the evaluation set before you switch, not after, because afterwards you will be comparing against
memory. Collect a few hundred real queries with the documents that should be returned, weighted toward
the queries that matter commercially rather than sampled uniformly. Score the current reranker on that
set to establish a baseline, then score each candidate identically. Look at ordering metrics rather than
recall, since reranking cannot improve recall by definition. Then, before release, run both models in
parallel on live traffic and compare the ordering they produce on the same queries. The disagreements are
where the regressions hide.
As an AI engineer, is the API shape compatible?
Broadly, and the differences are exactly the kind that cause quiet problems. Most rerank APIs take a
query and a list of documents and return scored indices, so the request structure translates without
much work. What varies is score normalisation, whether scores are comparable between models, maximum
document counts per request, truncation behaviour for long documents, and how ties are ordered. If your
application has any threshold tuned against the current provider's score distribution, a cut-off below
which results are discarded, that threshold is meaningless after a switch and must be re-derived.
As a CTO, why would we leave a working reranker?
Frequently you should not, and it is worth being clear about that before spending engineering time. There
are three good reasons. Volume, where per-call billing has grown past the cost of running the model
yourself. Data locality, where sending candidate documents to a third party has become unacceptable for
reasons that are not going to change. And portability, where the risk of a model being deprecated
underneath a tuned pipeline is worth removing. Convenience is not on that list, and neither is a
benchmark result. If none of the three applies, the honest recommendation from an article about
alternatives is to stay where you are. The Superlinked blog makes the
self-hosting case for the teams where they do apply.
Which one should you pick
Sort by why you are leaving. Cost alone points at the self-hosted options, and Infinity is the cheapest
credible landing place if reranking is all you need. Domain quality points at Voyage. A desire for the
least possible work points at Jina, which is a hosted-for-hosted swap. And data locality, which is the
reason that does not go away, points at running the model yourself, where Superlinked's
approach puts the reranker on the same cluster as the embedder rather than
making it a second project. Whichever it is, build the evaluation set first. Fridays are bad days to
learn about relevance.
Top comments (0)