What Is a Context Window?
The context window is the maximum number of tokens a single request may occupy, counting the input and the generated output together. It is a hard limit of the deployment: a request that exceeds it is rejected or truncated, never quietly accommodated.
What the window has to hold
Everything in the request counts against it. The system instruction, the conversation history replayed on each turn, retrieved passages, tool definitions, tool results and the reply being generated all draw on the same budget. A chat interface that appears to remember a conversation is generally resending it, which is why the room available for new material shrinks as a session grows longer.
Two limits are frequently discussed as one. The context limit is the total. The output limit is a separate and usually much smaller cap on how many tokens a single reply may contain. A request can sit comfortably inside the context limit and still have its answer cut off by the output limit, which produces a truncation that looks like a content problem and is not.
| Element | Notes |
|---|---|
| System instruction | Present on every request, whether or not it changed. |
| Conversation history | Resent in full unless the application summarises or truncates it. |
| Retrieved passages | Frequently the largest single element in a retrieval system. |
| Tool definitions | Schemas for the available tools, counted whether or not a tool is used. |
| Tool results | Returned content, which can be arbitrarily large unless it is bounded. |
| The generated reply | Counted against the same total, and separately capped. |
The fourth and fifth rows are the ones most often missing from a budget, because they are added by a framework rather than written by the application that pays for them.
What happens as the window fills
Three strategies handle input that does not fit, and each discards something. Truncation drops material at one end, usually the oldest. Summarisation replaces a span with a shorter account of it, a lossy transformation whose losses are chosen by whatever produced the summary. Chunked processing splits the input, processes the parts in order and merges the results, trading the limit for a merge step that can lose any relationship spanning two parts.
A fourth approach has become common enough to name, and it is the only one that changes the shape of the problem rather than the shape of the input. Keep the material outside the window and place into the request only what a given turn needs: a retrieval step does this for a corpus, and a tool result does it for a query, so the window holds a reference and a short extract instead of the whole source. It does not remove the difficulty — the decision about what to fetch is now the thing that can be wrong — but it converts an input that grows without bound into one that does not, and a fixed limit can only ever accommodate the second kind.
A separate and frequently confused question is what a large window is worth. A limit describes what a request may contain; it does not describe how material at every position within it is used. That is measured per deployment, and this registry publishes no measurement of its own.
How the Registry classifies an over-length summarisation task
Summarising a document longer than the request limit by processing it in ordered sections and merging the summaries is filed as information retrieval in this registry's classification: existing material is consulted and compressed, and the merge is machinery rather than a change of class.
The Registry's canonical brief for this entry is filed as:
Summarize a document longer than the request limit by processing it in ordered sections and merging the summaries.
Submitted for assessment it is
classified as Information retrieval, and its wording is hashed once — to
b32de0ec0c3c064f…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/retrieval.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about context window
What any particular deployment's limit is, and how it behaves as that limit is approached, are facts about that deployment. The canonical brief above describes the operation forced by a limit, not the limit itself.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about context window
- What is a context window?
- The context window is the maximum number of tokens a single request may occupy, counting the input and the generated output together. Exceeding it causes the request to be rejected or truncated rather than handled silently.
- Does the context window include the output?
- In the usual arrangement, yes: the generated reply is counted against the same total as the input. A separate and smaller output limit generally caps how long one reply may be, independently of how much room the context limit leaves.
- What happens when the context window is exceeded?
- The request fails, or the input is truncated according to whatever rule the application applies. Applications handle it upstream instead — by truncating history, summarising earlier turns, or splitting the input into ordered parts and merging the results, each of which discards something specific.
- Is a larger context window always better?
- A larger limit removes a constraint; it does not remove the cost of filling one. Every token in a request is paid for and adds latency, and material that is present is not necessarily material that is used. Whether a larger window improves a specific task is measured on that task.
- What is the difference between a context window and memory?
- A context window is a per-request capacity. It is filled at the start of a request and gone at the end of it, and nothing carries over from one request to the next by itself. What an application calls memory is storage outside the request — a database, a file, a running summary of earlier turns — together with a rule deciding what to place back into the window next time. The window is the limit; the memory is the machinery built around it.
Related entries
Order an assessment for information retrieval tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.