Context Window Usage
See how much of a model’s context window your prompt uses and how many tokens remain.
Formula last reviewed 4 August 2026 · How we verify our calculators
Context used
- Tokens remaining
- 5,00,000
Updates live as you type
Frequently asked questions
It is the maximum number of tokens a model can consider at once — your prompt plus its response. Exceeding it truncates input or causes errors, so usage must stay within the limit.
Usage % = prompt tokens ÷ context window limit × 100. With 500K tokens used of a 1M window, you are at 50% with 500K remaining.
Yes. The window holds both input and generated output, so leave headroom for the reply — filling the window with prompt leaves no room to answer.
Very long contexts can raise latency and cost and may dilute the model’s focus. Keeping prompts lean often improves both quality and price.
Half a million of a million used
A prompt of 500,000 tokens against a context window limit of 1,000,000 uses 50% of the available window, leaving 500,000 tokens remaining.
The context window is the total number of tokens a model can consider at once — everything in the request plus everything it generates in response. It is a hard architectural limit, not a soft guideline, and exceeding it causes a request to fail or content to be silently dropped.
What occupies the window
Everything, and the components are easy to underestimate:
System prompt — instructions, persona, constraints, output format specifications. Frequently 1,000–5,000 tokens in a production application.
Conversation history — every prior turn, user and assistant. In a long chat this dominates everything else.
Retrieved context — documents, search results, database records attached to the prompt.
Tool and function definitions — schemas for every available tool, sent on every request. With a dozen tools this is substantial.
Tool results — the output of each tool call, which in an agentic loop accumulates rapidly.
The user's actual message — usually the smallest component by a wide margin.
Reserved output space — the response must fit in the window too. A request filling 99% of the window leaves no room to answer.
Why usage matters before you hit the limit
Two effects appear well before the hard limit:
Cost. Input tokens are billed on every request. A conversation at 80% of a large window is expensive per turn, and in a chat application that cost is incurred again on every subsequent turn.
Degraded retrieval within context. Models do not attend uniformly across a long context. Information placed in the middle of a very long prompt is measurably less reliably used than information at the beginning or end — the effect usually described as "lost in the middle". Filling a window does not guarantee the model uses what is in it, and for accuracy-critical instructions, position matters.
A practical consequence: put the most important instructions at the start or the end of a long prompt, not buried in the middle.
Managing the window
Truncate conversation history — keep the most recent turns and drop or summarise older ones.
Summarise rather than discard. Replacing twenty old turns with a 200-token summary preserves continuity at a fraction of the cost.
Retrieve selectively. Attaching the five most relevant chunks beats attaching fifty, both for cost and for accuracy.
Prune tool definitions. Send only the tools relevant to the current task rather than the entire catalogue.
Cache the fixed prefix. A stable system prompt and document context should be cached rather than re-sent at full price.
Reserve output space explicitly. Leave enough headroom for the longest response you expect, plus margin.
Reading the result
Usage above roughly 70–80% is a signal to act — either to summarise history or to reduce retrieved context — rather than a level to sit at comfortably.
The remaining tokens figure is the ceiling on the response, not a target. If you need a 4,000-token answer, you need at least that much headroom before the request is sent.
Note that token counts here are estimates; different models tokenise differently, so a prompt fitting one model's window may not fit another's even at the same nominal size.
Common mistakes
Forgetting the response needs room. The window covers input and output together.
Ignoring tool definitions. They are sent on every request and add up.
Letting conversation history grow unbounded. Cost grows quadratically and quality degrades.
Assuming a full window is used well. Attention is uneven across long contexts.
Placing critical instructions in the middle. Start or end is measurably more reliable.