Worked example: 1,000 support articles
The default example has 1,000 documents at 600 words each, or 600,000 words. At 0.75 words per token, that is 600,000 / 0.75 = 800,000 estimated content tokens.
With 800-token chunks and 100-token overlap, the stride is 700 tokens. Chunk count is ceil((800,000 - 800) / 700) + 1 = 1,143 chunks.
Overlap is embedded again, so billable embedding tokens are 800,000 + 100 x 1,142 = 914,200 tokens. At $0.02 per 1M tokens, one-time embedding cost is 914,200 / 1,000,000 x $0.02 = $0.0183.
Storage uses 1,536 dimensions x 4 bytes plus 1,024 metadata bytes per vector. That is 1,143 x 7,168 bytes = 8,193,024 bytes, or about 0.008 GB. At $0.33 per GB-month, raw vector storage is about $0.0027 per month before read, write, backup, and reranking charges.
How the RAG chunk planner works
The planner estimates content tokens from document count, average words per document, and words per token. It then applies overlap chunking: stride equals chunk size minus overlap, and chunk count equals the number of windows needed to cover the token estimate.
Embedding cost is based on billable embedding tokens, including repeated overlap. Vector storage is estimated from chunk count, embedding dimensions, bytes per dimension, and metadata bytes per vector.
How many chunks will my RAG system create?
Chunk count rises when documents are longer, chunks are smaller, or overlap is larger. Small chunks can improve precise retrieval, but they also increase index size and can require a higher top-k to reconstruct enough context.
How much context will retrieval use?
Retrieved context tokens equal query tokens plus top-k multiplied by chunk size. This is only the retrieval payload; the final chat request also needs system instructions, tool schemas, user text, and output tokens.
What this estimate excludes
The storage result is a raw dense-vector estimate. It excludes vector database minimum plan fees, replicas, read units, write units, backups, imports, reranking, hybrid sparse indexes, metadata indexes, observability, and engineering time.
What to do next
Run a small retrieval-quality test before indexing everything. Sample real user questions, compare chunk sizes, check citations, measure missed answers, and only then approve the embedding and vector database budget.