An embedding model's price is a one-time cost. Its dimensions are a subscription.

Embedding models are billed per 1M input tokens, so that's the number that ends up in the comparison. Here are the nine generally-available embedding models that publish a token price, every rate re-read off the provider's own page this morning (2026-08-17):

Model	Provider	$/1M input	Default dims	Max input tokens
text-embedding-3-small	OpenAI	$0.02	1536	8192
amazon.titan-embed-text-v2	Amazon	$0.02	1024	8192
text-embedding-v4 (Qwen)	Alibaba	$0.07	1024	8192
embed-v4.0	Cohere	$0.12	1536	128,000
text-embedding-3-large	OpenAI	$0.13	3072	8192
nova-2-multimodal-embeddings	Amazon	$0.135	3072	8192
gemini-embedding-001	Google	$0.15	3072	2048
codestral-embed	Mistral	$0.15	1536	8192
gemini-embedding-2	Google	$0.20	3072	8192

(The Model column is the provider's own model string; the ids in our feed are normalised slightly differently — you'll see both at the end.)

Top to bottom, that's a 10x spread. It is also, for most retrieval workloads, the least consequential number on the row.

The ingestion bill is one-time, and it is small

Take a corpus of 1,000,000 documents averaging 800 tokens. That's 800M tokens to embed.

• At $0.02/1M: $16.00
• At $0.20/1M: $160.00

The entire 10x spread is $144, once. You will spend more than that deciding which model to use. The token price only becomes interesting again when you re-embed — a model migration, or a corpus that grows continuously — and even then it's a function of new tokens, not of the corpus you already indexed.

Meanwhile the thing you're actually buying is a pile of float vectors that you will store, index, and hold in RAM for as long as the product exists.

The vector is what recurs

One million vectors, float32:

Dimensions	Size
3072	12.29 GB
1536	6.14 GB
1024	4.10 GB
768	3.07 GB
256	1.02 GB

I'm deliberately not multiplying that by a vector-database rate — every managed vector store prices differently and I'm not going to invent a number. Use your own. The point is the shape: this one is monthly, it scales linearly with the dimension count, and picking the 3072-dim model over the 1024-dim one triples it forever.

…except the dimension is usually a knob, not a spec

This is the part that makes the comparison table misleading rather than merely incomplete. On most current models, the dimension count you see published is a default, and you can ask for a smaller vector:

• OpenAI — a dimensions request parameter, which its API reference says is supported on text-embedding-3 and later models.
• Cohere — embed-v4.0's docs table gives its dimensions as a choice of 256, 512, 1024 or 1536, with 1536 the default.
• Google — an output_dimensionality parameter, via Matryoshka Representation Learning. Both Gemini embedding models default to 3072 and Google's docs say you can truncate below that without losing quality, recommending 768, 1536 or 3072.
• Amazon — Titan Text Embeddings V2 is documented as having "configurable output dimensions", set via dimensions in the request body.

And Google publishes the trade-off as a table, which is the most useful thing I found all week. MTEB score by truncated dimension, for gemini-embedding-001:

MRL dimension	MTEB score
2048	68.16
1536	68.17
768	67.99
512	67.55
256	66.19
128	63.31

Read that carefully. 1536 scores fractionally higher than 2048. Going from 1536 down to 768 costs 0.18 MTEB points and halves your storage, your index size and your RAM. The cliff doesn't arrive until 256, and it doesn't get steep until 128.

So the honest version of "this model is 3072-dimensional" is "this model defaults to 3072 and its own vendor recommends 768 as a supported option". Those imply storage bills a factor of four apart.

The number that really is fixed: the input ceiling

The context window is the field on these rows that you cannot negotiate, and it varies more than the other two. Cohere's own current lineup spans the entire range:

• embed-english-v3.0 — 512 tokens
• embed-v4.0 — 128,000 tokens

That's 250x, same vendor, both generally available today. Google moved from 2048 on gemini-embedding-001 to 8192 on gemini-embedding-2. Most of the rest sit at 8192.

Why it compounds: the ceiling caps your chunk size, chunk size sets your vector count, and vector count multiplied by dimensions is your storage and your index. Chunking the same corpus against a 512-token ceiling instead of an 8192-token one yields 16x the vectors. Your token spend barely moves — it's the same text either way — while everything downstream of the embedding call multiplies.

To be fair to the small-context models: almost nobody chunks at the ceiling, because retrieval quality usually wants smaller chunks than the maximum anyway. The ceiling doesn't dictate your chunk size. It removes options, and it's the only one of the three fields where the provider makes the decision for you.

Rerank: there is no ladder to write

I wanted to end with the same table for rerankers. It doesn't exist, and the reason is worth more than the table would have been.

Of the 7 GA rerank models we track, 3 publish a rate, and the unit isn't tokens:

Model	Provider	Price
Amazon Rerank v1	Amazon	$1.00 per 1,000 searches
Rerank 4 Fast	Cohere	$2.00 per 1,000 searches
Rerank 4 Pro	Cohere	$2.50 per 1,000 searches

A "search" is not a standard unit, and it is not a token. AWS's price book bills its reranker in search units — $1 per 1,000 of them — where a unit is a query carrying some bounded number of document chunks, defined in the docs rather than on the price line. Cohere bills per 1,000 searches. Whether those two units mean the same thing for your query shape is your problem, not something either price implies.

That AWS model is also region-scoped in a way the price book makes plain: the SKU (Z7M6S4MRBXNXJRB4) is in us-west-2, and there is no rerank SKU in the us-east-1 price book at all.

The other four GA rerankers publish no first-party rate we could find. In our data those fields are null, which is a fact about the provider, not a gap we're papering over.

Get it as data

All of the above is in a free JSON feed — no key, no signup, CORS open. (If you would rather just look at the 13 rows, they are on one page too.)

curl -s https://aimodelwatch.dev/api/models.json \
  | jq -r '.models[]
      | select(.embedding_dimensions != null and .status == "ga")
      | [.price_input_per_mtok, .embedding_dimensions, .context_window, .id]
      | @tsv' \
  | sort -g

Output, run against the live endpoint today:

0.02    1024    8192    amazon-titan-embed-text-v2
0.02    1536    8192    text-embedding-3-small
0.07    1024    8192    qwen-text-embedding-v4
0.12    1536    128000  embed-v4-0
0.13    3072    8192    text-embedding-3-large
0.135   3072    8192    amazon-nova-2-multimodal-embeddings
0.15    1536    8192    codestral-embed
0.15    3072    2048    gemini-embedding-001
0.2     3072    8192    gemini-embedding-2
        384     512     embed-english-light-v3-0
        384     512     embed-multilingual-light-v3-0
        1024    512     embed-english-v3-0
        1024    512     embed-multilingual-v3-0

The four rows with a blank price are Cohere's v3 embedding family. They're still GA and still documented; Cohere's pricing page currently lists only Embed 4 among its embedding models, so there is no first-party rate to carry. A blank there means "the provider doesn't publish this", not "we didn't look" — every row carries the source_url it was read from.

One honest note while you're looking at that output. The two OpenAI rows read 8191 when this was drafted, and I'd written 8192 in the table at the top. Both numbers are first-party: 8191 is the figure OpenAI's 2024 new-embedding-models announcement carried, and the current API reference states "the max input tokens for the model (8192 tokens for all embedding models)". The disagreement was reconciled to 8192 on 2026-08-18 — the reference states the limit as a constraint on the input parameter, i.e. it carries the field as data, while the model spec pages state no limit at all. It's one token out of eight thousand and it changes nothing in this article. I'm leaving the paragraph in because a catalog that quietly rounds its own disagreements away isn't worth querying — and because you can see the audit trail: the row's notes field records the old value, the new one, and which surface won.

---

Data from AI Model Watch — 231 models, prices and lifecycle dates read from official provider documentation, refreshed daily, with null where the provider publishes nothing. Free JSON: /api/models.json and /api/deprecations.json.