LLM context planning
Split the text. See the overlap.
Plan fixed-token chunks before you build a retrieval pipeline. See the number of chunks, repeated tokens, and the final chunk length.
View calculation ↓Keep the boundaries visible.
Fixed-size sliding windows with a full overlap between adjacent chunks.
Enter counts from your tokenizer or usage report. Character estimates are not exact token counts.
A little repetition adds up.
Sliding windows
200 tokens overlapFirst 5 of 6 chunks. Hatched areas repeat from the preceding chunk. Positions use zero-based, end-exclusive token offsets.
| Chunk | Start | End | Length |
|---|---|---|---|
| 1 | 0 | 2,000 | 2,000 |
| 2 | 1,800 | 3,800 | 2,000 |
| 3 | 3,600 | 5,600 | 2,000 |
| 4 | 5,400 | 7,400 | 2,000 |
| 5 | 7,200 | 9,200 | 2,000 |
This is chunk-text arithmetic. It does not execute retrieval, estimate embedding cost, or predict answer quality. Semantic boundaries and retrieval settings need their own evaluation.
The formula, in plain sight.
Empty source → 0 chunks. Source up to one chunk → 1 chunk. Otherwise: 1 + ceil((length − size) / (size − overlap)). Processed tokens: length + (chunks − 1) × overlap for nonempty input.
How to calculate token chunks and overlap
Fixed-token chunking splits a source into windows. Overlap repeats tokens between adjacent chunks, so the total processed token volume can exceed the original source length.
- Enter the source length in tokens and a positive chunk size.
- Choose an overlap smaller than the chunk size; zero means no overlap.
- Inspect the chunk count, duplicated tokens and zero-based boundary table.
Worked example
A 10,000-token source with 2,000-token chunks and 200-token overlap produces six chunks, 1,000 duplicated tokens and a final chunk of 1,000 tokens.
The formula models fixed-size windows with full overlap. It does not choose semantic boundaries, measure retrieval quality or estimate embedding prices. Read the formulas and sources.