What the Context Window Planner does
This planner divides a model's context window between everything a request carries - system prompt, tool definitions, retrieved chunks, conversation history, the user's message - and the room the model needs to write its answer, then shows whether it fits and, if not, exactly how many tokens to cut from which section.
It is arithmetic in your browser, and the arithmetic matters because the window is shared: on current OpenAI, Anthropic and Google APIs the output and any reasoning tokens come out of the same budget as the prompt. A 200,000-token model given a 198,000-token prompt has room for a two-thousand-token answer at most, and usually fails well before that.
How to use it
- Choose a model to fill in its context window from the provider's model page, or type the window you use. Where no official figure was confirmed, the field is left for you.
- Set the output reserve - the longest answer you expect, plus reasoning tokens if the model thinks before answering - and a safety margin for token counts that are estimates.
- Enter each section's size in tokens. Mark the ones you can shorten as truncatable, give them a minimum you will never go below, and a priority: 1 is kept longest, the highest number is cut first.
- Read the allocation bar and findings. Switch between priority and proportional truncation to compare plans, then download the plan as CSV or JSON for your prompt-assembly code.
Reading the results
Headroom is what is left inside the usable window (the window minus the safety margin) after every section and the output reserve. Overflow is the opposite: how far over you are before truncation.
The priority strategy empties the least important truncatable section down to its minimum before touching the next - typically old history before retrieved documents. The proportional strategy shares the cut across all truncatable sections by how much each has above its minimum, rounding each cut up so the plan always fits.
If fixed sections, minimums and the output reserve alone exceed the usable window, no truncation plan exists and the planner says so rather than inventing one. That is the signal to shorten a fixed section, lower a minimum or choose a larger window.
Worked example: a RAG assistant on a 200,000-token model
Claude Haiku 4.5 has a 200,000-token window. With a 5% safety margin the usable window is 190,000 tokens. The request carries a 2,500-token system prompt, 3,500 tokens of tool definitions, 120,000 tokens of retrieved chunks, 80,000 tokens of history and a 1,200-token user message, plus an 8,000-token output reserve: 215,200 tokens in all, 25,200 over.
By priority, conversation history (priority 4) is cut first: 25,200 tokens come out of it, leaving 54,800 - well above its 6,000 minimum - and the retrieved chunks are untouched. The plan fills the usable window exactly.
Proportionally, the cut is shared by what each section has above its minimum: chunks have 96,000 spare and history 74,000, so chunks lose ceil(25,200 x 96/170) = 14,231 and history ceil(25,200 x 74/170) = 10,970. Which is better depends on whether your answers need the documents or the conversation more.
Formulas and scoring rules
- Usable window
usable = floor(window x (1 - margin / 100))- Overflow
overflow = sum(section tokens) + output_reserve - usableZero or less means it fits.- Can it fit at all
sum(fixed sections) + sum(minimums of truncatable sections) + output_reserve <= usable- Priority truncation
cut_i = min(remaining overflow, tokens_i - min_i), highest priority number firstTies are broken by cutting the later section first.- Proportional truncation
cut_i = ceil(overflow x (tokens_i - min_i) / sum(tokens_j - min_j))Rounding up can leave a token or two of headroom; it never leaves an overflow.
Why plan below the maximum
A full window is not a good window. Token counts for Claude and Gemini can only be estimated outside their APIs, so a margin of 5-10% absorbs the error. Models also tend to use information near the start and end of a long prompt more reliably than the middle, so pushing more retrieved text into the window does not always improve answers.
Cost rises with the prompt, too: every input token is billed on every request. A plan that keeps history at a summary and retrieves eight good chunks instead of forty mediocre ones is often both cheaper and better. The LLM API Cost Calculator shows what each extra thousand tokens costs per month.
Limitations: what the result does not prove
- Token sizes are your figures. Count real samples with the AI Token Counter; averages hide the long requests that actually overflow.
- It plans a single request. Multi-turn agents grow with every tool result, so re-plan at the size the conversation reaches, not the size it starts at.
- It does not decide what to keep inside a section - which turns to summarise or which chunks rank highest. That is your retrieval and memory logic.
- Some providers add hidden tokens for tool use or formatting that are not in your prompt; Anthropic, for instance, adds a tool-use system prompt of a few hundred tokens whenever tools are present.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- Anthropic Claude API pricing - checked 19 Sep 2026
- OpenAI API pricing - checked 19 Sep 2026
- Anthropic - Context windows
- Anthropic - Models overview (context window and max output per model)
- Google - Gemini long context
- OpenAI - GPT-5 model page
Frequently asked questions
Do output tokens count against the context window?
Yes. On current OpenAI, Anthropic and Google models the prompt and the generated answer, including any reasoning or thinking tokens, share one window. If the prompt leaves too little room, the answer is cut off when it reaches the limit, so always reserve space for output.
How big should the output reserve be?
At least the longest answer you want, plus the reasoning budget if the model thinks first. A short chat reply may need 1,000-2,000 tokens; a model writing code or reasoning at high effort can use tens of thousands. Look at the output token figures in real responses' usage data and add a margin.
Should I truncate conversation history or retrieved documents first?
Usually old history first: the last few turns carry most of the context, and earlier turns can be replaced by a short summary. Retrieved chunks are chosen for the current question, so cutting them hurts the answer more - but keep only the highest-ranked ones rather than everything the retriever returns.
What does the safety margin protect against?
Token counts that are estimates or averages. Claude and Gemini tokenizers are not public, so counts made outside their APIs can be off by tens of percent, and real requests vary in length. A margin of 5-10% of the window keeps a request that is slightly larger than planned from failing.
Is a bigger context window always better?
No. Larger prompts cost more on every call, take longer to process, and models do not use every part of a very long prompt equally well. A 1M-token window is valuable for whole-repository or long-document tasks, but most assistants work better with a tighter, well-chosen context.
Last reviewed by the A2Z.Tools team against the sources listed above.
