AI Model Context Window Reference Chart

A quick-reference chart of context window and max output limits across current major models — save this if you want the shape of current limits without digging through provider docs each time. Context windows change with nearly every model release, so always confirm the exact current number on the provider’s own documentation before designing a system around a specific limit.

Context window and output limits (July 2026)

Claude figures are sourced directly from Anthropic’s official model documentation as of July 2026. GPT and Gemini figures are ranges reflecting publicly reported specs across multiple independent trackers, since third-party sources disagree more on these — always confirm the exact current number on the provider’s own docs before designing around a specific limit.

What context window actually means

The context window is the total amount of text (measured in tokens, not words) a model can consider in a single request — this includes your prompt, any documents or code you send, the conversation history, and the model’s own response, all counted against the same limit. As a rough guideline, one token is about three-quarters of a word, so a 200K token window holds roughly 150,000 words — about the length of two full novels. Max output is a separate, usually smaller number: the longest single response the model can generate, even within a much larger context window.

Advertised vs. effective context window

A model’s advertised context window and its effective, reliable context window are not the same thing. Independent research on long-context performance has repeatedly found that accuracy degrades — sometimes sharply rather than gradually — as content moves toward the middle of a very long context, a pattern often called “lost in the middle.” A model claiming a 1M-token window may perform noticeably less reliably on information placed at, say, token 600,000 than on information placed near the start or end of the same request. The practical implication: don’t assume a model reliably uses 100% of its advertised window for retrieval-critical tasks — test with your own representative long documents before depending on it.

Which window size do you actually need

Context window vs. chunking: the real tradeoff

A larger context window lets you skip building a retrieval/chunking pipeline — feed the whole document in and let the model handle it directly. But bigger isn’t automatically better or cheaper: processing more tokens costs more per request regardless of whether the model uses all of them well, and the lost-in-the-middle effect means a well-designed retrieval system can sometimes outperform a brute-force full-context approach on accuracy, not just cost. The practical guideline: use the largest window that’s actually necessary for your task, not the largest one available, and benchmark retrieval-based chunking against full-context stuffing on your own documents before assuming either approach is automatically superior.

Cost implications of a large context window

A bigger context window isn’t free capacity — every token you send counts against your bill whether or not the model needed all of it to answer your question. This matters more than it first appears: input tokens are typically priced separately from output tokens, and sending a full 200-page document on every request when only a few pages were actually relevant means paying for the whole document every single time, not just once. Two mitigations are worth knowing about: prompt caching, which can cut the cost of repeated, unchanged context by a large margin on cache hits, and retrieval-based chunking, which sends only the relevant portion of a document rather than the whole thing. Neither is automatically better — a stable, frequently-reused document (a system prompt, a fixed knowledge base) is a strong caching candidate, while a large, rarely-repeated one-off document is often cheaper to chunk and retrieve from than to cache in full.

Worked example: choosing a window for a contract-review tool

Say you’re building a tool that reviews legal contracts, most of which run 20-80 pages. Two design choices are on the table: stuff the entire contract into a single request using a large-context model, or chunk the document and retrieve only the clauses relevant to a specific question. For a tool that answers targeted questions (“what’s the termination clause say about notice period?”), retrieval-based chunking is often both cheaper and more reliable, since it sidesteps the lost-in-the-middle risk on a long document entirely — the model only ever sees the relevant excerpt. For a tool that needs to reason across the whole document at once (flagging inconsistencies between clauses in different sections), a large-context, full-document approach is the more appropriate design, since the task genuinely requires holding the whole document in view simultaneously. The context window size doesn’t dictate the architecture — the task does; window size just determines which architectures are even possible.

Common mistakes

• Assuming the largest window is always the safest choice. A bigger window costs more per request and doesn’t guarantee better retrieval accuracy across its full length — matching window size to actual need is usually the better default.
• Citing a context window figure from an old article. These numbers change with nearly every model release; a figure that was accurate six months ago may already be outdated.
• Conflating context window with max output. These are two separate limits — a model with a huge context window can still have a comparatively modest cap on how long a single response can be.
• Never testing retrieval accuracy at different positions within a long document. A model that performs well on information near the start or end of a long context can still perform meaningfully worse on information buried in the middle — this only shows up if you specifically test for it.

Context windows vary within a provider’s own lineup, not just across providers

It’s easy to assume “Claude’s context window” or “GPT’s context window” is a single number, but current lineups typically vary meaningfully by tier within the same provider. In Anthropic’s current lineup, for example, Haiku (the fastest, most economical tier) has a smaller context window than Sonnet, Opus, or Fable — a deliberate tradeoff, not an oversight, since the fastest tier is optimized for high-volume, typically shorter tasks where a smaller window is rarely a real constraint. The practical implication: don’t assume that switching from a flagship model to a budget model within the same provider preserves your context window — check the specific tier’s limit, not just the provider’s headline number, especially if your workload depends on a large window and you’re considering a cost-driven downgrade.

Multimodal content and context windows

Context windows aren’t exclusively about text. Models that accept image, audio, or video input consume context budget for that content too, typically converted into an equivalent token cost based on resolution, duration, or complexity. A single high-resolution image can consume a meaningful chunk of a context window on its own, and a long video or audio file can consume substantially more — if your application mixes text with images, documents, or media, budget context window capacity for the non-text content specifically rather than assuming your text-only estimate captures the full picture. This is easy to overlook when a context window figure is quoted as a single headline number without breaking out how multimodal content factors into that same budget.

Estimating your own token count without a tool

Before reaching for a dedicated counter, a rough manual estimate is often good enough to sanity-check whether your task fits comfortably within a given window. English prose tokenizes at roughly 1.3 tokens per word (so 100 words ≈ 130 tokens), while code and structured data (JSON, tables) tend to tokenize somewhat less efficiently due to punctuation, whitespace, and symbols, often running closer to 1.5-2 tokens per word-equivalent. A quick gut-check for a text document: take the word count, multiply by roughly 1.3, and compare against the model’s context window minus your expected output length — leaving headroom for the response itself, not just the input, since both count against the same window on most current models. For anything approaching a meaningful fraction of a context window, a real token-counting tool is worth the extra step, since these rough multipliers can be off by a noticeable margin on unusual content like heavily formatted text, non-English languages, or dense code.

How context windows have grown, and why it matters

Early widely-used models topped out around 4K-8K tokens — barely enough for a long email thread and a response. Growth since then has been dramatic: 32K and 128K became common mid-tier benchmarks, and current-generation flagship models routinely offer context windows in the hundreds of thousands to over a million tokens. This progression matters beyond the raw numbers because it’s changed what kinds of applications are practical to build without heavy engineering investment. Tasks that once required a custom-built retrieval pipeline just to fit within a small window — summarizing a long report, reasoning across a multi-file codebase — are now often possible with a single request on a large-context model. That said, the underlying lost-in-the-middle challenge discussed above means “bigger window” hasn’t fully eliminated the engineering tradeoffs it was expected to — it’s shifted where the hard problems sit, from “how do I fit this in the window” to “how do I make sure the model actually uses everything in the window reliably.”

Checklist before designing around a context window number

• Verify the exact current number on the provider’s own model documentation, not a third-party comparison chart — these figures change with nearly every model release.
• Test your own representative long documents for retrieval accuracy across the full window, not just at the start — don’t assume uniform reliability from a headline number.
• Check the max output limit separately from the context window — a large input window doesn’t guarantee a correspondingly large single response.
• Factor in cost: a bigger context window processed on every request costs more per call, even when the extra capacity isn’t needed for a specific request.
• Re-verify before scaling a production system — a limit that was accurate when you built a feature may have already changed by the time you scale it.

Frequently asked questions

Why do context window figures vary so much between sources?

Providers update their model lineups frequently, and different trackers capture snapshots at different times — some reflect the current generally-available model, others reflect a preview or beta tier, and older articles simply go stale. Always check the provider’s own current documentation rather than relying on a comparison chart’s exact number.

Does a 1M-token window mean I can reliably use all 1 million tokens?

Not necessarily — advertised capacity and effective, reliable capacity are different things, and research on long-context performance consistently shows degradation at long distances within a context. Test with your own representative inputs before depending on the full advertised range.

Is max output the same as context window?

No — context window is the total input plus output a model can consider in one request; max output is a separate, usually much smaller limit on how long a single response can be, even within a large context window.

Should I always pick the model with the largest context window?

No — match the window size to your actual task. Most production use cases (chat, single-document analysis, standard coding tasks) fit comfortably in a fraction of the largest available window, and paying for unused capacity on every request adds cost without adding value.

Is a bigger context window always better than a well-built retrieval pipeline?

Not necessarily. A well-designed retrieval system can outperform brute-force full-context stuffing on both cost and accuracy for tasks that only need a small, targeted portion of a large document — the “just use the biggest window” instinct isn’t automatically the right engineering choice.

How do I count tokens for my own documents before choosing a model?

Use a token counter tool rather than estimating from word count alone, since the token-to-word ratio varies somewhat by content type (code and text tokenize differently) and by provider. The rough guideline of 100 words ≈ 130 tokens is a reasonable starting estimate, but a real count is more reliable for a production decision.

Do context window limits differ between the chat interface and the API for the same model?

Sometimes — a chat app may default to a smaller effective window or a different model version than what’s available through the API, even under the same model family name. Check the specific access method you’re using, not just the model name, when confirming a limit.

Why do budget-tier models typically have smaller context windows than flagship models?

It’s a deliberate design tradeoff rather than a technical limitation providers haven’t solved — budget tiers are optimized for high-volume, typically shorter tasks (classification, quick responses) where a smaller window rarely constrains real usage, and keeping the window smaller helps keep the tier fast and cheap. If your specific use case needs both budget pricing and a large window, check each provider’s lineup carefully, since this pairing isn’t available on every tier.

Will context windows keep growing indefinitely?

The trend has been consistently upward for several years, but growth in advertised window size has outpaced growth in effective, reliable usage of that window — meaning the more relevant question for most practical purposes may increasingly be “how reliably does the model use its window” rather than “how large is the window,” a distinction worth watching as providers continue to push headline numbers higher.

Related reading

Understanding Tokens: A Complete Guide · Multi-Model Token Counter & Cost Estimator · AI Model Pricing Comparison Chart · How to Choose the Right AI Model for Your Task · AI Model Pricing in 2026 · AI Model Comparison Tool · Claude vs ChatGPT vs Gemini: Complete Comparison · Best AI Model for Your Budget Finder

How to use this chart in a real decision

Use the table above as a starting filter, not a final answer. First, estimate your actual token needs using the Token Counter — most tasks need far less than the largest window available. Second, if your task is retrieval-critical (finding a specific fact in a long document), test the model’s reliability at the specific position in the document where your critical information tends to sit, not just at the start. Third, re-verify the exact current numbers on the provider’s documentation before finalizing an architecture decision, since these figures shift with nearly every model release — a chart like this one is a starting point, not a substitute for checking the live source before a production decision.

A note on how this chart was built

Claude figures in the table above are sourced directly from Anthropic’s official model documentation as of July 2026. GPT and Gemini figures are ranges reflecting publicly reported specs across multiple independent trackers, cross-checked where possible — these figures showed more disagreement across sources than Claude’s did, which is itself worth noting rather than papering over with false precision. Where sources disagreed meaningfully, this chart reports a range rather than picking one source’s number as definitive. Recheck all figures against the provider’s own current documentation before a production decision, since this table will drift out of date as new models ship.