The context window planner above adds up everything competing for space inside a single model request — the system prompt, tool schemas, conversation history, retrieved documents, and the tokens you need left over for the answer — and compares the total against the window of the model you have chosen. It then tells you how many more conversation turns you can absorb before the request stops fitting.
Arb Digital builds this budget before writing a prompt, because context overflow is not a gradual degradation. It is a request that fails, or worse, a request that silently drops the beginning of a conversation and returns a confident answer built on half the information. This tool makes the ceiling visible while it is still cheap to design around.
What This Context Window Planner Does
Enter the size of each component of your prompt and the window of your target model. The headline figure is total context consumed including the reserved output allowance. The grid breaks out input tokens alone, the percentage of the window in use, the raw headroom remaining, and the number of additional conversation turns that headroom will absorb at your current turn length.
The bars show the four components as proportions of the total, which usually settles an argument quickly. Teams tend to assume the system prompt is the problem. In retrieval-heavy applications it is almost always the retrieved chunks, and in long-running chat it is almost always history.
How to Use It
- Count your system prompt. Include everything sent on every request — instructions, persona, formatting rules, and any static examples. The prompt token estimator converts the text directly.
- Add tool definitions. Function and tool schemas are serialised into the request. A dozen tools with detailed parameter descriptions can easily exceed the system prompt itself.
- Set history depth and turn size. Use a realistic average for your product, not a short test conversation.
- Add retrieved chunks. Multiply top-k by chunk size; the RAG chunk size calculator gives both figures if you are still choosing them.
- Reserve an output budget and set the model window, then click Calculate. Look at the extra-turns figure as much as the percentage.
The Formula / How It's Calculated
Input tokens are system + tools + (turns × tokens per turn) + (chunks × tokens per chunk). Total context is that plus the output budget, because on most models input and output are drawn from one shared window: a 128,000-token window with 120,000 tokens of input leaves only 8,000 for the answer, regardless of what maximum output you request.
Headroom is window − total, and the extra-turns figure is headroom ÷ tokens per turn, rounded down. That last number is the practical one. A conversation that starts at 30% of the window and grows 350 tokens per turn has a fixed number of exchanges before it hits the wall, and knowing that number tells you when your trimming strategy has to engage.
Reserve Output Space, Don't Hope for It
Most model APIs accept a maximum output parameter and then fail, or truncate, if the input plus that maximum exceeds the window. Requesting 4,000 tokens of output on a request whose input has crept to within 2,000 tokens of the limit produces an error rather than a shorter answer.
Treat the output budget as a reservation made first, then fill the remainder with input. If your application produces long structured output — a report, a table, a rewritten document — reserve generously, because a truncated JSON object is worse than no answer at all: it parses as a failure downstream and often triggers a retry that costs the whole input again. Provider documentation is explicit about which models share input and output space and which cap output separately; Anthropic's context windows documentation and OpenAI's model reference both publish the limits per model.
History Grows Until Something Stops It
Every chat application eventually needs a trimming policy, and the choice between them changes both cost and quality. A sliding window keeps the last N turns and drops the rest — simple, predictable, and it forgets what the user said at the start, which is frequently the most important thing in the conversation. Summarisation compacts older turns into a short recap, preserving the thread at the cost of an extra model call and some loss of detail.
A hybrid works well in practice: keep the system prompt and the first user message verbatim, summarise the middle, and keep the last few turns in full. Whatever you choose, set the trigger below the limit rather than at it. Firing compaction at 90% of the window leaves no room for an unusually long user message arriving at the wrong moment. Around 70% gives you a margin that absorbs surprises.
A Larger Window Is Not a Free Window
Long-context models make overflow less likely, and they solve nothing about cost. Every token in the window is billed as input on every request, so a conversation that grows to 100,000 tokens costs roughly ten times one that stays at 10,000 — for the same answer quality, if the extra 90,000 tokens were history nobody needed. In agent loops the effect compounds, which the AI agent cost calculator models directly.
Retrieval quality is the second reason not to fill a window just because it is available. Research on long-context behaviour, including the "Lost in the Middle" study by Liu and colleagues, found that models attend most reliably to information at the beginning and end of a long input, with material buried in the middle used less consistently. The design implication is practical: put the instruction and the most relevant retrieved passage where they are hardest to miss, and prefer five well-ranked chunks over twenty mediocre ones.
The Silent Consumers Nobody Budgets
Several things occupy the window without appearing in anyone's estimate. Tool schemas are the largest: a well-documented tool with six parameters and clear descriptions can run to several hundred tokens, and tools are sent on every request whether or not the model uses them. Structured output schemas behave the same way.
Tool results are the other one. When a model calls a tool, the result is appended to the conversation and stays there, so a search returning 3,000 tokens permanently consumes that space for the rest of the exchange. Attachments matter too — an image or a document consumes a token allowance determined by its resolution or length, and a user uploading three screenshots can move you thousands of tokens closer to the ceiling in a single turn. Add a line for each of these before trusting a budget.
What Actually Happens When You Overflow
Behaviour varies by provider and by framework, and the variation is the risk. Some APIs return a clear error naming the token count, which is the best case because it fails loudly. Some client libraries silently drop the oldest messages to make the request fit, which produces an answer that looks fine and is missing the constraint the user set three turns ago. Some truncate the input from one end without warning.
Whichever your stack does, count tokens before sending rather than relying on the provider to handle it. Log the token count of every request, alert on the ninetieth percentile rather than the average, and test with a deliberately long conversation — the ceiling is only ever hit by your most engaged users, which is exactly the group you least want to break things for. Compare your projected request shape across models with the AI model comparison tool before committing to one window size.
Arb Digital designs prompt architecture with an explicit token budget and a trimming strategy, so the twentieth turn behaves as well as the first.
Browse Free Tools Talk to Arb DigitalCommon Mistakes to Avoid
- Forgetting that output shares the window — a nearly full input leaves no room to generate, and the request fails rather than answering briefly.
- Leaving tool schemas out of the count — they are sent on every request and are often larger than the system prompt.
- Testing only short conversations — overflow appears at turn twenty, with your most engaged users, in production.
- Filling a large window because it is there — every token is billed on every request, and buried content is used less reliably than content at the edges.
- Trusting a framework to trim silently — dropped messages produce plausible answers that ignore instructions the user gave earlier.
Related Free Tools From Arb Digital
Count your text with the AI token calculator, verify a prompt fits with the token limit checker, plan retrieval with the RAG chunk size calculator, price the resulting request in the LLM cost comparison tool, and trim what you send with the prompt cost optimizer. More in the free online tools hub.
Frequently Asked Questions
On most models, yes — input and generated output draw from the same window. A request that fills nearly all of the window with input will fail or truncate rather than produce a shorter answer, so the output allowance should be reserved before the input is assembled.
Yes. Tool and function schemas are serialised into every request whether the model uses them or not. A set of well-documented tools can consume more tokens than the system prompt, so they belong in any context budget.
It depends on the provider and the client library. Some return an explicit error, some truncate the input, and some silently drop the oldest messages. The last case is the most dangerous because the answer looks normal while missing earlier instructions.
Common approaches are a sliding window of recent turns, summarising older turns into a recap, or a hybrid that keeps the first and last messages verbatim and compacts the middle. Trigger trimming well below the limit so an unusually long message cannot push you over.
It reduces the risk of overflow but does nothing about cost, since every token is billed as input on every request. Studies of long-context behaviour also find that information placed in the middle of a very long input is used less reliably than material at the start or end.
It varies by product, but a user message plus an assistant reply commonly falls in the low hundreds of tokens for chat and much higher for technical or document-heavy exchanges. Measure your own average rather than assuming.
Yes. Multimodal inputs are converted into a token allowance based on resolution or document length, so a few uploads can move a conversation thousands of tokens closer to the limit in a single turn.
Figures produced by this tool are planning estimates only — exact token counts depend on your model's tokenizer, message formatting overhead, and how your client library serialises tools and attachments.
