Knowledge base sizing calculator.

Most agencies size knowledge bases by feel. They dump every document a client sends into one index, watch the first few test calls go fine, and ship it. The failure shows up later, and it does not look like an error. It looks like a fluent, confident, wrong answer delivered to a real caller who has no reason to doubt it. That is the specific risk of an oversized base: the retriever has more near-miss chunks to choose from, so it picks one that is close enough to sound right and far enough to be false.

The model here is deliberately simple. Content volume is your document count times average size times languages, because a second language is a second full copy, not a translation layer at call time. Divide by roughly 50,000 words per base and round up. That ceiling is not a platform limit, it is the point where topic bleed starts appearing in real deployments. Split by topic before you hit it: services in one base, policies in another, pricing in a third. Three clean bases beat one crowded one, and at $12 each the math is not close.

The token line is the one people misread. The indexed figure is your corpus size, a one-time consideration. The number that recurs is per answer, and it stays near 2,000 tokens whether your base holds 5,000 words or 50,000, because retrieval pulls a few chunks rather than the whole index. Bigger bases do not make calls more expensive. They make calls less accurate. Size for retrieval quality and the cost takes care of itself. On Hermes each client is a separate workspace with its own bases from $149 a month, so no client content is ever one retrieval away from another client's caller.