Skip to content

Chunk Size Calculator

Document size, chunk size and overlap in; chunk count, total tokens stored, the storage amplification and the embedding cost out.

This is an estimate, not a token count. Everything below is exact arithmetic on the token total you give it. The only estimate is what happens if you paste a document instead of typing a total — the token count of that paste is approximate, and every figure derived from it inherits the error. For the exact figure, read the usage object on any completion response — prompt_tokens and completion_tokens are what you are billed on, they cost nothing to read, and they settle the question for the model you are actually calling.
Chunks
112

57,104 tokens embedded in total — 1.14× the document, because each chunk repeats 64 tokens of the one before it.

Document size
50,000 tokens
Stride (chunk − overlap)
448 tokens
Chunks
112
Tokens stored across all chunks
57,104
Duplicated by overlap
7,104 tokens
Storage amplification
1.14×
Size of the final chunk
272 tokens
Overlap as a share of each chunk
12.5%
One-off embedding cost
$0.0057
The same document without any overlap
98 chunks · $0.0050
What this assumes: A fixed-size sliding window: chunk one starts at token zero, each following chunk starts one stride later, and the last chunk is whatever is left — so it is usually shorter than the others. Real splitters respect sentence or paragraph boundaries and will land a few per cent either side of these numbers. The embedding cost counts every token stored, overlap included, because you pay to embed the duplicate too. Vector storage itself is not priced here.

What the overlap is buying, and what it costs

Overlap exists because a fixed-size window cuts wherever the token count says to, not where the meaning ends. A definition split across the boundary is retrievable from neither half; repeating the last few dozen tokens of each chunk at the start of the next makes sure that any short span of text appears intact somewhere. That is the whole argument for it, and it is a good one.

The price is visible above as the amplification factor. At a 512-token chunk with 64 of overlap you store about 14% more tokens than the document contains; at 128 of overlap on the same chunk size it is about 33%. You pay that premium three times — once to embed, once in vector storage, and once again on every re-index when you change model or chunking strategy. Push overlap much past a quarter of the chunk size and you are mostly paying to store the same sentences repeatedly.

Chunk size itself is the more consequential dial and it is not a cost question. Small chunks retrieve precisely and lose context, so the model gets the right sentence without the paragraph that made it mean something. Large chunks carry context but dilute the embedding, so retrieval gets vaguer as the chunk covers more topics. There is no universal answer; there is only the answer for your corpus, which you find by fixing an evaluation set of real questions and trying three sizes against it. Use this calculator to know what each option costs before you run that test, not instead of running it.

Chunk Size Calculator · Multigrid