Embeddings Pricing Calculator (15+ models)

Estimate initial index construction costs and monthly query costs for 15+ embedding models including OpenAI, Voyage, Cohere, Gemini, Mistral, Together, and more. Also provides a comprehensive list of dimensions, maximum tokens, and Matryoshka Representation Learning (MRL) support.

100% Free No signup Browser-only 5 languages Dark mode

⚠ Pricing as of 2026-04. Verify on official pages: OpenAI · Voyage · Cohere · Google

Related: 🪓 RAG Chunker · 🪙 LLM Token Counter

📚 Index build (one-time)

Total documents Avg tokens/doc

🔍 Query (monthly)

Queries/month Avg tokens/query

📊 Quick stats

Index input

0 tokens

Monthly query input

0 tokens

Model	Dim	Max tok	$/MT	Index cost	Monthly query	Total (month 1)	MRL

※ Prices as of April 2026. MRL = Matryoshka Representation Learning (dimensions can be reduced retroactively).

📖 Where people get stuck

Estimate the one-off cost of building an embedding index and the monthly cost of querying it, for a given corpus size and model. Everything runs in the browser. What you see here is the API charge only. The real total for a RAG system also carries the monthly bill for the vector database, the cost of re-embedding when you reindex, and the inference cost of feeding the retrieved chunks to an LLM — and in most designs that last item is tens of times the embedding cost.

Case	What happens	What to do
Deciding on the build cost alone	Learning that embedding a hundred thousand documents costs a few dollars is reassuring, but that number happens once. What actually accumulates is re-embedding whenever a document changes and embedding every search query. At ten thousand queries a day that is three hundred thousand query embeddings a month, forever.	Add up three separate lines: build once, updates times their frequency, and queries times monthly volume. A query embedding is only a few dozen tokens, so a cheaper model for queries can look tempting — but note that documents and queries must use the same model, since distances across different vector spaces are meaningless. Where a model offers a reduced-dimension option, that is the practical lever instead.
Picking the model with the most dimensions	The dimension count feeds straight into storage and memory in the vector database. Three thousand dimensions in float32 is 12 KB per vector, so a million documents is 12 GB. Halve the dimensions and you halve that. This storage side often ends up mattering more than the API charge, and search latency scales with dimensions too.	Build at a small dimension first, measure the accuracy, and raise it only if you need to. For many applications 768 to 1024 is enough. A model that supports dimension reduction lets you lower the output size without changing model, so the rework is small. At a scale where storage hurts, quantising float32 to int8 cuts it to a quarter, usually for a few percent of accuracy.
Not budgeting for a model migration	Changing the embedding model invalidates every vector you already have. The spaces differ, so mixing old and new and measuring distance between them is meaningless in principle. That makes re-embedding the entire corpus mandatory, at the full cost of the original build. Model generations turn over every year or two, so this is a question of when, not if.	Store which model produced each vector, alongside the vector, from the design stage. Whether you can tell the old generation apart decides how much work a migration is. Keep the source text as well — re-embedding needs the original, and if you discarded everything but the chunks you are back to fetching the documents. Migrate by running the old and new indexes side by side and comparing retrieval quality before switching.

The most effective way to cut cost is to embed less in the first place. Indexing only what actually gets searched, rather than every document in the company, is cheaper, faster and more accurate — every unrelated document is one more source of noise in the results. Avoid re-embedding everything on each update, too: keep a hash per document and re-embed only what changed, and the running cost drops sharply. Chunking design is covered on the RAG text chunker, and token estimation on the token counter.

❓ Frequently Asked Questions

Index = one-time?

Yes, only at initial build. Adding new docs incurs incremental cost

Choosing dimensions?

512-1536 typical. MRL models truncate post-training (e.g., 3072 → 512 retains most quality)

OSS embeddings?

BGE / E5 / Nomic etc. are free (self-host). Add CPU/GPU + vector DB cost. Table covers API only

🐛 Found a bug or issue with this tool?

Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.