Embedding Cost Calculator

Estimate the cost of embedding a whole dataset for search, RAG or clustering.

Number of documents / chunks

Avg tokens per document

Embedding model

—

Rates auto-synced 2026-07-25 from the LiteLLM community pricing database, a public community-maintained dataset that tracks vendor pricing pages — not an official vendor feed. The same values drive every calculator here via pricing.json. Confirm on the official pages before budgeting: Anthropic · OpenAI · Google. Every rate movement since tracking began is logged on the pricing change log.

How embedding cost works

Embedding APIs bill per token, just like chat models, but there's only input — you pay once to turn each document into a vector. Total cost = total tokens ÷ 1,000,000 × rate. Re-embedding (after chunking changes or model upgrades) means paying again, so estimate before large runs.

Chunking decides the total, not the document count

The bill follows total tokens, and chunking changes that total more than most people expect. Overlap is the reason: a 200-token overlap on 500-token chunks means 40% of the corpus is embedded twice. Halving the chunk size roughly doubles the number of chunks, and with fixed overlap it more than doubles the tokens embedded.

That is not an argument for large chunks — retrieval quality usually improves with smaller, focused ones. It is an argument for calculating the real token total after chunking rather than from the raw document size.

The costs that come after embedding

Embedding the corpus once is often the smallest line item in a retrieval system:

Cost	When it lands
Initial embedding	Once, and it is what this calculator estimates
Query embedding	Every search, forever — small per query, unbounded in total
Re-embedding	Whenever the model, chunking or preprocessing changes: the full cost again
Vector storage	Ongoing, and scales with dimensions as well as chunk count
The generation step	Usually the dominant cost in a RAG system — retrieved passages become input tokens on every answer

A retrieval pipeline that looks cheap at build time can be expensive to run, because the recurring costs are per query rather than per document.

Dimensions are a cost lever too

Embedding models differ in output dimensions, and some support shortening the vector at request time. Fewer dimensions means less storage and faster similarity search, at some cost to retrieval quality. Since storage and query latency scale with dimensions across millions of vectors, this is worth testing against your own evaluation set rather than defaulting to the largest available.

Should I re-embed everything when a better model appears?

Only if retrieval quality is actually a problem. Vectors from different models are not comparable, so a migration is all-or-nothing: the whole corpus has to be re-embedded before anything can be queried. Estimate that full cost here before committing, and compare it against the improvement you measured on real queries.

Is embedding cheaper than sending documents to a chat model?

Substantially, per token — embedding rates are a fraction of chat input rates. The saving in a retrieval system comes from a different place, though: retrieving five relevant passages instead of stuffing fifty documents into the prompt cuts the generation cost on every single query.