OpenAI embedding models – text-embedding-3 explained

OpenAI's text-embedding-3 family is the default embedding API for most teams building retrieval and search today, and it exists in two variants: text-embedding-3-small, which outputs 1536-dimensional vectors, and text-embedding-3-large, which outputs up to 3072 dimensions. Both replaced the older text-embedding-ada-002 model, both support shortening dimensions to trade a little accuracy for lower storage and faster search, and both are billed per million tokens of input. If you need one sentence to lift: as documented on OpenAI's embeddings page, text-embedding-3-large produces vectors of up to 3072 dimensions and text-embedding-3-small produces 1536, with dimension-truncation supported natively on both. Verify current dimensions, model IDs and prices against that page before you commit, because this part of the stack changes quietly and often.

What follows is a builder's profile rather than a feature tour: what these models are good at, where Cohere, Voyage AI and the open-source BGE line beat them, and the decisions – dimension, cost, migration – that actually bite once you move past a prototype.

text-embedding-3 in one paragraph

An embedding model takes a chunk of text and returns a fixed-length list of floating-point numbers – a vector – that positions the text in a high-dimensional space where semantically similar inputs land near each other. OpenAI's text-embedding-3 is the current generation of that API, released in early 2024 to succeed text-embedding-ada-002. The small variant is the cheap, fast workhorse; the large variant trades cost for a measurable quality lift on retrieval and classification tasks. The notable architectural feature across both is Matryoshka-style dimension truncation: you can request fewer dimensions than the model's native maximum and still get usable vectors, because the most important information is concentrated in the early dimensions. That lets a single model serve a high-accuracy tier and a storage-frugal tier without retraining anything.

How embeddings actually work

The mechanism matters because it explains both the strengths and the failure modes. The model reads your text, passes it through a transformer encoder, and pools the token representations into one vector. Distance in that vector space – usually cosine similarity – becomes your proxy for meaning. Two product reviews that say the same thing in different words sit close together; a review and an unrelated invoice sit far apart. Retrieval, clustering, deduplication and classification all reduce to geometry once the text is embedded.

The important caveat: embeddings capture distributional meaning, not truth or intent. They will happily place a confident falsehood next to the fact it contradicts, because both are about the same topic. They also inherit the training data's blind spots, so niche jargon, code, or low-resource languages may be embedded less crisply than mainstream English prose. For a fuller treatment of the representation itself, see our explainer on embeddings and vector representations. If you are building retrieval on top of these vectors, the companion piece on retrieval-augmented generation covers how the embedding step fits into the larger pipeline.

text-embedding-3-small versus text-embedding-3-large

The practical difference is a quality-versus-cost curve. text-embedding-3-small is cheaper per token and produces smaller native vectors, which means lower API spend and lower storage and query cost in your vector database. text-embedding-3-large costs more and produces larger vectors, and in exchange it scores higher on OpenAI's reported retrieval and multilingual benchmarks.

For most applications the honest answer is: start with small. The accuracy gap between the two is real but often marginal against the noise introduced by your chunking strategy, your query phrasing and your reranking. Teams routinely over-index on the embedding model when the larger wins are upstream – better document segmentation, metadata filtering, a reranker on top. Reach for large when retrieval quality is the measured bottleneck, when you are working across many languages, or when the domain is dense enough that the extra dimensions earn their keep.

Both support truncation. You can take text-embedding-3-large and request, say, 1024 dimensions to shrink your index while keeping more of the large model's quality than the small model would give you at the same size. That three-way trade – model choice, dimension count, index cost – is the real tuning surface, and it is worth measuring on your own data rather than trusting a general benchmark.

Capability picture: MTEB and multilingual reach

The standard public yardstick is MTEB, the Massive Text Embedding Benchmark, which aggregates dozens of tasks across retrieval, classification, clustering, reranking and semantic similarity. On the MTEB leaderboard, text-embedding-3-large posts strong scores, and text-embedding-3-small sits respectably below it – but neither currently tops the board, and that is the important point. The leaderboard's upper reaches have been dominated for some time by open-source and specialist commercial models that were tuned specifically to its tasks. Treat MTEB as a directional signal, not a verdict: scores shift as new models land, and a model can lead the aggregate while losing on the one subtask that matches your workload. Check the date on any score you cite and read the per-task breakdown rather than the headline average.

On multilingual coverage, text-embedding-3 is a genuine improvement over ada-002, with OpenAI reporting better cross-lingual retrieval. For mainstream European and major Asian languages it performs well. For low-resource languages, measure before you promise anything – this is exactly where purpose-built multilingual models can pull ahead. For background on how to read benchmark claims critically, our guide to AI benchmarks applies the same scepticism to the model-capability leaderboards.

Pricing and the economics at scale

As of this article's publication, OpenAI prices embeddings per million input tokens, with text-embedding-3-small costing a fraction of text-embedding-3-large. Exact figures move, so read them from the OpenAI pricing page rather than any third-party quote, including this one.

The economics that matter are not the per-call cost – they are the cumulative cost of embedding a large corpus and the ongoing cost of storing and querying the vectors. Embedding a few million documents is a one-time charge you can estimate precisely by counting tokens. The recurring cost is the vector index: higher dimensions mean more bytes per vector, more memory, and slower nearest-neighbour search at scale. This is where dimension truncation pays off – halving your vector width can roughly halve index memory with a small, measurable accuracy cost. If you are embedding user queries in real time at volume, watch your rate limits too; our note on 429 Too Many Requests errors covers the throttling you will hit before you hit a budget ceiling. For the storage side, the survey of vector databases lays out how index choice interacts with dimension count.

How OpenAI embeddings compare to the alternatives

OpenAI's advantage is operational rather than technical: if you already call the OpenAI API, embeddings are one more endpoint with the same key, the same SDK and the same billing. That convenience is worth real money in engineering time. But on pure retrieval quality the competitive picture is more contested than the default choice suggests.

Cohere Embed v3. Cohere built its embedding line explicitly around retrieval, and its Embed v3 announcement emphasises document-quality ranking and compression-aware training. In independent and vendor comparisons it frequently matches or beats OpenAI on retrieval tasks, and its multilingual model is a serious option for cross-lingual search. Cohere also offers an int8 and binary embedding path that is attractive when index cost dominates. If retrieval accuracy is your measured priority, Embed v3 deserves a bake-off.

Voyage AI. Voyage positions itself around domain specialisation – models tuned for code, finance, law and similar verticals – and its general models have ranked competitively on retrieval benchmarks. The pitch is that a domain-tuned embedder beats a generalist on domain text, which is often true in practice. The trade-off is another vendor relationship and the usual questions about long-term pricing and availability for a smaller company.

BGE and the open-source field. The BGE family from the Beijing Academy of Artificial Intelligence, along with models like E5 and the GTE line, give you open weights you can run yourself. The appeal is control and marginal cost: once you host the model, embedding is effectively free beyond compute, with no per-token bill and no data leaving your infrastructure. Several open models rank at or near the top of MTEB. The cost is operational – you own the serving, scaling, GPU capacity and version management that OpenAI otherwise absorbs. For privacy-sensitive corpora or very high volume, that cost is often worth paying.

The honest summary: OpenAI's text-embedding-3 is a strong, well-supported default, not the accuracy leader. Choose it for integration simplicity and solid all-round performance; look to Cohere for retrieval, Voyage for specialist domains, and BGE when control and cost-at-scale outweigh convenience.

Matching the model to the use case

For search and RAG, retrieval quality is everything, and the right move is to measure recall on your own queries, add a reranker, and only then decide whether the embedding model is the limiting factor. For clustering and deduplication, dimension count and raw separation matter more than fine-grained ranking, so the small model at full dimensions is often enough. For classification, embeddings feed a lightweight downstream classifier, and the large model's extra signal can lift accuracy if labels are subtle. For semantic similarity – matching, recommendation, near-duplicate detection – cosine distance behaviour is what you test, and small differences between models rarely justify the large model's cost.

Migrating from ada-002 to text-embedding-3

The migration is not drop-in, and the reason is dimensional. text-embedding-ada-002 produced 1536-dimensional vectors; text-embedding-3-large produces up to 3072. You cannot compare a v3 vector against an ada-002 vector – they live in different spaces – so you must re-embed your entire corpus with the new model and rebuild the index. Plan for the one-time embedding cost and the index rebuild as a single coordinated cutover, not a gradual rollout, because mixed-generation indexes return nonsense.

If you want to keep your existing 1536-dimension infrastructure, text-embedding-3-small is the natural landing spot, or text-embedding-3-large truncated to 1536. Benchmark both against your retrieval metrics before deciding; the truncated large model often wins at equal storage. Store the model name and dimension count alongside every vector as metadata, so the next migration – and there will be one – is a known quantity rather than an archaeology project.

The durable lesson is that the embedding model is a dependency with a shelf life. Build your pipeline so re-embedding is a routine operation you can trigger on demand, and the choice between OpenAI, Cohere, Voyage and BGE becomes a decision you can revisit with data rather than a lock-in you regret.