The embedding cost calculator above turns a corpus size, an average chunk length, and a per-million-token rate into two numbers that matter for very different reasons: the one-time cost of building your vector index, and the recurring monthly cost of keeping it current and querying it. Most cost estimates for retrieval systems stop at the first number, which is why the running cost tends to arrive as a surprise in month three.
Arb Digital models this for clients building internal search and retrieval-augmented generation over their own content, because embeddings sit in an awkward gap: cheap enough per call that nobody checks, frequent enough at scale that the total is real. This page shows how the pieces fit together and where the recurring spend actually comes from.
What This Embedding Cost Calculator Does
Enter how many chunks you need to embed, their average token length, and your provider's embedding rate. The headline result is the cost of embedding the whole corpus once. The supporting grid then shows total tokens for that initial pass, the ongoing monthly cost of new and changed documents plus amortised full re-index runs, the separate cost of embedding incoming search queries, and a year-one total that combines all of it.
The bars split the recurring monthly figure three ways, so you can see immediately whether your ongoing spend is driven by content churn, by re-indexing, or by query volume. Those three have completely different fixes, and teams routinely optimise the wrong one.
How to Use It
- Enter chunks, not documents. Retrieval systems embed chunks. If you have not settled on a chunking strategy yet, the RAG chunk size calculator will tell you how many chunks a given corpus produces at a given chunk size and overlap.
- Set the average token length per chunk. If you only know word counts, the words to tokens converter gives a reliable conversion for English text.
- Replace the price default with your provider's current embedding rate. Embedding models are priced far below chat models and are listed separately on pricing pages.
- Set your churn rate and re-index frequency. The churn percentage is the share of your corpus that is new or edited each month; both new and edited chunks have to be re-embedded.
- Add query volume and query length, then click Calculate to see the initial, monthly, and year-one figures together.
The Formula / How It's Calculated
Embedding is priced on input tokens only — there is no output side, because the response is a vector rather than generated text. So the initial cost is simply chunks × tokens per chunk × price ÷ 1,000,000. Twenty-five thousand chunks at 800 tokens each is 20 million tokens, and at the default rate that is a couple of dollars. This is the number that makes teams stop worrying about embedding cost, and it is the least important of the three.
Monthly cost has three parts added together. Incremental embedding is chunks × churn% × tokens × price. Amortised re-indexing is initial cost × full runs per year ÷ 12. Query embedding is queries × tokens per query × price. Year one is the initial cost plus twelve monthly totals.
Query Embeddings: Tiny Calls, Enormous Counts
Every semantic search requires the query itself to be embedded with the same model as the corpus, so the two live in the same vector space. A query is short — often fifteen to thirty tokens — and the individual cost rounds to nothing. But query volume is orders of magnitude higher than document volume in a working system, and it never stops.
Put the default numbers side by side. Twenty-five thousand chunks embedded once is 20 million tokens. Two hundred thousand queries a month at 20 tokens each is 4 million tokens a month, or 48 million a year — more than twice the entire corpus. If your product runs multi-query retrieval, where each user question is expanded into three or four rewritten queries before search, multiply that again. Query-side caching for repeated searches is the obvious lever, and on consumer-facing search with a long head of common queries it removes a large share of the calls outright.
Re-Indexing Is the Cost That Recurs
A full re-index means paying the initial cost again. It happens more often than teams plan for, and almost never for the reason they expected. Common triggers: switching to a newer embedding model, changing chunk size or overlap after evaluating retrieval quality, adding a new metadata scheme that alters what gets embedded, or migrating between vector databases in a way that does not preserve vectors.
Because embedding models produce vectors in their own space, you cannot mix outputs from two models in one index and get meaningful similarity scores. Upgrading the model is therefore all-or-nothing: the whole corpus must be re-embedded before the new model can serve a single query. Setting the re-index field to two runs a year is not pessimistic for a system under active development. Set it to zero only if your chunking and model choice are genuinely frozen.
Dimensions Change Storage, Not Embedding Cost
Embedding models produce vectors of a fixed dimensionality, and some support shortening the output to fewer dimensions. That choice has no effect on what you pay to embed, because you are billed on input tokens, not output size. It has a large effect on what you pay to store and search, since index size scales directly with dimensions.
This is why embedding cost and vector storage cost need to be modelled separately — reducing dimensions can cut hosting cost substantially while leaving this calculator's output unchanged. Size that side with the vector database cost calculator, and check the retrieval token load your chunks add to each prompt with the context window planner, since retrieved chunks are billed again as input on every generation call.
Where to Find Current Rates
The price field is a placeholder, not a quote. Embedding rates change and models are superseded, so pull the live figure from the provider's own documentation before you use this for budgeting: OpenAI's embeddings guide documents its current embedding models and links to their rates, and Google's Gemini embeddings documentation covers its equivalents. Self-hosted open-weight embedding models remove the per-token charge entirely and replace it with compute cost, which is a different calculation — the GPU cost calculator handles that side.
One practical note when comparing: most providers offer a batch or asynchronous mode at a reduced rate for jobs that do not need an immediate response. Initial indexing is the textbook case for it, since nobody is waiting on a corpus backfill. Query embedding is the opposite and must run synchronously.
Chunk Size Quietly Sets Your Token Count
Two teams with identical corpora can have embedding bills that differ by half, purely from chunking. Smaller chunks mean more chunks, but the token total stays roughly constant — until overlap enters the picture. Overlap duplicates tokens deliberately so that context is not lost at chunk boundaries, and every duplicated token is embedded and paid for.
A 512-token chunk with 128 tokens of overlap re-embeds a quarter of the corpus. That is a 25% surcharge on the initial index, on every re-index, and on every incremental update, in exchange for better retrieval at boundaries. It is often worth it. It should still be a deliberate decision rather than a copied default, and this calculator makes the cost of that setting explicit: raise the average token count by your overlap percentage and compare the two totals.
Arb Digital scopes retrieval projects with the indexing and query economics modelled first, so the running cost is understood before any code is written.
Browse Free Tools Talk to Arb DigitalCommon Mistakes to Avoid
- Counting documents instead of chunks — a single long PDF can produce dozens of embedding calls, so document counts understate the token total badly.
- Forgetting query embeddings — at real search volume they routinely exceed the cost of embedding the corpus itself within the first year.
- Assuming the index is built once — model upgrades and chunking changes both require re-embedding everything, and both happen during normal development.
- Ignoring overlap — overlapping chunks duplicate tokens on purpose, and that duplication is billed on every indexing pass.
- Confusing embedding cost with total retrieval cost — the chunks you retrieve are sent to a chat model afterwards, and that generation step usually costs far more than the embedding did.
Related Free Tools From Arb Digital
Size your text first with the AI token calculator, plan chunking with the RAG chunk size calculator, cost the storage side using the vector database cost calculator, price the generation step with the LLM cost comparison tool, and test the overall business case with the AI ROI calculator. More in the free online tools hub.
Frequently Asked Questions
No. Embedding endpoints bill on input tokens only, because the response is a numeric vector rather than generated text. That is why embedding is dramatically cheaper per call than a chat completion of similar input length.
Yes. Every semantic search embeds the query with the same model used for the corpus. Queries are short, but their volume is far higher than document volume, so at scale they often become the larger line item.
Whenever the embedding model changes, the chunking strategy changes, or the corpus is migrated. Vectors from different models are not comparable, so a model upgrade requires re-embedding the entire corpus before it can serve any query.
No, because billing is based on input tokens rather than output dimensions. Fewer dimensions reduce index size and therefore vector database hosting and query cost, which is a separate calculation.
Count chunks. Each chunk is a separate embedding call with its own token cost, so a corpus of a thousand long documents can easily represent tens of thousands of embedding calls.
It replaces a per-token charge with compute and operations cost. Whether that is cheaper depends on volume and utilisation, since idle hardware still costs money while a per-token API charges nothing when not in use.
Overlap duplicates tokens by design, so a 25% overlap adds roughly 25% to the tokens embedded on every indexing pass. It usually improves retrieval quality at chunk boundaries, but it should be a deliberate trade rather than a default.
Figures produced by this tool are planning estimates only — actual spend depends on your provider's current rates, tokenizer, batch discounts, and real corpus churn.
