Embedding Cost Calculator
Set your corpus (documents × average tokens), chunking (size + overlap), embedding model and vector dtype — and get the numbers that decide RAG budgets: one-time indexing cost, vector count, storage footprint from FP32 down to binary, and the monthly bill for query embeddings.
Three bills, one index
RAG pricing questions collapse into three numbers. The indexing bill: every corpus token through the embedding API once (plus overlap — those 15% chunk overlaps are real tokens you pay for). The storage bill: vectors × dimensions × bytes, forever, plus the ANN index structures on top. The query bill: every search embeds the query — small per call, relentless at scale. This tool prices all three from six sliders.
Chunking is a financial decision too
Chunk size is usually tuned for retrieval quality — but watch the vector count as you slide it. Halving chunk size doubles your vectors, which doubles storage AND doubles ANN index memory, while the embedding bill barely moves (same tokens, different grouping). Overlap works the opposite way: it inflates the token bill linearly but leaves the vector count roughly alone. Quality first, but know what the knob costs.
The dtype ladder
Nobody should default to FP32 vectors in 2026. FP16 is free (no measurable retrieval loss). INT8 keeps ~99% of quality at ¼ the memory — the sensible production default. Binary embeddings are the aggressive play: 32× smaller than FP32, good enough to build a fast shortlist that you rescore with full-precision vectors kept on disk. On a 10M-vector index, that ladder is the difference between a RAM-resident index and a sharded cluster.
Watch the query line
The corpus is embedded once; queries arrive forever. At 100K queries a day, query embeddings pass the one-time index cost within months — which is exactly when teams move query embedding to a cheap or self-hosted model (the corpus and queries do not have to use the same model, as long as they share a vector space via the same model family or a matryoshka setup). High-traffic retrieval is a recurring-cost business; budget it like one.
How it works
- Index cost = corpus tokens (incl. overlap) ÷ 1M × model price.
- Vectors = corpus tokens ÷ chunk size; storage = vectors × dims × dtype bytes.
- ANN index structures add ~1.5–2× over raw vector bytes.
- Query spend recurs: queries/day × ~25 tokens, monthly.
Frequently asked questions
What drives the one-time indexing cost?
Total tokens embedded: documents × average tokens, inflated by chunk overlap (15% overlap re-embeds 15% of every boundary). At list prices the corpus cost is total tokens ÷ 1M × the model’s per-million price — chunking choices move it directly.
How is vector storage computed?
Vectors × dimensions × bytes per dimension. A million 1536-dim FP32 vectors is ~5.7 GB of raw vectors; the ANN index (HNSW graphs and friends) typically adds another 1.5–2× on top, which is why the tool flags it separately.
Are quantized embeddings (INT8, binary) actually usable?
Yes — INT8 keeps ~99% of retrieval quality at a quarter of the memory in most benchmarks, and binary embeddings (32× smaller than FP32) work well as a first-stage shortlist that you rescore with full-precision vectors. Storage dtype is a measured retrieval-eval decision, not a default.
Do query embeddings matter in the budget?
At scale, more than the index: the corpus is embedded once, but queries arrive forever. 100K queries/day at ~25 tokens each is ~75M tokens/month — recurring. High-traffic search is exactly where a cheap or self-hosted embedding model pays for itself.