Every language model reads a limited amount of text at once. That limit is called the context window, and it is measured in tokens — the small chunks of text, roughly parts of words, that the model processes. When your prompt, together with any system instructions and the space you reserve for the answer, exceeds that window, something has to give. Usually the model silently drops the earliest part of the input, which is often the part containing your instructions, or it refuses the request, or it truncates its answer mid-sentence. All three failures share an unpleasant property: they look, at first glance, like the model misunderstood you, when in fact you gave it more than it could hold.
The Context Window Planner prevents that confusion. You enter the model's context size, your prompt, your system text, and the amount of space you want to reserve for the output, and it shows you what remains, along with an estimated word budget. The point is to do the arithmetic before you run the prompt, when it is cheap to fix, rather than after a failed or degraded run, when the cause is hard to diagnose.
How the tool works
The planner works from four numbers. The context size is the model's total window, as stated by its provider — commonly figures such as 8,000, 32,000, 128,000 or 200,000 tokens, depending on the model. Your prompt is the text you send, counted in tokens. Your system text is the instruction text that frames the model's behaviour, which also consumes window space even though you may think of it as separate from the prompt. The output reserve is the space you set aside for the answer: if you need a long reply, you must reserve generously, because output tokens come out of the same window as input tokens.
Subtracting the prompt, the system text and the output reserve from the context size gives the remaining tokens: the headroom you have left. If that number is negative, your request does not fit, and you must shorten something before running it. If it is small, your request fits but leaves no room for a longer answer than you reserved, and the model may stop early. If it is large, you have room to add examples, context or documents — or to switch to a smaller, cheaper model whose window still fits your needs.
The estimated word budget translates tokens into approximate words, because most people think in words rather than tokens. The conversion is rough: a common rule of thumb is that one token is about three quarters of a word in English, but the true ratio varies with the text. Code, numbers, non-English text and unusual formatting all tokenise differently. Treat the word estimate as a planning aid, not a precise measurement, and trust the token count over the word count when they disagree.
A worked example
Suppose you are working with a model whose context window is 128,000 tokens. Your prompt — a document excerpt plus your question — measures 3,200 tokens. Your system text, a set of style and formatting instructions, measures 800 tokens. You want a detailed answer, so you reserve 2,000 tokens for output. The planner's arithmetic is: 128,000 minus 3,200 minus 800 minus 2,000, which is 122,000 tokens remaining. That is a comfortable margin: your request uses only 6,000 tokens of the window, leaving 122,000 spare.
The estimated word budget for the remaining space, using the rough three-quarters rule, is 122,000 multiplied by 0.75, which is 91,500 words. That figure is far larger than any single answer you are likely to need, and it tells you something useful: you could add much more context — several more documents, or a longer conversation history — before this window became a constraint. Alternatively, you could switch to a model with a 32,000-token window, where the same request would leave 32,000 minus 6,000, which is 26,000 tokens spare, still comfortable, and possibly at lower cost or higher speed.
Now consider the opposite case. Suppose the same request were sent to a model with an 8,000-token window. The remaining space would be 8,000 minus 6,000, which is 2,000 tokens — exactly your output reserve, with no headroom at all. Any slight growth in the prompt, or any answer longer than you reserved, would overflow. The planner makes that fragility visible before you run anything, which is when you can still choose a larger model, shorten the prompt, or trim the system text.
Common mistakes
The first mistake is forgetting the system text. Many people count only their visible prompt and are surprised when a request fails, because the system instructions — sometimes long, sometimes set by an application rather than by the user — consume window space invisibly. Always include system text in your budget, and if you do not know how long it is, assume it is longer than you think.
The second mistake is reserving too little output space. A model that runs out of output room does not warn you politely; it simply stops, often mid-sentence or mid-list, leaving an answer that looks complete at a glance but is missing its conclusion. Reserve for the answer you actually want, including any formatting, lists or examples, and add a margin for answers that run longer than expected.
The third mistake is assuming that a bigger window is always better. Larger windows can cost more and run slower, and very long inputs can dilute a model's attention: the relevant instruction buried in the middle of a huge context is easier to overlook than the same instruction in a focused prompt. Fit the window to the job. If your prompt is short, a modest window used well beats a huge window filled with irrelevant material.
The fourth mistake is treating token estimates as exact. Token counts depend on the specific tokeniser a model uses, and two models can count the same text differently. Use the planner's figures to plan and to compare options, but verify against the provider's own count or usage report when a request is near the limit. A margin of a few hundred tokens near the boundary is not a margin at all.
Honest limitations
The planner budgets space; it does not judge content. It cannot tell you whether your prompt is well written, whether your examples are relevant, or whether the model will answer correctly. It estimates words from tokens using a rough ratio, and for code, mathematics, or languages other than English, that estimate can be noticeably off. It also relies on the context size you enter: if a provider changes a model's window, or if an application imposes a lower effective limit than the model's maximum, the planner's answer will reflect the number you gave it, not the real constraint. Check the provider's current documentation for the model you are actually using.
Closing
Budget before you run: context size minus prompt minus system text minus output reserve, and check that the remainder leaves real headroom. To count tokens in a draft directly, try the AI Token Counter, and to store proven prompt structures for reuse, see the Prompt Template Builder. For writing the prompts themselves well, read How to Write Better Prompts and Reusable Templates.