Embedding models 2026 — OpenAI, Cohere, Voyage, open source

The embedding model is the decision in a RAG pipeline that calcifies first. Chunking strategy can be re-tried in a weekend. Vector database can be migrated in an afternoon. Re-embedding a million-chunk corpus with a different model, however, costs real money and real time — which is why most teams pick an embedding model early and stay with it for years. Picking the right one up front matters more than any other RAG decision.

This article covers the four hosted embedding APIs most teams actually ship with in late 2026, the four open-source models worth considering for self-hosting, and the three axes that should drive the pick.

What an embedding model is choosing between

An embedding model takes a chunk of text and outputs a fixed-length vector of floats (384 to 3,072 dimensions depending on model). Chunks with similar meanings sit close in that vector space; unrelated chunks sit far apart. “Similar” is defined by whatever the model was trained to minimise, which varies — some models are trained for general semantic similarity, some for retrieval specifically, some for domain-specific text (code, legal, biomedical).

Three factors determine real-world retrieval quality on a specific corpus:

1. Dimensionality. Higher dimensions can encode more nuance but cost more to store and search. 384-768 is enough for most workloads; 1,536+ matters for domain-nuanced retrieval.
2. Training data overlap with your corpus. A model trained on general web text works well on general web text. On legal contracts, biomedical research, or source code, domain-specific models often beat the generalists.
3. Query-document asymmetry handling. Some models (BGE, Nomic) treat questions and documents differently — questions are embedded with a prefix like query:, documents with passage:. Models trained this way outperform symmetric ones on question-answer retrieval.

Benchmarks like MTEB report average quality across many tasks. Average rankings often do not predict quality on a specific workload. Benchmark on your own data before committing.

The four hosted options

Hosted embedding APIs are the right default when the corpus fits a cost budget, the latency of an external call is acceptable, and operational simplicity matters more than per-call cost.

OpenAI — text-embedding-3-small and text-embedding-3-large

The default pick for most English-language RAG in 2026. Two models, same API shape:

• text-embedding-3-small — 1,536 dimensions (configurable down to 256), roughly $0.02 per million input tokens. Fast, cheap, good enough for most workloads.
• text-embedding-3-large — 3,072 dimensions (configurable), roughly $0.13 per million tokens. Noticeably better on technical corpora and long-form content.

The configurable-dimensions feature (via the dimensions parameter) is important: a 1,536-dim embedding compressed to 512 dims performs within a few percent of full for most tasks, cuts storage by 3x, and cuts query latency on large indexes. Treat it as the default compression knob rather than running at full width.

Downsides: English-centric, closed weights, cost scales linearly with volume. For organisations that cannot send corpus data to OpenAI, this is a non-starter.

Cohere — embed-v3-english and embed-multilingual-v3

The strongest hosted option for multilingual corpora. 1,024 dimensions, roughly $0.10 per million tokens for both English and multilingual variants. Cohere’s embeddings have query-document asymmetry built in: input_type="search_query" for questions, input_type="search_document" for stored content. Using the right input type gives a 5-15% quality lift over asking the same model to embed both.

Downsides: pricing sits between OpenAI small and large; the Cohere ecosystem is smaller than OpenAI’s for downstream tooling.

Voyage AI — voyage-3 and voyage-3-code

The 2026 upstart that routinely tops MTEB-style leaderboards. 1,024 dimensions, roughly $0.06 per million tokens — cheaper than Cohere, often higher quality than OpenAI small for retrieval tasks. A code-specific variant (voyage-3-code) is one of the few models trained specifically for source code retrieval and reliably beats the generalists on that workload.

Downsides: newer provider; smaller ecosystem; API availability and SLAs still proving out at the scale OpenAI and Cohere have.

Jina AI — jina-embeddings-v3

Strong free tier (up to several million tokens/month). 1,024 dimensions. The right pick for teams that want hosted convenience without the OpenAI/Cohere pricing floor.

Downsides: free-tier limits require upgrading to paid at modest scale; quality is strong but not best-in-class for English.

The four open-source options for self-hosting

Running embeddings on your own GPU (or CPU for small models) is cheaper at scale, keeps corpus data in-house, and sometimes beats hosted options on domain-specific text.

sentence-transformers — all-MiniLM-L6-v2 and all-mpnet-base-v2

The baseline. all-MiniLM-L6-v2 is 384 dimensions, runs on CPU, embeds 1,000 chunks in a few seconds, works well for general English. all-mpnet-base-v2 is 768 dimensions, slightly better quality, slightly slower. Both are free, open-weight, and have been the default self-hosted choice since 2021.

Downsides: smaller models, so quality trails the hosted options on nuanced retrieval. English-dominant.

BGE — BGE-M3 and bge-large-en-v1.5

BAAI’s open-weight embedding family, consistently near the top of MTEB benchmarks. BGE-M3 supports multilingual, long-context (up to 8K tokens), and dense + sparse + multi-vector output in one model. For teams that want hybrid search without running two separate models (BM25 + dense), BGE-M3 is the single-model solution.

Downsides: larger model, needs a GPU for reasonable batch throughput. More sophisticated to deploy than sentence-transformers.

Nomic Embed — nomic-embed-text-v2

Open-source, Apache 2.0 licensed, 768 dimensions, Matryoshka representation learning (embeddings can be truncated to 128 or 256 dims with graceful quality loss). The right pick when a fully-permissive licence matters AND quality close to hosted options is required.

Downsides: smaller community than sentence-transformers or BGE.

Qwen3-Embedding — multilingual + long-context

Alibaba’s 2026 release. Strong on Asian languages and long documents (8K+ tokens per chunk). The pick for multilingual corpora where Cohere’s hosted option is not viable.

Downsides: licence terms vary by model size and vendor; verify compatibility before shipping commercially.

The three axes to pick on

Axis 1 — Cost at steady state

For a 1-million-chunk corpus re-embedded quarterly (say the chunks average 500 tokens, so 500M tokens per re-embed):

Numbers are approximate at late-2026 prices; verify current rates. For small corpora, cost is noise — the choice is driven by quality. For 10M+ chunks, cost becomes a real factor and the self-host options start to pay for themselves.

Axis 2 — Hosting constraint

Three constraints are decisive:

• Corpus data cannot leave your environment (compliance, confidential customer data) → self-host only.
• No GPU budget / small team / fast setup → hosted only.
• Latency < 50ms per embed call matters → either self-host or geo-closest hosted region.

If any one of these is a hard constraint, it narrows the field to 1-2 options.

Axis 3 — Quality on your corpus (the only real benchmark)

MTEB leaderboards average across many tasks; your workload is one task. The right benchmark is a 50-100 question eval set from your corpus, run through 2-3 candidate models, scored on recall@k. Spend an afternoon on this before committing — the ranking on your corpus is often different from the public ranking.

Decision table

Three mistakes to avoid

1. Mixing embedding models for queries and documents. Both must be the same model and same prompt convention. A query embedded by text-embedding-3-small searching against documents embedded by voyage-3 returns garbage.

2. Re-embedding on every chunker tweak. Delta-reindex detection (compare chunk content hashes, only re-embed changed chunks) saves 90-99% of embedding cost during chunker iteration. See the handbook’s Chapter 2 for the pattern.

3. Trusting MTEB rank order on your workload. Benchmark on 50-100 of your own questions before locking in a choice. The MTEB-top-ranked model is often not the top on a specific corpus.

Bottom line

For a 2026 RAG system starting fresh and in no hurry, the default stack is: OpenAI text-embedding-3-small if hosted is acceptable, Voyage voyage-3 if quality-per-dollar matters more than ecosystem, BGE-M3 if self-hosting with hybrid search is the goal, sentence-transformers all-MiniLM-L6-v2 if the prototype needs to run on a laptop for free.

The embedding model is the one decision in RAG that is painful to walk back. Benchmark two candidates on 50 real questions from the actual corpus before committing — the hour spent on that evaluation is the highest-ROI hour in the entire pipeline.

Related reading:

• Build a RAG pipeline from scratch — the pipeline the embedding model plugs into
• RAG chunking — 5 strategies with runnable Python — step before embedding
• Vector databases compared — pgvector, Qdrant, Pinecone, Chroma — where the embeddings live
• Hybrid search for RAG — BM25 + vector beats pure vector — the retrieval layer above embeddings
• Evaluating RAG — retrieval + generation metrics — how to actually benchmark two embedding models on your corpus