RAG cost calculator

Estimate what a retrieval-augmented pipeline costs to run: one-time corpus embedding, per-query generation, and vector storage, broken down into a monthly total and a per-query price. Every number is editable, so it works for any embedding model, LLM, or vector database.

Corpus

Advanced

Queries

Vector storage

pgvector on a database you already run ≈ $0; managed vector databases typically land at $0–70/mo on entry tiers.

Cost itemBasisCost
Embedding the corpus (one-time)500,000 tokens × $0.02/1M$0.01
Re-embedding / monthone-time only — no refresh$0.00
Generation input / month2,300 tokens/query × 9,000 queries$62.10
Generation output / month400 tokens/query × 9,000 queries$54.00
Vector storage / monthflat monthly rate$0.00
Total / monthexcludes the one-time embedding row$116.10

≈ $0.01 per query

Defaults reflect list prices as of July 2026 — every field is editable, so plug in any provider's pricing. Months are counted as 30 days.

How RAG pipeline costs break down

A RAG pipeline has three cost buckets. First, embedding: every document is chunked and run through an embedding model once, billed per token — a one-time (or periodic) charge that repeats only when documents change or you re-index. Second, vector storage: the embeddings have to live somewhere, which is a flat monthly cost — near zero if you use pgvector on a database you already run, an entry-tier subscription or per-vector charge if you use a managed vector database. Third, per-query cost: each request embeds the user's question, runs a retrieval lookup, and sends the retrieved chunks plus the question to a generation model as input tokens, paying for the answer as output tokens. The generation call is almost always the dominant per-query cost.

What drives each line item

  • Corpus size and chunking → embedding and storage. More documents and smaller chunks mean more vectors to embed once and more vectors to store every month. Both scale with the size of the corpus, not with how often you query it.
  • Query volume → generation. Every question triggers a generation call, so daily and monthly spend scales directly with how many queries you serve. This is the multiplier that turns a fraction of a cent per query into a real monthly bill.
  • Retrieved chunks per query (top-k) → generation input tokens. The more chunks you send as context, the more input tokens each generation call pays for. Larger chunks and a higher top-k improve recall but raise the per-query cost proportionally.
  • Answer length → generation output tokens. Output is billed at a premium rate, so long, verbose answers move the bill more than their token count suggests.

Ways to cut RAG costs

  • Use a smaller, cheaper embedding model. Embedding rarely needs a frontier model; a smaller embedder trims both the one-time indexing cost and the query-embedding charge on every request.
  • Right-size chunk count and top-k. Retrieving fewer, tighter chunks cuts generation input tokens directly — but starves the model of context and degrades answers, so tune against answer quality, not just the bill.
  • Cache the generation system prompt. The fixed instructions re-sent on every call are a prime candidate for prompt caching, often 75–90% cheaper on the cached portion.
  • Rerank to send fewer chunks. A reranking pass lets you retrieve broadly, then pass only the top few chunks to the generation model — better answers on fewer input tokens.
  • Store only what you need. Keep just the fields you actually retrieve, and run pgvector on a database you already operate rather than paying for a separate managed store, to keep storage near zero.

A worked example

Take a support knowledge base of 2,000 documents answering 1,000 queries a day. Indexing is a one-time job: chunk the 2,000 docs into, say, 20,000 chunks and embed them once — a few dollars at most, because embedding models are cents per million tokens. Storage for those 20,000 vectors is a flat monthly line, near zero on pgvector. The recurring cost is the 1,000 daily queries: each sends the question plus, say, five retrieved chunks (a few thousand input tokens) to a generation model and pays for a short answer. That generation spend, multiplied by ~30,000 queries a month, is what dominates the bill — which is why halving top-k or caching the system prompt moves the total far more than optimizing the corpus ever will. Model your own numbers above by setting corpus size, chunking, top-k, and query volume.

Frequently asked questions

How much does RAG cost?
It depends far more on query volume than on corpus size. Indexing a corpus is a one-time embedding charge that stays small — embedding models are cheap per token, so even a large knowledge base embeds for a few dollars or less. The recurring cost is per query: each question re-sends the retrieved context to a generation model and pays for the answer. At scale, that generation spend, multiplied by queries per day, is what determines your monthly bill. Enter your corpus size and query volume above to price your exact pipeline.
Is embedding a one-time cost?
Mostly. You embed each chunk of your corpus once when you first index it, and that charge does not repeat unless the documents change. In practice it is a periodic cost: you pay again to embed new or updated documents as the corpus grows, and you pay to re-embed everything if you switch embedding models or change your chunking strategy. Steady-state, a stable corpus incurs no ongoing embedding cost beyond the small query-embedding charge on each request.
What is the biggest cost in a RAG pipeline?
For any real query volume, generation dominates. Every query sends the user's question plus several retrieved chunks — often thousands of input tokens — to a generation model priced far higher per token than an embedding model, and then pays again for the output. Corpus embedding and vector storage are usually rounding errors next to generation once you are answering more than a handful of queries a day. That is why the number of retrieved chunks (top-k) and your chunk size are the levers that move the bill most.
How do I reduce RAG costs?
Cut what you send to the generation model. Retrieve fewer, tighter chunks (lower top-k), rerank so only the most relevant chunks reach the model, and cache the fixed system prompt so you are not billed full input price for it on every call. Choosing a smaller or cheaper embedding model and storing only the fields you actually retrieve trims the indexing and storage lines. Because generation input tokens are the largest recurring line item, shrinking retrieved context — without starving the model of the context it needs to answer well — is where most savings come from.
Do I pay for vector storage?
You pay to keep the embeddings somewhere, but it is usually the smallest bucket. If you run pgvector on a database you already operate, the marginal storage cost is near zero. A managed vector database adds a flat monthly subscription or a per-vector charge that scales with corpus size, not with query volume. Either way, storage is a fixed monthly line that rarely rivals generation once queries ramp up.
How is per-query cost different from indexing cost?
Indexing cost is paid once, up front, and scales with corpus size and chunking — how many chunks you create and how many tokens each holds. Per-query cost is paid on every request and scales with query volume and retrieval depth — the query embedding, the retrieval lookup, and the generation call that sends the retrieved chunks and returns an answer. The calculator separates them so you can see the one-time indexing figure alongside the recurring monthly total.
Is this RAG cost calculator free?
Yes — it runs entirely in your browser, needs no signup, and sends nothing to a server. Every rate is prefilled and editable, so you can model any embedding model, generation model, or vector database, and adjust for a future price change.

Related tools: LLM API cost calculator (price a single generation call), RAG chunking visualizer (see how chunk size and overlap split your docs), and the context window comparison (count tokens and check what fits).

More free tools