Context Windows Explained (Plain English)

TL;DR: A context window is the total number of tokens a model can hold in one exchange, prompt plus reply combined. In 2026, Gemini, Claude and GPT-5.6 have converged near 1 million tokens, and none publish a 2 million figure. The real question isn't size. It's how reliably a model uses everything you give it before recall slips.

What Is a Context Window, Actually?

A context window is the maximum amount of text, measured in tokens rather than words or characters, that a model can hold in view during a single exchange. Everything counts against it: the system instructions, your message, any files or chat history you've included, and the reply the model writes back. Once that ceiling is reached, something has to give, either the request is rejected outright, or the oldest content quietly falls out of view depending on how the surface you're using handles overflow.

The reason this limit exists at all comes down to how these models work internally: every token in the window has to be weighed against every other token to decide what matters, and that cost grows fast as the window grows. Vendors have spent the last two years making that math cheaper, which is exactly why the published ceilings have climbed from roughly 8,000–32,000 tokens in 2023 to somewhere near a million today. The mechanism didn't change; the amount of it you can afford to run did.

The number resets with every new conversation. It is not a running total across your account, and it is not the same thing as how much the model "remembers" about you over time (more on that distinction in the FAQ below). It is a per-request ceiling, published by the vendor, that applies to that one exchange and nothing else.

Are Tokens the Same as Words?

No, and this is the first place plain-English explanations go wrong. A token is the unit models actually process, and it doesn't map cleanly onto a word. OpenAI's own tokenizer documentation puts it this way: tokens commonly range in length from one character to one word, and in some languages a token can be shorter than a single character or longer than a whole word.

In practice, English text runs at roughly three-quarters of a word per token, so a 1,000-word document is closer to 1,300 to 1,400 tokens once whitespace, punctuation and word fragments are counted separately. Run that forward: a 300-page novel at roughly 300 words a page is around 90,000 words, which lands somewhere near 120,000 tokens, well inside every model listed below. A codebase, a set of scanned PDFs, or text in a language that tokenizes less efficiently than English will burn through the same window noticeably faster than a plain English word count would suggest. This is why "how many pages fit in the context window" never has one clean, universal answer.

Does the Window Hold Input and Output Together?

Mostly, yes, but the vendors publish this differently. For OpenAI and Anthropic, one context-window figure covers the entire exchange: what you send in and what the model writes back draw from the same shared ceiling, with a separate, smaller sub-limit on how much of that total the reply itself is allowed to be. Google instead lists input and output as two distinct numbers on its own model pages, rather than folding them into a single combined figure.

That distinction matters in practice. On the vendors where input and output share one pool, a model can still return a short, cut-off answer if a huge input has left little of the shared ceiling free for the reply. And on any vendor, if you're running a reasoning model, the visible answer isn't the only thing eating into that output allowance, which is the subject of the next section.

How Big Is Each Model's Window in 2026?

Checked against each vendor's own published model reference on September 3, 2026:

The headline is convergence, not a size race. Three vendors that used to differ by an order of magnitude now sit within roughly 5% of each other at the top end. Anthropic is the one exception worth flagging on its own list: Haiku 4.5, its fastest and cheapest model, stays at 200K while the rest of the current lineup runs to 1M, so "Claude has a 1M window" is true of three current models and false of a fourth. Our own comparison of ChatGPT and Claude reaches the same convergence conclusion from the other direction, comparing the two head to head rather than reading spec sheets in isolation.

Why Did My Request Burn Tokens and Return Nothing?

This is the single most confusing failure mode tied to context windows, and it isn't really a context-window problem. It's an output-cap problem that only shows up once you're running a reasoning model. OpenAI's own API specification defines its output-token fields as covering the entire response the model generates, the part you see and any reasoning tokens spent producing it, together. Anthropic's Messages API reference documents the same architecture: tokens spent thinking draw from the same ceiling as the visible reply, not a separate allowance.

The practical consequence: if a reasoning model spends its whole output budget working through the problem, it can hit the cap before writing a single visible word. You get charged for the tokens, and the response comes back empty or truncated, which reads exactly like a broken API even though it isn't one. Post 114 has the full per-vendor reference table for these output-cap fields if you want the exact parameter names.

{
  "usage": {
    "input_tokens": 37,
    "output_tokens": 11,
    "output_tokens_details": {
      "reasoning_tokens": 0
    },
    "total_tokens": 48
  }
}

That shape, a reasoning_tokens count nested inside the output-token accounting, is how OpenAI's own API structures usage reporting. When that number climbs and your visible answer doesn't, the cap was the problem, not the model.

What Happens if You Go Over the Limit Entirely?

Rather than silently truncating your prompt, both major vendors treat a genuine context-window overflow as its own distinct failure. Anthropic's API documents a dedicated stop reason for it, separate from a normal completion, from hitting a stop sequence, or from running out of output tokens specifically. OpenAI's Assistants API takes a similar approach one level down: an incomplete run reports which specific limit it hit, distinguishing a prompt that was too long from a completion that ran too long, using two different reason codes rather than one generic "too long" error.

The takeaway for anyone building on top of these APIs: check the specific reason code before assuming what went wrong. "The request failed" and "the model ran out of room to think" and "your input alone exceeded the window" are three different problems with three different fixes, and the better APIs already tell you which one you hit.

Does Filling the Whole Window Actually Help?

Not reliably, and no vendor puts a number on this in their published specs, because it's a quality issue rather than a documented limit. Recall of anything sitting in the middle of a very long input degrades well before you reach the stated ceiling. It shows up as a model confidently missing a detail that was clearly present in what you gave it, simply because that detail wasn't near the start or the end of a long document.

This site's own comparison of ChatGPT and Claude on long-document work reaches the same conclusion from actual side-by-side testing: at genuinely large context sizes, recall accuracy separates the models more than the size of the window does. A model with a smaller published ceiling that reads carefully will often outperform a larger one that skims. Post 489 and post 508 go deeper on exactly where each vendor's recall starts to slip, model by model, if you're deciding what actually belongs at 200K-plus tokens versus what should be trimmed first.

Quick Rules for Working Within the Window

• Put the most important instructions and facts near the start or the end of your prompt. The middle of a long input is where recall degrades first, on every vendor tested so far.
• Don't treat the published ceiling as a target. A context window that's 40% full and well-organized will usually outperform one that's 90% full and padded with irrelevant material.
• If you're on a reasoning model and getting empty or truncated replies, check the reasoning-token count in the usage response before assuming the prompt is the problem.
• Remember the window resets every conversation. If a product claims to "remember" something across sessions, it's re-feeding a summary into a fresh window, not extending the window itself.
• When comparing vendors on paper, check whether their published figure is a combined input-plus-output ceiling or two separate numbers; the models above aren't all measured the same way.

A Worked Example: Pasting In a Contract or a Codebase

Say you're pasting a 40-page contract, roughly 16,000 words, into a chat window along with a request to flag anything unusual. At three-quarters of a word per token, that's somewhere around 21,000 to 22,000 tokens for the document alone, plus your instructions, plus whatever system prompt the product adds behind the scenes. On any of the models listed above, that comfortably fits with room to spare. The window was never going to be the constraint here.

Now scale it up: ten contracts at once, or a mid-size codebase with its tests and documentation included, and you're plausibly in the 150,000 to 400,000-token range. Still under every ceiling in the table, but now squarely in the territory where recall quality, not raw capacity, decides whether the answer is actually reliable. This is the case the size number can't tell you anything about. A model that fits your input and a model that reads all of your input carefully are not the same claim, and only one of them is what the spec sheet measures.

None of this changes by picking the vendor with the biggest published number. Once every major model sits within striking distance of a million tokens, the window stops being the constraint and the model's own recall becomes the thing worth testing before you commit a real workflow to it.