Quick answer: A context window is the maximum amount of text, measured in tokens, that a language model can consider in a single request. It holds everything: your system prompt, the conversation history, any documents you paste in, and the response the model is still writing. When you run past it, the model either errors or silently drops the oldest content. Most current frontier models sit around 200K to 1M tokens.
I think of the context window as the model's working memory. It is not a database and it is not disk. It is the desk space the model has to spread out everything it needs for one answer, and the moment the answer is done, the desk is cleared.
Tokens, Not Words
Models do not read characters or words. They read tokens, which are chunks of text produced by a tokenizer. A rough English rule of thumb is about 4 characters per token, or roughly 0.75 words per token, but code, JSON, and non-English text tokenize very differently. A dense HTML page can blow past your estimate because every angle bracket and attribute name costs tokens.
This matters because your context window is denominated in tokens, not pages. A "200K context window" is not 200,000 words. Estimating with a word count will leave you surprised when a request gets rejected.
If you want an accurate number, count tokens with the model's own tokenizer rather than guessing. General-purpose approximators built for one model family will misjudge another family by a wide margin.
What Actually Fills the Window
Every request is assembled from parts, and all of them share the same budget. Here is a typical breakdown for an agent answering a question about a web page.
| Component | What it is | Typical size |
|---|---|---|
| System prompt | Instructions, persona, rules, tool definitions | 500 to 5,000 tokens |
| Conversation history | Prior user and assistant turns | Grows every turn |
| Retrieved documents | Web pages, search results, RAG chunks | Often the largest slice |
| Current user message | The actual question | Small |
| Output | The response being generated | Counts against the same budget |
The part that surprises people is the last row. Output tokens come out of the same window as input tokens. If you fill 195K of a 200K window with input, you have left the model almost no room to answer.
The other trap is the retrieved-documents row. Feeding a full web page to a model is easy to do and easy to overdo. One long article can be 15K to 40K tokens of markup, boilerplate, navigation, and cookie banners, most of which the model does not need. This is exactly where clean extraction pays off, which I get into below.
What Happens When You Exceed It
There are two failure modes, and you want to know which one your stack has.
Hard error. The API rejects the request with a message telling you the input exceeds the model's limit. This is the honest failure. You see it, you fix it.
Silent truncation. Some frameworks quietly trim the oldest messages to make the request fit. The call succeeds, but the model has forgotten the beginning of the conversation. This is the dangerous one, because the output looks fine and is quietly wrong. The model answers confidently based on a history that got clipped without anyone noticing.
There is also a subtler problem that happens well before you hit the ceiling: the "lost in the middle" effect. Models attend most reliably to the start and end of a long context, and information buried in the middle of a huge prompt gets less weight. A bigger window does not automatically mean the model uses everything in it equally. Filling a 1M window to the brim is rarely the smart move even when it fits.
Strategies for Staying Under the Limit
You have four practical levers, and good systems use several at once.
1. Summarize the history. When a conversation grows long, replace old turns with a compact summary. You keep the thread of the discussion without carrying every word. Many agent frameworks and some APIs now do this automatically as you approach the limit.
2. Retrieve, do not dump. Instead of pasting an entire corpus, use retrieval-augmented generation (RAG) to pull only the passages relevant to the current question. This is the difference between handing the model a library and handing it the three paragraphs it needs.
3. Chunk large inputs. If you must process a huge document, split it into pieces that each fit comfortably, process them separately, then combine the results. Map-reduce over chunks beats stuffing everything into one call.
4. Clean the input before it lands. The cheapest tokens are the ones you never send. A web page rendered to clean markdown is a fraction of the raw HTML, with the same meaning.
The Context Window and Feeding Web Pages to an LLM
This last point is where the context window shapes a lot of real agent design. If your agent reads the web, the single biggest source of wasted budget is raw HTML.
Compare fetching a page two ways. A raw fetch returns the full document: scripts, inline styles, tracking pixels, nav bars, footers, and the article. A fetch that returns clean markdown returns the article. The token difference is often 5x to 10x.
Here is a fetch that returns clean, model-ready markdown from any URL:
curl https://link.sc/v1/fetch \
-H "Authorization: Bearer lsc_..." \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/long-article",
"format": "markdown"
}'
The response is the readable content without the markup overhead, which means more of your context window goes to actual information and less to boilerplate. When you are grounding an answer in several sources at once, that ratio decides whether they all fit.
The point is not that a bigger window fixes everything. It is that a clean input lets a modest window do the work of a huge one. For a deeper look at trimming what you send, see token optimization for feeding web data to LLMs. And if you are wiring live web access into an agent, link.sc handles the fetch-to-markdown step so you are not shipping cookie banners to your model.
The Short Version
A context window is a token budget, shared across your prompt, history, retrieved data, and output. Measure it in tokens, not words. Know whether your stack errors or truncates when you exceed it. And treat clean input as the first optimization, not the last, because the tokens you never send are free. You can read more about how link.sc turns arbitrary URLs into compact markdown built for this exact constraint.
Building an agent that reads the web without blowing its context budget? link.sc returns clean markdown from any URL so your tokens go to content, not markup. Start free.