A workflow we use when reviewing "we built a RAG system" write-ups, and which works for planning your own. Three tools on this site, in order:
- /tools/rag-text-chunker: paste a representative document, pick a chunk size and overlap, see the chunks and how many there are. This is where you discover that your 400-token chunks split tables in half, or that 50% overlap doubles your index for little gain.
- /tools/token-counter: count the tokens of a chunk, of the system prompt, and of a typical question. Tokenisers differ between model families; a count from one is a rough guide for another, which is why the tool lets you pick.
- /tools/llm-cost-calculator: input tokens per request (system prompt + retrieved chunks × top-k + question), output tokens, requests per day, and the model's price. It gives the monthly figure you can put in front of whoever pays.
Two things the numbers usually reveal. The embedding cost of indexing is small compared with the generation cost of answering, so "we re-index nightly" is cheap and "we retrieve 20 chunks" is expensive. And a system prompt that is 1,500 tokens long is in every request; trimming it is often the single biggest saving.
Caveat: prices change, and the calculator uses the price you type in. Check the vendor's page that day rather than a figure from a blog post. /learn/embeddings and /learn/vector-database cover the vocabulary if any of this is new.