Context Windows and Token Limits: Why a Bigger Window Does Not Fix It

Claude Opus 5, Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 5, Sonnet 4.6, Fable 5 and Mythos 5 all have a 1M-token context window, with a maximum output of 128K tokens. Other Claude models, including Sonnet 4.5, have 200K (Anthropic documentation, fetched 3 August 2026). | Model | Context window | Max output | |---|---|---| | Claude Opus 5, Opus 4.8, Opus 4.7, Opus 4.6 | 1M tokens | 128K tokens | | Claude Sonnet 5, Sonnet 4.6 | 1M tokens | 128K tokens | | Claude Fable 5, Mythos 5 | 1M tokens | 128K tokens | | Claude Sonnet 4.5 and earlier | 200K tokens | Not stated on the page checked | The commercial change matters more than the number. Quoted from the same documentation: "For every model with a 1M-token context window, 1M is the default: you don't need a beta header, and long-context requests are billed at standard pricing." The pricing page adds that a 900k-token request is billed at the same per-token rate as a 9k-token request. On Sonnet 4.5 and Sonnet 4 the 1M window was a beta carrying a long-context premium of 2x input and 1.5x output above 200K input tokens. That cliff is gone on current models. One deliberate omission. This guide does not publish OpenAI or Google context window sizes. Both vendors' pricing pages were checked on 3 August 2026 and neither lists window sizes, and the secondary sources contradict each other badly, with the same model described as 400K, 1M and 2M by three different write-ups. Check the vendor's own model reference page, not a blog.

Lost in the Middle showed that retrieval accuracy follows a U-shaped curve. Models find information best when it sits at the very start or very end of the input, and worst when it sits in the middle, with the content held constant and only the position moved. The paper is Liu, Lin, Hewitt, Paranjape, Bevilacqua, Petroni and Liang, "Lost in the Middle: How Language Models Use Long Contexts", arXiv:2307.03172, published in Transactions of the Association for Computational Linguistics, volume 12, pages 157 to 173 (2023). The method used two controlled tasks, multi-document question answering and key-value retrieval, and moved the location of the answer inside the input. Quoted from the paper: "We show that language model performance degrades significantly when changing the position of relevant information... In particular, performance is often lowest when models must use information in the middle of long input contexts." The paper also offers a mechanism worth knowing, because it explains why the top of a prompt behaves differently from the middle. The models tested were instruction fine-tuned, and "the task specification and/or instruction is commonly placed at the beginning of the input context in supervised instruction fine-tuning data, which might lead instruction fine-tuned language models to place more weight on the start of the input context." One honest caveat: this is a 2023 paper testing 2023 models. It established the effect. It does not describe how today's frontier models behave, which is why the next section matters.

Context degradation still happens on current models. Chroma tested 18 models across four families in 2025 and found every one degraded as input length grew, with task complexity deliberately held constant. Getting longer, not harder, was enough to hurt performance. The report is Hong, Troynikov and Huber, "Context Rot: How Increasing Input Tokens Impacts LLM Performance", Chroma Technical Report, 14 July 2025, with an open replication codebase. The 18 models spanned Anthropic, OpenAI, Google and Alibaba families, from Claude Opus 4 and o3 through to Gemini 2.5 Pro and three Qwen3 models. Quoted from the report: "Large Language Models (LLMs) are typically presumed to process context uniformly, that is, the model should handle the 10,000th token just as reliably as the 100th. However, in practice, this assumption does not hold. We observe that model performance varies significantly as input length changes, even on simple tasks." Four findings are directly useful when you are debugging your own prompt: 1. The easy benchmark hides the problem. The standard needle-in-a-haystack test relies on word overlap between the question and the answer. When Chroma rewrote the needle so it required semantic understanding instead, performance fell sharply with length while the word-matching version held up. 2. Distractors compound. One distractor pushed performance below the clean baseline, four pushed it lower again, and the damage was uneven across distractors. Claude models had the lowest hallucination rates of those tested, GPT models the highest. 3. Packaging beats presence. On LongMemEval, focused prompts of roughly 300 tokens scored consistently high while full prompts of roughly 113K tokens degraded markedly across every model family. Same information, different packaging, materially different result. 4. Long outputs decay too. On a repeated-words replication task, models under-generated or invented words that were never in the input. GPT-4.1 refused the task 2.55% of the time and Claude Opus 4 refused 2.89%. Disclosure worth making: Chroma sells retrieval infrastructure, so "retrieval beats stuffing" is a commercially convenient conclusion for them. The codebase is open and the result matches what practitioners report, but the interest is real.

Filling a big window is not free even when the per-token rate is flat. Every turn resends the whole conversation as input, so a 20-turn session does not pay for 20 messages. It pays for the running total of everything said so far, 20 times over. That accumulation is why a long debugging session produces a bill nobody expects. Output makes it worse: on every current Claude model, output costs exactly 5x input. Prices below are per million tokens (MTok) from Anthropic's pricing page on 3 August 2026, quoted in USD and converted at an indicative AUD 1.55 to USD 1.00. Check the rate on the day before you budget anything. | Model | Input USD/MTok | Input AUD approx | Output USD/MTok | Output AUD approx | |---|---|---|---|---| | Claude Fable 5 | $10.00 | $15.50 | $50.00 | $77.50 | | Claude Opus 5 | $5.00 | $7.75 | $25.00 | $38.75 | | Claude Sonnet 5 (intro, to 31 August 2026) | $2.00 | $3.10 | $10.00 | $15.50 | | Claude Haiku 4.5 | $1.00 | $1.55 | $5.00 | $7.75 | | OpenAI gpt-5.6-sol | $5.00 | $7.75 | $30.00 | $46.50 | | Google Gemini 3.6 Flash | $1.50 | $2.35 | $7.50 | $11.60 | Four cost levers are worth knowing. The Batch API is a flat 50% discount on input and output. Prompt caching charges 1.25x base input for a 5-minute cache write, 2x for a 1-hour write, and 0.1x for a cache read, so caching pays for itself after one read on the 5-minute duration or two reads on the 1-hour duration (Anthropic pricing docs, 3 August 2026). Claude 4.7 and later use a newer tokenizer that produces roughly 30% more tokens for the same text, so a straight per-token comparison against an older model understates the newer one. And tool definitions cost tokens before you do anything: the tool-use system prompt alone is 286 to 406 tokens on Opus 5 and 675 to 804 on Opus 4.7, plus your own schemas. One detail people consistently miss, quoted from Anthropic's documentation: "Cached prompt prefixes still occupy the context window: prompt caching changes what you pay for those tokens, not whether they count." Caching is a cost lever, not a context lever.

Browser automation floods your context because every intermediate result passes through the model. A browser automation tool returns the full accessibility tree of a page into your context whether you needed three elements or three hundred, and a large file read does the same thing with a file. Anthropic publishes the size of the effect. In "Code execution with MCP", a Google Drive to Salesforce workflow was rebuilt so the agent wrote code against the tools instead of calling them directly: "This reduces the token usage from 150,000 tokens to 2,000 tokens, a time and cost saving of 98.7%." The same post notes that a two-hour meeting transcript consumed an extra 50,000 tokens simply being moved between two tool calls, and that when agents are wired to thousands of tools "they'll need to process hundreds of thousands of tokens before reading a request." Browser automation is the canonical offender, and Microsoft now says so in its own Playwright MCP server documentation. It points coding agents towards CLI-based workflows exposed as skills rather than MCP servers, because "CLI invocations are more token-efficient: they avoid loading large tool schemas and verbose accessibility trees into the model context." Two figures circulate that are worth reporting with their confidence attached. Roughly 114,000 tokens for a browser task via Playwright MCP against roughly 27,000 via the Playwright CLI, about 4x, is attributed to the Playwright team's own benchmarks and reported by TestCollab, but the primary benchmark could not be located. Around 17,000 tokens consumed by Chrome DevTools MCP for tool definitions alone is a single practitioner measurement. Treat both as directional. What practitioners actually do about it recurs across every source: write tool output to disk and read back only what is needed, return element references rather than whole trees, load tool definitions on demand instead of upfront, prefer a CLI plus a skill file over an MCP server for high-volume tools, and clear stale tool results from context on the next call. One independent practitioner blog sums the principle up: "every tool you give an AI agent is a tax on its context window." That is a personal blog rather than an institutional source, but it matches what the vendor documentation now says.

Curate what goes in rather than filling the space you have been given. Anthropic's guidance for building agents sets the goal as finding "the smallest set of high-signal tokens" that make your desired outcome most likely (Anthropic, Effective context engineering for AI agents, 2025). Five techniques do most of the work, and four of them are named in that guidance. 1. Compaction. Summarise a conversation that is nearing the window limit and restart a fresh window from the summary. Anthropic describes it as "the first lever in context engineering to drive better long-term coherence" and ships it as server-side compaction, in beta for Claude 4.6 and later. Compaction is lossy by design, so anything mentioned once forty turns ago is a prime candidate for deletion. 2. Just-in-time retrieval instead of stuffing. Rather than pre-loading every document, keep lightweight identifiers such as file paths, stored queries and links, and load the content at the moment it is needed. Anthropic's analogy is human: we do not memorise whole libraries, we keep file systems, inboxes and bookmarks. 3. Structured note-taking. Have the agent write durable notes to a file outside the window and read them back later. This is also the reason a constraints file such as CLAUDE.md or AGENTS.md outperforms telling the agent the same rule in chat. 4. Sub-agent isolation. Give a specialised sub-agent a clean window, let it burn tens of thousands of tokens internally, and have it return a condensed summary. Anthropic's stated target is 1,000 to 2,000 tokens returned per sub-agent. 5. Retrieval instead of pasting. If you are pasting the same 40-page document into every session, you want an index and a search step, not a bigger window. A sizing habit helps too. Anthropic publishes rough token costs for reading things: an average web page of about 10 kB is roughly 2,500 tokens, a large documentation page of about 100 kB is roughly 25,000 tokens, and a research paper PDF of about 500 kB is roughly 125,000 tokens. Three research PDFs is a third of a million-token window gone before you have asked a question.

buildAcademy is a small live Melbourne cohort for people who can build with AI tools but have not shipped to real users, and context control is taught as a working habit rather than a theory. Every technique above sounds obvious written down and disappears the moment you are deep in a session with a broken feature and a full window. Practising on your own project, with someone who has run out of context on a production job before, is what makes it stick. You will set up a constraints file, cut a bloated tool surface down, and rebuild a session that fell apart into one that finishes. See the curriculum and upcoming cohort dates at 13labs.au/buildacademy.

Will a 1M-token context window fix my problem? Usually not. Accuracy and recall degrade as input grows, an effect Anthropic names context rot in its own documentation and Chroma measured across 18 models in 2025. A larger window raises the ceiling on what you can send, not on what the model can reliably use. Why does my AI session get more expensive the longer it runs? Because every turn resends the entire conversation as input. A 20-turn session pays for the running total of all prior turns, not for 20 messages. Output compounds it further, costing 5x input on every current Claude model (Anthropic pricing, 3 August 2026). Does prompt caching give me more context? No. Quoting Anthropic's documentation: "Cached prompt prefixes still occupy the context window: prompt caching changes what you pay for those tokens, not whether they count." A cache read costs 0.1x base input, so it pays off after one read on the 5-minute cache. Why does Playwright MCP eat my context window? Because it loads large tool schemas and returns verbose accessibility trees into the model's context. Microsoft's own Playwright MCP documentation now points coding agents at CLI-based workflows for exactly this reason. Anthropic measured a comparable workflow dropping from 150,000 tokens to 2,000 by running code against tools instead of calling them directly. Where should I put my most important instructions in a long prompt? Near the start and again near the end. Retrieval accuracy follows a U-shaped curve, worst in the middle (Liu et al., TACL 2023), and Google Research measured a 22.3 point improvement in instruction-following when scattered instructions were also repeated at the end of the context (MMMT-IF, 2024).