Home / Calculators / Embedding Cost Calculator: Price Your Corpus and Queries

Embedding Cost Calculator: Price Your Corpus and Queries

An embedding cost calculator estimates what it costs to turn a corpus and its queries into embedding vectors, from the number of documents, their length, chunk overlap, query volume and the model’s price per token. The method is to count tokens first and apply price last. Corpus tokens are documents times average words times tokens per word, multiplied by one plus the chunk overlap. The one-time cost is those tokens times the price per token. Query cost is queries times tokens per query times the same price, every month. Because prices for hosted embedding models change often and differ widely, the calculator takes your provider’s current price as an input rather than listing models. Two habits keep the bill low: chunk without excessive overlap, and pick the model carefully, since changing it later means paying to re-embed everything.

How do you estimate embedding cost with the calculator?

You estimate embedding cost with the calculator by entering your document count, average words per document, tokens per word, chunk overlap, price per million tokens and monthly query volume. It returns corpus tokens, the one-time embedding cost and the monthly query cost.

With the default inputs, 100,000 documents of 800 words at 1.3 tokens per word make 104 million tokens, and a 10 percent overlap raises that to 114.4 million. At an illustrative 0.10 per million tokens, the one-time cost is 11.44. One hundred thousand queries of 12 tokens add 1.2 million tokens, or 0.12 per month at the same price.

The example shows the usual pattern: corpus embedding is the larger and more visible cost, while query embedding is small unless query volume is very high. The other lines of a semantic search bill, such as memory and reranking, are covered in the cost of semantic search. Each input deserves a closer look.

What formula does an embedding cost calculator use?

An embedding cost calculator multiplies total tokens by the price per token, where total tokens come from document count, words per document, tokens per word and chunk overlap. Counting tokens accurately matters more than the price itself.

Embedding providers bill by tokens, the units their tokenizer splits text into, not by words or characters. The ratio of tokens to words depends on the tokenizer and the language: English prose usually needs somewhat more tokens than words, while code, tables, rare names and many non-English languages need more. The most reliable way to set the ratio is to run a sample of your own documents through the provider’s tokenizer and divide tokens by words.

Self-hosted models have no per-token fee; their cost is compute time. The same token count still drives it, since processing time grows with input length. Whatever the pricing model, the next lever is how the text is chunked.

How does chunking change embedding cost?

Chunking changes embedding cost through overlap, because text that appears in two chunks is embedded twice, and through chunk count, which sets how many vectors you store. Overlap raises the token bill directly.

Overlap keeps context that would otherwise be cut at chunk boundaries, which can help retrieval. But a 50 percent overlap embeds half the corpus twice, so the token count rises by half. Most collections work well with modest overlap; the right amount comes from testing retrieval quality, as covered in chunking for semantic search and estimated in the chunk size calculator.

Chunk size has a second effect beyond tokens. Smaller chunks mean more vectors to store and index, which raises memory cost even though the token total barely changes. The vector storage and memory calculator sizes that side. Price is the input that varies most between choices.

How do you find the price per token for an embedding model?

You find the price per token on the embedding provider’s current pricing page, usually stated per million tokens, and check whether batch processing or a different tier changes it. Prices change often, so check at the time of the decision.

Hosted embedding models are priced per million input tokens, and the range between models is wide, often reflecting model size and dimensions. Some providers offer lower prices for asynchronous batch jobs, which suit one-time corpus embedding. Weaviate offers its own hosted service, Weaviate Embeddings, for collections on Weaviate Cloud, alongside integrations with many third-party providers.

The cheapest model is not the cheapest choice if it retrieves worse. A model with fewer dimensions also cuts memory cost, which can outweigh the embedding fee over a year. Compare models on your own queries first, then price the one that wins. The model choice has a cost that appears later.

When do you pay to embed the corpus again?

You pay to embed the corpus again whenever you change the embedding model, change how text is chunked or cleaned, or change which fields are embedded. Each of these produces vectors incompatible with the old ones.

Vectors from different models live in different spaces, so a query embedded with a new model cannot be compared with documents embedded by the old one. Weaviate’s documentation notes that a collection’s vectorizer cannot be changed after creation; moving to a new model means a new collection and a full re-embed. Changing chunk size or overlap changes the text of every chunk, which also means re-embedding. Migrating to a new vector database covers the process.

Plan for at least one re-embed in the life of a system, since better models appear regularly. Keeping the source text and a record of the model and chunking settings makes the re-embed a script rather than a project. Ongoing updates have a cost too.

How do updates and queries add to embedding cost?

Updates and queries add to embedding cost by embedding new or changed documents as they arrive and embedding every search query, which together form a monthly cost on top of the initial load. Both scale with activity rather than corpus size.

New and edited documents need embedding when they change. If a tenth of the corpus changes each month, the monthly update cost is a tenth of the one-time cost. Re-embedding only changed chunks, rather than whole documents, keeps it lower. Query embedding is usually small per query, but very high query volumes can add up, and caching the vectors of repeated queries avoids paying twice.

Weaviate can embed text at import and query time through its model integrations, so each insert and each text query triggers a model call to the configured provider. Applications can instead supply their own vectors, which gives full control over batching and caching. The related calculators explain the rest of the pipeline: the vector similarity calculator shows how vectors are compared, and the reciprocal rank fusion calculator shows how hybrid results merge.

An embedding cost calculator counts the tokens a corpus and its queries will send to an embedding model, then multiplies by the price per token. Corpus tokens are documents times words times tokens per word, raised by chunk overlap, and query tokens are queries times their length. Enter your provider’s current price and a tokens-per-word ratio measured on your own text, keep overlap modest, and remember that a model change means paying for the whole corpus again. Compare models on retrieval quality first, then use the calculator to price the winner.