A context window is not a document-size allowance. It is a shared token budget for the material you send, the instructions and conversation already present, and the answer the model generates. A 128,000-token window therefore does not mean that you can safely paste 128,000 tokens of source material.
The practical calculation is:
document budget = context window - system and tool tokens - conversation history - output reserve - safety margin
Use the Context Budget Calculator embedded with this article to estimate that budget before a request. Treat its word, page, and code conversions as ranges, then confirm the final prompt with the model provider’s tokenizer or token-counting endpoint.
Verified / updated: 2026-07-24. Model limits and token behavior cited below were checked against official OpenAI, Anthropic, and Google documentation on that date. Limits can differ by model, endpoint, account, and hosting platform, so check the model page used by your application before deployment.
Tokens are not words
A token is a unit produced by a tokenizer, not a fixed number of characters or words. A short common word may be one token; a long or unusual word may become several. Punctuation, spaces, source-code symbols, and non-English scripts can change the ratio.
Google’s official token guide gives a useful English-language estimate for Gemini: one token is about four characters, and 100 tokens are about 60–80 English words. It also provides a countTokens method for measuring the actual input. That range is a planning aid, not a universal conversion rule for every tokenizer (Google token guide).
For rough English prose planning:
- 1,000 tokens may represent roughly 600–800 words.
- 10,000 tokens may represent roughly 6,000–8,000 words.
- 128,000 tokens may represent roughly 76,800–102,400 words before subtracting every other context consumer.
The last line is deliberately not a promise about how much document text will fit. The model still needs room for instructions, chat history, tool definitions, retrieved material, reasoning where applicable, and its response.
When accuracy matters, estimate first and count second. Google documents a token-counting API; Anthropic’s Token Counting endpoint accepts the same structured inputs used to create a message, including system prompts, tools, images, and PDFs. Anthropic also notes that its preflight result is an estimate and may differ slightly from actual message usage (Anthropic token counting, checked 2026-07-24). OpenAI model responses expose token usage, while model-specific tools or supported tokenizer libraries should be used for preflight counting. Do not carry a count from one provider’s tokenizer into another provider’s model and assume it is exact.
Estimate words, pages, and code differently
Words are the least misleading human-readable input for ordinary English prose, but even that conversion is a range. Pages introduce another assumption: a page might contain 250 words in a spacious report, 500 words in a dense manuscript, or something else entirely. The calculator should therefore let you set words per page instead of presenting one page count as fact.
A defensible workflow for prose is:
- Count the document’s words.
- Convert words to a low and high token estimate.
- Apply the context-budget deductions.
- Report a page range using an explicit words-per-page assumption.
- Confirm the final assembled request with the relevant tokenizer.
Code needs a separate path. Identifiers, indentation, punctuation, minified files, generated data, and long encoded strings do not resemble natural-language word counts. Counting “words” in a repository can substantially misrepresent its token load. For code, start from characters or, preferably, run the exact selected files through the provider’s tokenizer. Exclude build output, vendored dependencies, lockfile noise, binary data, and files unrelated to the question.
This distinction also matters for local models. A model may fit in memory while the desired prompt does not fit comfortably beside its key-value cache and runtime overhead. If you are planning local inference, pair the context calculation with the site’s guide to local LLM VRAM requirements.
Reserve output, instructions, and a safety margin
Start with the model’s documented context window, but do not use it as the document budget. Subtract known consumers in a fixed order:
| Budget item | What it includes | How to estimate it |
|---|---|---|
| System and developer instructions | Policies, role instructions, formatting rules | Count the actual static prompt |
| Tool schemas | Function names, descriptions, JSON schemas | Count the tools enabled for this request |
| Conversation history | Earlier user and assistant turns | Read usage telemetry or count the assembled history |
| Retrieved context | Search results, RAG chunks, file excerpts | Count after retrieval and deduplication |
| Output reserve | The answer, code, or structured data you need back | Set from the task’s realistic maximum |
| Safety margin | Tokenization variance and unexpected additions | Choose a visible percentage or fixed amount |
The output reserve is not spare capacity. It is part of the request plan. If you need an 8,000-token report, reserve 8,000 tokens even when a typical answer is shorter. Structured output, tool calls, and reasoning modes may add consumption that a plain-text estimate misses.
Keep the safety margin explicit rather than hiding it inside a conversion factor. A margin of 10% is a planning example, not a provider recommendation or guarantee. Increase it when documents are multilingual, code-heavy, assembled dynamically, or passed through tools that add material. Reduce it only after measurements show that the complete request remains stable.
This accounting is especially important in tool-heavy agents. For practical ways to shrink tool descriptions and results, see how to reduce MCP token usage.
Check the current model limit
Context and output limits are specifications, not permanent properties of a brand name. They can change between model families, snapshots, APIs, and cloud hosts. The following examples were verified on 2026-07-23 and are included to show why both columns matter:
| Example model or family | Documented context window | Documented maximum output | Official source |
|---|---|---|---|
| OpenAI GPT-5.6 Sol | 1,050,000 tokens | 128,000 tokens | OpenAI GPT-5.6 Sol model page |
| Anthropic Claude Fable 5 | 1,000,000 tokens | 128,000 tokens | Anthropic context-window documentation |
| Google Gemini 3 models | 1,000,000 input tokens | Up to 64,000 output tokens | Gemini 3 developer guide |
These figures should not be copied into a permanent calculator preset without an update process. Google states that the context window is the combined input-and-output limit and recommends retrieving inputTokenLimit and outputTokenLimit programmatically from model metadata. Its token guide also confirms that system instructions and tool definitions count as input. Anthropic says its context window includes the response itself, along with system prompts, messages, tool definitions, documents, and applicable thinking tokens. OpenAI publishes context and maximum-output fields per model; its conversation-state guide defines the window as the per-request maximum across input, output, and reasoning tokens where applicable (OpenAI conversation state, checked 2026-07-24).
The safe implementation is to store the verification date next to any preset, allow manual overrides, and display the source. If a provider page and an API response disagree, stop and investigate rather than selecting the larger number.
Large windows do not guarantee good recall
Fitting is a capacity test, not a quality test. Anthropic’s current context guidance explicitly warns that more context is not automatically better and that accuracy and recall can decline as token count rises. Google’s long-context guidance likewise recommends thinking deliberately about how large inputs are used rather than treating the window as unlimited memory.
Long prompts can fail without producing an over-limit error. The answer may overlook a clause buried in the middle, confuse two similar sections, or spend attention on irrelevant boilerplate. A successful API response only proves that the request was accepted.
Use three gates:
- Capacity gate: Does the assembled request fit after all reserves?
- Relevance gate: Is each included section needed for this question?
- Quality gate: Does the model retrieve and cite known facts from the beginning, middle, and end?
For repeated document workflows, test several prompt sizes against a small set of questions with known answers. Record recall and citation accuracy by position. Prefer filtered excerpts or retrieval when they preserve answer quality with less context. If a stable prefix is repeatedly reused, caching may reduce cost, but it does not create extra context capacity; prompt-cache misses and prefix design are a separate operational concern.
Worked document examples
Suppose a model has a 128,000-token context window. Your application uses 4,000 tokens for system instructions and tools, carries 12,000 tokens of history, reserves 8,000 tokens for output, and applies a 10% safety margin to the full window:
available = 128,000 - 4,000 - 12,000 - 8,000 - 12,800 = 91,200 tokens
Using the broad English planning range of 60–80 words per 100 tokens, 91,200 tokens correspond to roughly 54,720–72,960 English words. At an assumed 300 words per page, that is about 182–243 pages. The page result changes immediately if typography, tables, footnotes, or the words-per-page assumption changes.
Now consider a 70,000-word report. The same rough ratio places it between about 87,500 and 116,667 tokens. The upper estimate exceeds the 91,200-token document budget, so the correct result is not “it probably fits.” The calculator should flag the risk and recommend counting the exact assembled request.
For a code review, suppose the selected files total 500,000 characters. Do not divide by an English word ratio. Enter the character count with a clearly labeled adjustable code coefficient, or tokenize the files directly. Then add the review instructions, repository map, issue description, and expected patch or explanation to the same budget. A context-aware file selection is usually more reliable than sending the entire repository.
Truncation checklist
Before sending a near-limit request:
- Confirm the exact model ID, endpoint, context limit, and maximum output.
- Count the complete assembled request, not just the main document.
- Reserve output before allocating document space.
- Include system prompts, tools, history, retrieved chunks, and attachments.
- Remove duplicate passages, navigation text, logs, generated files, and irrelevant history.
- Test retrieval from multiple positions in the document.
- Define what the application does when over budget: reject, summarize, split, or retrieve. For agent workflows, enforce that policy before the request with token budgets and circuit breakers.
- Log actual input and output usage so future estimates can be calibrated.
FAQ
Does a 128K context window hold 128K input tokens?
Not necessarily. Output and other request components can share that window, depending on the provider and model. Budget them before assigning the remainder to input.
How many pages fit in 128K tokens?
There is no provider-independent answer. With a rough English estimate of 60–80 words per 100 tokens, 128K tokens represent about 76,800–102,400 words before deductions. Divide the remaining word range by your document’s measured words per page.
Why does code need a different estimate?
Tokenizers split punctuation, whitespace, identifiers, and encoded strings differently from prose. Character-based estimates are still approximate; exact tokenization is preferable.
What should happen when the estimate is over budget?
Do not silently truncate. Remove irrelevant material, split the task into independently answerable parts, summarize with validation, or retrieve only the passages needed. Preserve document identifiers and section boundaries so answers remain auditable.
Does prompt caching increase the context window?
No. Caching can reduce repeated-input cost or latency, but cached tokens can still count toward the context window. Use the documented context limit and count the complete request even when part of the prefix is cached.
Primary sources
The following provider documentation was checked on 2026-07-24:
- OpenAI GPT-5.6 Sol model page: context and maximum-output limits.
- OpenAI conversation-state guide: how input, output, reasoning, and prior-response context affect the window.
- Anthropic context-window documentation: components counted in Claude context and current model limits.
- Anthropic token-counting documentation: preflight counting scope and estimate caveat.
- Google token guide: rough English conversion,
countTokens, multimodal counting, and model metadata fields.