Context window size — the amount of text a model can read and work with in a single interaction — has become one of the most practically significant differences between AI models for business use. A small context window limits what you can do: you cannot summarise a 100-page report if it does not fit in the context. A large context window enables new use cases: entire codebases, lengthy legal documents, full meeting transcripts, comprehensive research files can all be processed in a single interaction. Understanding which models offer which context sizes, and how context size affects both quality and cost, is essential for selecting the right model for context-heavy tasks.
Current Context Window Sizes by Model
Context windows have expanded dramatically since 2023. GPT-4o supports 128,000 tokens — roughly 96,000 words or about 400 pages of dense text. Claude 3.5 Sonnet and Claude 3.7 Sonnet both support 200,000 tokens — approximately 150,000 words or about 600 pages. Google’s Gemini 1.5 Pro supports 1,000,000 tokens (1 million) and Gemini 1.5 Flash offers a 1 million token window as well, enabling processing of truly enormous documents — multi-volume books, large codebases, or months of chat history. Gemini 2.0 models extend this further to 2 million tokens in some configurations.
For most business use cases, the practical question is not which model has the largest possible context window but which model reliably uses the context it has. Research has consistently shown that models attend to content at the beginning and end of long contexts more reliably than content in the middle — the “lost-in-the-middle” problem. A 200,000-token context window does not guarantee that the model will pay equal attention to a critical detail on page 300 of a 600-page document as it does to content on page 1 and page 600.
Context Window Sizes: Major Models (2026)
| Model | Context Window | ~Words | Best for |
|---|---|---|---|
| Gemini 1.5 Pro / 2.0 | 1–2M tokens | 750k–1.5M | Entire codebases, multi-volume docs |
| Claude 3.5/3.7 Sonnet | 200k tokens | ~150k | Long documents, large codebases |
| GPT-4o | 128k tokens | ~96k | Most business documents |
| GPT-4o Mini | 128k tokens | ~96k | High-volume document processing |
| Llama 3.3 70B | 128k tokens | ~96k | On-premise, privacy-sensitive |
The Cost of Long Contexts
Context window size and cost are directly linked. Every token in your context — whether system prompt, document content, conversation history, or retrieved knowledge — is a token you pay for at input token rates. A 200,000-token context call costs 20× more in input tokens than a 10,000-token call. For most business documents (10–50 pages), the cost difference between a short and long context is modest. For truly large context tasks — processing a multi-year Slack archive, a complete codebase, or a lengthy legal discovery set — the input token cost at large context sizes can become significant at scale.
Manage context costs the same way you manage any AI cost: use only the context that is actually needed for the task. A 200,000-token context window does not mean you should fill it. Well-structured retrieval (providing the relevant sections of a large document rather than the full document) consistently produces better results at lower cost than brute-force context stuffing.
When Large Context Actually Helps vs When RAG Is Better
The conventional wisdom that RAG is always preferable to large context is not universally true in 2026. For tasks that require understanding relationships across an entire document — contract analysis that needs to reconcile provisions from multiple sections, codebase analysis that needs to understand how components interact across many files, research synthesis that needs to identify patterns across a full body of work — providing the full document in context often produces better results than retrieving fragments, because the model has access to the full picture rather than selected pieces.
RAG is preferable when the relevant information is a small subset of a much larger corpus (most customer FAQ questions need only a few documentation sections, not the entire knowledge base), when the corpus changes frequently (retrieval handles updates automatically while context re-loading is expensive), or when the query type varies unpredictably (retrieval finds the relevant subset dynamically rather than requiring the full corpus every time). Use large context for tasks that need full-document understanding; use RAG for tasks that need specific retrieval from large corpora.
The practical question when evaluating context window requirements for a specific use case: what is the average document size you need to process, how frequently do you need to process it, and does the task require whole-document understanding or targeted retrieval? These three questions determine whether context window size or RAG architecture is the right solution — and which models are worth evaluating for your specific requirements.
Multimodal Context: Documents, Images, and Audio
Context windows are not just for text. All major frontier models now support mixed-modality context that includes images alongside text — and some support audio and video as well. An image in context consumes tokens proportional to its resolution: a 1024×1024 image typically costs 1,000–1,500 tokens depending on the model’s vision tokenisation. For workflows that process documents containing both text and images (invoices, slide decks, forms, scanned documents), the effective context budget is the text budget minus the image token cost. For image-heavy documents at large scale, this becomes a meaningful cost consideration alongside text token costs.
Gemini’s extremely large context window is particularly valuable for multimodal use cases: processing a lengthy video, a full presentation deck with many slides, or a document set that includes diagrams and charts alongside text. For use cases that require understanding across large multimodal documents, Gemini’s context size advantage over Claude and GPT-4o is practically significant rather than just a specification number.
Context Quality vs Context Quantity
The most important lesson from working with large context models is that context quality matters more than context quantity. A well-structured 10,000-token context with clearly organised, directly relevant information produces better answers than a poorly structured 100,000-token context where the relevant information is buried among less relevant material. The “lost in the middle” attention problem — where models attend less reliably to content far from the beginning and end of long contexts — means that information placement within a long context matters as much as inclusion.
Structure your long-context inputs deliberately: place the most important information (the question, the key constraints, the most critical context) at the beginning or end of the context rather than in the middle. Use clear section headings to help the model navigate. Remove content that is not directly relevant to the task rather than including everything available. A curated long context consistently outperforms an uncurated one at the same or lower cost.
Measure whether your context-heavy tasks actually benefit from the larger context before committing to a more expensive model for their full context window. Test the same task on a 32k-token context, a 100k-token context, and the full document context, and compare output quality. The result often reveals that a well-selected subset performs as well as or better than the full context — and at dramatically lower cost. That empirical result should drive your context strategy rather than the assumption that more context is always better.
Context Window Sizing for Common Tasks
The most important mental model shift for working effectively with large context windows: think of context as a budget rather than a free resource. Every token in context costs money and affects attention quality. A well-managed 20,000-token context with precisely chosen content consistently outperforms a carelessly assembled 100,000-token context with significant irrelevant material. The discipline of context curation — choosing what to include, what to summarise, and what to exclude — is the skill that makes large context windows genuinely useful rather than just expensive.
Dynamic Context Selection
Static context — sending the same background information with every request regardless of relevance — is the least efficient approach to context management. Dynamic context selection — choosing what to include in each request based on what is actually relevant to that specific query — produces better quality at lower cost. The simplest implementation: a function that takes the current query and returns a curated set of context elements relevant to it, rather than always including the full available context. For RAG applications, this is retrieval — the retrieval step performs dynamic context selection automatically. For applications without RAG, a simple relevance check before including any context element is often sufficient to significantly reduce unnecessary context and improve both quality and cost.