text-embedding-3-small is OpenAI's smaller, lower-cost embedding model, released January 25, 2024 alongside the larger text-embedding-3-large. An embedding model turns text into a fixed-length vector of numbers representing its meaning, rather than generating new text — two passages with similar meaning produce vectors that land close together in that numeric space. That property underlies semantic search, clustering, deduplication, recommendation, and retrieval-augmented generation (RAG), where a system needs to rank stored passages by relevance to a query before a language model ever sees them.
What it is built for
By default, text-embedding-3-small outputs a 1,536-dimension vector. On OpenAI's own MTEB benchmark — a standard evaluation suite covering retrieval, classification, and clustering — it scores 62.3, ahead of the older text-embedding-ada-002 model's 61.0 despite ada-002 using the same 1,536 dimensions. In other words, this generation improved quality at an unchanged vector size, which is a straightforward upgrade for anyone still running the previous generation.
Maximum input length is 8,192 tokens per request, matching the larger model. Output is embedding-only: no chat, no generation, no tool use — a single call takes a string and returns a fixed-size array of floats.
The dimensions parameter
Like its larger sibling, text-embedding-3-small supports a dimensions parameter that truncates the output vector to a shorter length without re-embedding through a different model. Shortening the vector reduces storage in a vector database and speeds up similarity comparisons at query time, which is useful when the index is large enough that storage and search latency start to dominate cost — a common situation once a corpus reaches millions of documents.
Where it earns its place
The core case for text-embedding-3-small is volume: high document counts, frequent re-indexing, and a query pattern where latency budgets are tight. Its lower per-call cost and smaller default vector size compound at scale — every document indexed and every query embedded carries a real, ongoing storage and compute cost, and for large corpora that adds up regardless of how good the per-embedding quality is.
It is also a reasonable default for retrieval tasks that are not adversarial or fine-grained: general document search, FAQ matching, deduplication of near-identical content, and RAG pipelines where the retrieval step needs to be "good enough" rather than maximally precise, because the language model reading the retrieved passages can tolerate some noise in what gets retrieved.
Where the limits show
The MTEB gap to text-embedding-3-large is real, even if modest, and it tends to widen on harder retrieval tasks — distinguishing between closely related passages, working in less common languages, or ranking many similar candidates precisely. For a RAG system that is measurably missing relevant passages, or a search feature returning near-misses, the fix is often switching to the larger model rather than tuning the smaller one further.
Alternatives worth comparing
text-embedding-3-large is the natural upgrade path when retrieval quality, not cost, is the bottleneck. text-embedding-ada-002 remains available but is dominated on quality by this model at the same vector size, so there is little reason to pick it for new work. Outside OpenAI, several providers ship comparable general-purpose embedding models; testing retrieval quality against a representative sample of your own corpus is a better guide than benchmark scores alone, since embedding performance does not always transfer evenly across domains.