text-embedding-3-small: Dimensions, Pricing & Alternatives

text-embedding-3-small is OpenAI's low-cost embedding model: a 1536-dimension vector at $0.02 per 1M tokens, with a max input of 8192 tokens. Its headline trick is the dimensions parameter — built on Matryoshka Representation Learning, it lets you shorten the vector (256, 512, 1024…) without the embedding losing its concept-representing properties, so you trade a little accuracy for a smaller, faster, cheaper-to-store index. This reference gives you the exact specs, the MTEB number OpenAI reports, when to reach for text-embedding-3-large instead, and how Google's gemini-embedding-001 stacks up — all from primary vendor docs, dated July 2026.

What text-embedding-3-small is

It is OpenAI's small, cheap text-embedding model — a 1536-dimension vector at $0.02 per 1M tokens. You send it text; it returns a fixed-length vector of floats that places semantically similar text near each other in vector space. That vector is what powers semantic search, retrieval-augmented generation (RAG), clustering, deduplication and classification. Two things make it the default starting point for most teams:

• Cost. At $0.02 per 1M tokens it is one of the least expensive frontier embedding models, so embedding a large corpus stays affordable. (OpenAI model card.)
• The dimensions parameter. You can shorten the output vector on demand to shrink your index without re-embedding — the explainer below covers exactly how.

Embeddings are a different job from chat completions — they turn text into vectors rather than generate text — but they ride the same API surface, which matters when you get to the gateway section.

Specs at a glance

Here are the numbers you actually look up, all from OpenAI's primary docs (July 2026).

*The current OpenAI embeddings guide documents 8192 tokens. Older OpenAI materials commonly cite 8191 — we report the current primary-doc figure and flag the discrepancy. The 62.3% figure is reported by OpenAI and attributed to MTEB (the Massive Text Embedding Benchmark), the independent benchmark; treat it as a vendor-reported number.

The dimensions parameter, explained

You can shorten the vector without re-embedding — that is the single most useful thing to know about this model. Both text-embedding-3-small and text-embedding-3-large support shortening embeddings via the dimensions API parameter. In OpenAI's words, "developers can shorten embeddings (i.e. remove some numbers from the end of the sequence) without the embedding losing its concept-representing properties by passing in the dimensions API parameter."

This works because the models are trained with Matryoshka Representation Learning (MRL): the most important information is packed toward the front of the vector, like nested Russian dolls, so truncating the tail degrades quality gracefully instead of catastrophically. How strong is the effect? OpenAI notes a text-embedding-3-large embedding shortened to size 256 still outperforms an unshortened older text-embedding-ada-002 embedding of size 1536.

Why you would shorten: a smaller vector means less storage, a smaller vector-DB index, and faster nearest-neighbour search — at the cost of some accuracy. Ask for it directly in the request:

from openai import OpenAI
client = OpenAI()

resp = client.embeddings.create(
    model="text-embedding-3-small",
    input="the quick brown fox",
    dimensions=512,          # shorten 1536 -> 512
)
vec = resp.data[0].embedding
print(len(vec))              # 512

Price per 1M tokens

text-embedding-3-small is $0.02 per 1M tokens — the cheap end of the frontier embedding lineup. Embedding pricing is input-only (there is no generated output to bill), so your cost is simply total tokens embedded ÷ 1,000,000 × the rate. Against the alternatives in this article:

• text-embedding-3-small — $0.02 / 1M tokens (OpenAI official)
• text-embedding-3-large — $0.13 / 1M tokens (OpenAI official) — about 6.5× small
• gemini-embedding-001 — $0.15 / 1M input tokens, paid tier (Google official)

For high-volume corpora — millions of chunks re-embedded on every content change — that 6.5× gap between small and large is the whole budget conversation. If cost is the deciding factor across your whole stack, our cheapest-LLM API guide works through the same math for generation models.

3-small vs 3-large vs gemini-embedding-001

The one table that answers "which embedding model should I use?" All figures from primary vendor docs, July 2026. Note the benchmark columns are not directly comparable: OpenAI reports MTEB average, Google reports MTEB(Multilingual) by dimension — different variants, so read them as within-vendor signals, not a head-to-head score.

*OpenAI max input per the current embeddings guide (older materials cite 8191). MTEB averages are OpenAI-reported; the Gemini score is Google-reported on MTEB(Multilingual). Gemini reports by dimension: 68.17 @1536, 68.16 @2048, 67.99 @768, 67.55 @512, 66.19 @256, 63.31 @128. Sources: OpenAI embeddings guide and model cards; Google Gemini embeddings docs.

Rule of thumb from the table: start with 3-small for cost and throughput; move to 3-large when retrieval accuracy is worth 6.5× the price; reach for gemini-embedding-001 when multilingual coverage is the priority and your chunks fit inside 2048 tokens. For a broader survey of the field, see our best embedding models roundup.

When to use text-embedding-3-large

Reach for the large model when retrieval accuracy matters more than cost. text-embedding-3-large defaults to 3072 dimensions and OpenAI reports it at 64.6% average on MTEB, versus 62.3% for small — a real but modest gap. What you pay for it: $0.13 per 1M tokens, roughly 6.5× the small model. It supports the same dimensions parameter, so you can take the more accurate large embedding and shorten it to keep your index small — often the best of both, given that a large vector truncated to 256 still beats an unshortened ada-002 at 1536. Pick large when a few points of recall change the product (legal search, high-stakes RAG); stay on small when you are embedding at scale and cost dominates.

Where gemini-embedding-001 fits

Google's gemini-embedding-001 is the multilingual-leaning alternative — higher default dimension, higher reported benchmark, but pricier and shorter-context. Its default and maximum output dimensionality is 3072, with supported Matryoshka dimensions of 128, 256, 512, 768, 1536, 2048 and 3072. Google reports MTEB(Multilingual) scores by dimension — 68.17 at 1536, peaking essentially at 68.16 at 2048, down to 63.31 at 128 — which shows the same graceful-degradation curve as OpenAI's MRL. The trade-offs against 3-small are concrete: it costs $0.15 per 1M input tokens on the paid tier, and its max input is 2048 tokens — a quarter of OpenAI's documented 8192, so long documents need more aggressive chunking. If you already run Gemini for generation, you may want it here too; grab a key via our Gemini API key walkthrough.

Calling embeddings through a gateway

Embeddings share the OpenAI request shape, so any OpenAI-compatible endpoint exposes a /v1/embeddings route you hit by changing one line. The request is model, input and the optional dimensions — identical whichever provider is behind it. DataLLM Lab exposes an OpenAI-compatible /v1/embeddings endpoint at the same base URL as its chat models, so you point the standard OpenAI SDK at it by swapping base_url:

from openai import OpenAI

client = OpenAI(
    base_url="https://www.datallmlab.com/v1",
    api_key="YOUR_DATALLMLAB_KEY",
)

resp = client.embeddings.create(
    model="text-embedding-3-small",   # confirm the current embedding catalogue
    input=["first chunk", "second chunk"],
    dimensions=512,
)

DataLLM Lab's hosted catalogue is focused on chat and completion models. The endpoint is OpenAI-compatible; check the current model list before depending on any specific embedding model. The mechanics of an OpenAI-drop-in base URL are covered in our OpenAI-compatible API guide, and the gateway pattern generally in what is an LLM gateway.

FAQ