—monthly churn
—year 1 total
—one full re-index
Annual cost by monthly churn
Churn is the driver most people miss. A corpus that turns over 20% a month costs far more to keep current than the one-time embed suggests — before any model migration.
| Monthly churn | Docs re-embedded / mo | Year 1 total |
|---|
The cost that arrives after launch
Retrieval-augmented generation projects almost always get costed the same way: count the documents, multiply by tokens and the embedding price, and there is your number. That number is real, but it is only the cost of embedding the corpus once. A knowledge base is not a museum — support articles get rewritten, product docs get updated, new content lands every week. Every one of those changes has to be re-embedded, and if a tenth of your corpus changes each month you are quietly paying to re-embed a tenth of everything, month after month. On a large corpus that recurring bill can rival the initial one within a year, and it never shows up in the launch estimate.
Then there is the migration cliff. Embedding vectors from different models are not interchangeable, so the day you move to a newer or cheaper embedding model, you have to re-embed the entire corpus at once — a full re-index. That single event can cost more than a whole year of ordinary churn, which is exactly why teams put off model upgrades they should make. Budgeting for it up front turns a scary surprise into a line item. To keep the ongoing number down, only re-embed what genuinely changed by tracking document hashes, chunk finely so a small edit does not re-embed a whole file, and batch the jobs for any discount. Size the rest of the pipeline with the RAG cost calculator, the embeddings cost calculator and the vector database cost calculator. Prices are editable reference estimates — confirm the current rate in your provider's docs.
Frequently asked questions
Why does a RAG knowledge base cost money every month, not just once?
Because documents change. The one-time cost most teams budget is embedding the whole corpus once, but a real knowledge base has churn — new documents added, existing ones edited — and every changed document has to be re-embedded to stay searchable. If 10% of a large corpus changes each month, you are re-embedding 10% of the whole thing every month, forever. That recurring line is invisible in most RAG cost estimates, and this calculator makes it explicit alongside the one-time initial cost.
What is a full re-index and why is it so expensive?
A full re-index is re-embedding your entire corpus from scratch, usually because you switched to a different or newer embedding model. Embeddings from different models are not compatible — you cannot mix vectors from an old model and a new one in the same index — so upgrading the model forces you to re-embed everything at once. On a large corpus that can dwarf a whole year of incremental churn in a single bill. This tool shows the cost of one full re-index separately so you can plan for model migrations instead of being surprised by them.
How can I lower ongoing re-embedding cost?
Three levers. First, only re-embed what actually changed — track document hashes so an unchanged file is never re-embedded, and re-embed at the chunk level so editing one paragraph does not re-embed a whole book. Second, pick a cheaper embedding model or a smaller dimension where retrieval quality allows; embedding prices vary widely. Third, batch your re-embedding jobs to use any batch-API discount. The calculator lets you dial churn and price to see how much each lever saves before you build the pipeline.