OpenAI

text-embedding-3-small

Name: text-embedding-3-small
Availability: InStock
Author: OpenAI

text-embedding-3-small is an OpenAI text embedding model that converts text into dense vectors for search, clustering, classification, and retrieval-augmented generation.

Input from

$0.0040 / 1M tokens

on PopNow · 1 provider

Output from

$0.0000 / 1M tokens

on PopNow

Compare Prices

API Pricing

Provider	Input / 1M	Output / 1M	Updated	Source
PopNow	$0.0040	$0.0000	11/10/2026	Visit

Prices updated daily. Last check: Nov 10, 2026

text-embedding-3-small pricing by provider

Input, output, and batch rates, plus alternatives, for one provider at a time.

PopNow1 provider comparedfrom $0.0040/1M

Model Details

General

Creator: OpenAI
Modalities: Text

Capabilities

Open Source: No

Strengths & Limitations

Strengths

Produces 1,536-dimensional embeddings by default, a size supported natively by essentially every vector database and ANN index
Supports the `dimensions` API parameter to shorten output vectors, trading a small amount of accuracy for lower storage and faster similarity search
Accepts long inputs (thousands of tokens per request), so document chunks rarely need to be split further for embedding
Batch input — multiple strings can be embedded in a single API call, reducing round trips when indexing large corpora
Cheaper per token than text-embedding-3-large, making full-corpus re-indexing more practical
Served as a hosted API by OpenAI with no GPU provisioning, model loading, or inference-server tuning required
Widely integrated into retrieval frameworks and vector database SDKs, so swapping it in usually requires little code

Limitations

Lower retrieval benchmark scores than text-embedding-3-large, which is the trade-off for its smaller size and cost
Proprietary and API-only — weights are not available for self-hosting, air-gapped deployment, or fine-tuning
Embeddings are not interchangeable with those from other models; switching embedding models requires re-indexing the entire corpus
Produces vectors only — it cannot rerank, generate text, or explain why two items are similar, so it is usually paired with other models
Per-request latency and rate limits are set by the API provider, which can constrain very large bulk indexing jobs

Key Features

•Dense text embeddings for semantic similarity, search, and clustering

•1,536-dimensional output vectors by default

•`dimensions` parameter for shortened embeddings without re-embedding

•Long input support (thousands of tokens per string)

•Batch embedding of multiple inputs per API request

•Float and base64 encoding options for the returned vectors

•Drop-in compatibility with common vector databases and RAG frameworks

•Part of OpenAI's text-embedding-3 family alongside text-embedding-3-large

About text-embedding-3-small

text-embedding-3-small is an embedding model from OpenAI, part of the text-embedding-3 generation that sits alongside text-embedding-3-large. It is the smaller of the two, positioned for workloads where embedding throughput and cost per million tokens matter more than squeezing out the last points of retrieval accuracy. Unlike a chat model, it produces no text output: given a string, it returns a fixed-length vector of floating-point numbers whose geometric relationships approximate semantic similarity. The model accepts long inputs (OpenAI documents an input limit in the range of roughly 8K tokens for the text-embedding-3 family) and returns 1,536-dimensional vectors by default. A notable capability of this generation is the API-level `dimensions` parameter, which lets callers request shorter vectors that remain usable without re-training or re-embedding from scratch — useful when vector database storage or index memory is the binding constraint. Batch requests let many strings be embedded in a single API call, which matters when indexing large corpora. In practice text-embedding-3-small is used as the retrieval layer behind RAG pipelines, semantic search over document stores, deduplication, recommendation, and lightweight text classification built on top of vector features. The usual comparison is against text-embedding-3-large, which produces higher-dimensional vectors and generally scores better on retrieval benchmarks at a higher cost per token, and against open-weight embedding models that can be self-hosted on your own GPUs. Teams embedding millions of chunks frequently pick the small variant for the index and reserve larger models for rerank or for corpora where retrieval quality is the bottleneck.

Common Use Cases

text-embedding-3-small fits high-volume indexing work where every document chunk in a corpus must be vectorized: retrieval-augmented generation over internal wikis, support tickets, or product documentation; semantic search that goes beyond keyword matching; near-duplicate detection and content deduplication; clustering and topic discovery over large text collections; and feeding vector features into lightweight classifiers or recommendation systems. Its cost and size profile make it a common default for the initial retrieval stage of a pipeline, with a reranker or a larger embedding model applied only to the top candidates when precision matters. It is less appropriate when retrieval quality is the measured bottleneck — in those cases text-embedding-3-large or a domain-tuned open-weight model is worth evaluating — and it is not a substitute for a chat or reasoning model, since it emits vectors rather than text.

Frequently Asked Questions

How much does text-embedding-3-small cost?

Embedding models are billed per input token, and the rate varies by provider and by pricing type (on-demand versus batch or committed-use tiers). Rates also change over time, so check the pricing table on this page for current figures rather than relying on a number quoted in an article.

What is text-embedding-3-small best used for?

It is best suited to embedding large volumes of text for semantic search, retrieval-augmented generation, clustering, and deduplication, where cost per million tokens and index size matter and small differences in retrieval accuracy are acceptable.

How does it compare to text-embedding-3-large?

Both are part of OpenAI's text-embedding-3 family. The large variant produces higher-dimensional vectors and generally scores better on retrieval benchmarks, while the small variant costs less per token and yields smaller vectors that are cheaper to store and search. A common pattern is to index with the small model and evaluate whether the large model's accuracy gain justifies re-indexing.

Can I reduce the embedding dimension to save storage?

Yes. The text-embedding-3 generation exposes a `dimensions` parameter that returns shorter vectors, so you can cut vector-database storage and speed up similarity search without re-embedding your corpus with a different model. Shorter vectors typically give up some retrieval accuracy, so test on your own data.

Can I use text-embedding-3-small for chat or text generation?

No. It is an embedding model — it returns numeric vectors, not text. It is used as the retrieval component of a system and is typically paired with a separate chat or reasoning model that consumes the retrieved passages.

Do I need to re-index if I switch embedding models?

Yes. Embeddings from different models occupy different vector spaces and are not comparable, so moving to or from text-embedding-3-small requires re-embedding your entire corpus and rebuilding the index.