A context window has to hold both your input and the model's response — it's one shared budget, not two separate ones. Estimating whether a document "fits" without accounting for the response space is the single most common way people get this calculation wrong.
The Same Document, Two Different Outcomes
Take a 100,000-token document against a 128K context window:
- With no tokens reserved for a response: uses 78.1% of the window — comfortably fits.
- With 30,000 tokens reserved for a long, detailed response: the available space for input drops to 98,000 tokens, and the same 100,000-token document now uses 102% — it no longer fits at all.
Nothing about the document changed. What changed is how much of the shared budget was set aside for the model's output, which is exactly the detail a raw token count alone doesn't capture.
Why This Trips People Up
It's intuitive to think of "context window size" as available space for your input alone, since that's the part you're actively pasting in. But every response the model generates also draws from that same pool. Asking for a brief one-paragraph answer barely touches the budget; asking for an extensive, multi-section response can reserve a meaningful chunk of it — and that reservation happens regardless of how much room your input already used.
Estimating Your Own Limit
The practical fix is estimating with a reserve that matches what you're actually planning to ask for. A quick factual question needs very little reserved space. A request for a long rewrite, a detailed analysis, or an extensive summary needs considerably more — and building that expectation into the check upfront avoids finding out mid-conversation that a response got cut short because the input left no room for it.
Check your document against real reserved-token scenarios
Open the Context Limit Estimator