LLM Context Window Planner
Break a request down across system prompt, tools, history, documents and reserved output, and see where it overflows. The counts are yours: this page has no tokenizer and will not guess at one.
context-budget.txt
updates as you typeCommon mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Sizing the prompt against the context window and stopping there
`max_tokens` reserves space in the same window. A prompt that fits alone overflows once the answer's budget is added, and the failure is a rejected request or a response that stops mid-sentence.
Instead:Budget prompt plus `max_tokens` against the window, not the prompt alone.
Setting `max_tokens` from the expected answer length with thinking on
Reasoning tokens are output tokens and count against the same cap. On a hard task they can consume the whole budget, producing a response that hit the limit having said nothing readable.
Instead:Several times the expected answer on demanding work, and branch on the stop reason so truncation is detected.
Treating a comfortable margin as settled
History grows every turn without anyone deciding it should. A margin that looks fine at turn three is gone by turn thirty, and nothing prompts you to look.
Instead:Decide the eviction strategy now, before you need it: compaction, clearing old tool results, or your own truncation.
The window holds the question and the answer together
A prompt that fits on its own can still overflow, because max_tokens reserves space in the same window. That is the arithmetic this page does, and it is the one people skip.
max_tokens is an output cap, not a window
Two separate limits. The context window is the total the model can hold; the output ceiling is the most it will produce in one response, and it is much smaller. Exceeding the output ceiling is a rejected request. Exceeding the window is a rejected request or a truncated answer, depending on where the overflow happens.
Thinking spends the output budget
Reasoning tokens are output tokens: billed as output, counted against max_tokens. A budget sized around the answer you expect can be consumed almost entirely by thinking on a hard task, producing a response that hit the cap having said nothing. Give it real headroom, several times the expected answer on demanding work.
History is the part that grows without a decision
System prompt and tool definitions are chosen once. Conversation history grows every turn, and nothing prompts anyone to notice. A margin that looks comfortable at turn three is gone by turn thirty, which is why the tight-headroom warning here is a schedule rather than a suggestion.
Tool definitions render first and are paid every turn
They sit ahead of the system prompt in the rendered prompt, so they are both a fixed per-request cost and the front of the cache prefix. When they are a large share of the prompt, the tool list is the request.
Decide the eviction strategy before you need it
Something has to go when the window fills: compaction, which summarises earlier turns; context editing, which clears stale tool results outright; or your own truncation. All three are better chosen deliberately than discovered during an incident.
What this cannot see
The token counts. This page ships no tokenizer and calls no API, so every figure it produces is exactly as accurate as the numbers you enter. A character-count approximation was considered and rejected: it is wrong by a wide and unpredictable margin, particularly on code and on non-English text, and a confidently wrong budget is worse than no budget. Use the provider's token counting endpoint against your real prompt, then bring the numbers here.