Context Window by Model: Compare Capacity and Useful Context

Context window size is one of the most cited specs when comparing AI models, but the published number is a ceiling, not a guide to how well the model uses every token inside it. A model with a 200,000-token window that reliably recalls content from all positions is more useful for long-document work than one with a million tokens whose attention fades in the middle. For work that persists across sessions, people or model changes, fenbs keeps the lasting project context — tasks, decisions, rules and current status — outside any individual model's window.

This guide walks through the main model families, explains what the numbers mean in practice and shows how to choose a model for the actual inputs you work with.

What a context window measures

A context window is the total number of tokens a model can process in a single API call or conversation turn. Tokens are subword units: roughly 750 English words equal 1,000 tokens, though the ratio varies by language and content type. Code, structured data and non-English text tend to use more tokens per visible character than plain English prose.

The window covers both what you send and what the model generates. A model described as having a 128,000-token context may allow 127,000 input tokens with a 4,000-token output limit, or a different split depending on the implementation. Always check both input and output limits separately in the vendor documentation. The AI context window guide explains these concepts in more detail.

Context window sizes by model family

The table below shows published context window sizes for the main model families as of October 2026. These change with each new model version. Treat the table as a starting reference; verify current figures on each provider's documentation page before making a decision that depends on them.

A pattern worth noting: the largest context windows belong to models where retrieval quality across all positions has not always matched the headline number. Larger windows give you more room; they do not guarantee uniform recall. Test your specific workload rather than assuming a bigger number is always better.

How effective capacity differs from published capacity

Research on how models handle long contexts consistently shows stronger recall for content at the beginning and end of the context window than for content in the middle. This matters when you are relying on a model to extract specific facts from a long document: content buried in the middle of a large input may receive less attention than content near the top.

Effective capacity is the window size at which a model reliably answers questions about content from any position in its input. For some tasks and models, this is lower than the published window. For others, particularly those with retrieval-augmented architectures or strong attention mechanisms, it is close to the full window. The only reliable way to know for your use case is to test it. For more on how context quality degrades over long sessions, see the AI context rot guide.

Practical input and output limits for common tasks

For code review and coding assistance, the relevant question is how much of a codebase fits in the window at once. A 128,000-token window can hold roughly 100,000 words of code — a large amount for most tasks. In practice, sending only the relevant files and functions produces better results than sending the entire repository and hoping the model finds the right section.

For document analysis, context size matters more. A 50-page document is roughly 20,000-25,000 tokens. A 200,000-token window easily handles that, with room for your questions and the model's response. The limiting factor then becomes whether the model reliably extracts specific details from different sections. Testing with a representative document and known answers is the best evaluation.

Output limits matter for long-form writing and structured generation. A model that can ingest 200,000 tokens may limit its generated response to 4,000-8,000 tokens. For generating long documents, a higher output cap is more important than a larger input window. Check the vendor docs for both numbers. MCP connections like those at /integrations allow assistants to read and write structured content in fenbs, keeping long-running work outside any single response.

Choosing a model based on context window

Start with your typical input size. Measure the token count of the material you usually send in a session — your documents, code, chat history and instructions. Then look for models whose effective capacity covers that with headroom. A model whose window is only slightly larger than your input leaves no room for the response.

If your work requires processing inputs close to a model's limit, consider whether you can restructure: split the task, process the document in chunks, or extract the relevant sections rather than sending everything. Many tasks that seem to need a large context window are better served by careful context selection. The MCP vs RAG comparison covers structured retrieval as an alternative to large contexts.

If you switch models frequently — for cost, speed or availability — keep in mind that your context resets with each switch. Whatever you built up in a session with one model does not carry over to the next. That is a separate problem from context window size, and it calls for a separate solution.

How to do this with fenbs

1. Create a free account and add a project. Record its goal, current tasks and any decisions or rules that every assistant working on it should know.
2. Connect your AI apps from Integrations. Supported apps read the fenbs project context at the start of each session over MCP.
3. For each task, load only the source material directly relevant to that work into the model's context window. Let fenbs hold the persistent record — decisions, task status, lessons — rather than re-sending it every session.
4. At the end of the session, ask the assistant to save progress. The next session, with any connected model, starts from Where we left off rather than an empty context.
5. When you need a different model for a different task, the same fenbs project applies. Switch models for the right job without rebuilding the project context each time.