What is a context window? LLM context explained for coding agents

A context window is the amount of text a language model can hold in view at once, measured in tokens, roughly pieces of a word rather than whole words. Everything needed for a single turn has to fit inside it: instructions, any files or documents handed over, the conversation so far, and the model's own reply, all drawn from the same pool.

For someone typing questions into a chat box, that pool is usually more than enough. A coding agent burns through it differently. Every file it opens, every command it runs, every test log it reads back gets added to the same running total as the conversation itself, so a context window that felt roomy in chat can fill up in an afternoon of real coding work. This page covers what actually counts against that limit, what happens when it fills, and how to think about picking a model or plan that fits how you work.

What actually counts against your context

Tokens are the practical unit here, not words. English text runs somewhere around four characters per token on average, so a 1,000-word page lands near 1,300-1,500 tokens depending on the model's tokenizer. A few things share that same budget on every turn:

• Your system prompt and any project instructions, such as a CLAUDE.md file or custom tool definitions
• The conversation history so far, both your messages and the model's replies
• Any file contents the model has read into context
• Tool call results: command output, test failures, search results, diffs
• The reply the model is about to generate

That last point catches people off guard. Output tokens count against the same window as input tokens. A model asked to write a long file back out, or to reason at length before answering, can use up a meaningful chunk of its own context window just producing the response.

Why coding agents fill up faster than a chat conversation

A chat conversation grows a paragraph at a time. An agent session grows in chunks that are much larger and less predictable. Opening a single mid-size source file can add a few hundred to a few thousand tokens in one step. A failing test suite's full output, stack traces included, can add several thousand more. A repo-wide search, a directory listing, a diff review: each lands in context whole, not summarized, unless the tool doing the reading trims it first.

Multi-turn agent loops make this worse. Every read-plan-act cycle resends what came before plus whatever the latest tool call returned, so context grows with the length of the task, not just the length of the conversation. A session that opens a dozen files, runs the test suite three times, and iterates on a fix for an hour can accumulate far more context than a full afternoon of chat ever would. It's part of why subagents exist in tools like Claude Code: spinning up a subagent with its own isolated context window for a self-contained piece of work, then folding only a summary back into the main session, keeps the main thread from absorbing every intermediate detail.

How big is a context window, really

Context window sizes have grown a lot since 2023's few-thousand-token limits, and the headline numbers move fairly often. As of September 2026, per each provider's own documentation:

Treat those as a snapshot, not a fixed spec; they get revised with every model update. An advertised maximum also isn't the same as how well a model actually uses all of it. Chroma's research testing 18 frontier models found answer quality drops as input length grows well inside the stated limit, and that models are especially unreliable at using information placed in the middle of a long context rather than at the start or end, a pattern researchers call the lost-in-the-middle problem. A smaller local model with a shorter, well-used window can outperform a much larger advertised one stuffed past where it stays reliable.

What happens when the context window fills up

Once a session's context is close to full, one of two things tends to happen, depending on the tool. Some interfaces simply refuse the next request or truncate silently, dropping the oldest turns until the new prompt fits, which can quietly cut off instructions or file contents that mattered without telling you. Better-behaved coding tools compact instead: they generate a summary of the older parts of the session, capturing key decisions and file paths, and replace the raw history with that condensed version while keeping recent turns intact. Claude Code's docs describe clearing older tool output first, then summarizing the conversation only if that isn't enough; OpenAI's Codex CLI runs a comparable compaction step once a session crosses a configured share of its context window.

Compaction keeps a session running, but it isn't free. A summary is a lossy compression of everything before it, so detail that mattered, an exact variable name, a decision made three turns back, a subtlety in a bug report, can get smoothed over or dropped. Run enough compaction cycles in one long session and an agent's grip on early context gets progressively fuzzier, sometimes described as context rot setting in before the window is technically full.

• The agent re-reads a file it already opened earlier in the same session
• It contradicts or forgets an instruction given several turns back
• Responses get noticeably slower right after a long tool output
• It starts summarizing its own progress unprompted mid-task

Picking a plan or model with enough context for your workflow

The advertised maximum is the wrong number to shop by. A more useful question is what your actual sessions look like: how large are the files you regularly hand over, how long do agent sessions typically run before you'd rather start fresh, how much of a repository does a typical task touch. A workflow built around short, focused sessions on one file at a time rarely needs anywhere near a million-token window. A long-running agent working across a large monorepo, reading test output repeatedly, benefits far more from headroom, and from a tool that compacts well rather than one that just has a bigger number on the spec sheet.

• Measure a real session before assuming more context is needed; most agent tools show current token usage somewhere in the interface or logs
• A model's context window and what a given plan lets you actually use aren't always the same figure; some providers cap the effective window by tier even when the underlying model supports more
• If a task is self-contained, isolating it in a subagent or a fresh session often beats trying to keep everything in one long-running context
• Compaction quality varies by tool more than raw window size does; a well-summarized 200K session can outperform a poorly managed million-token one

If you're comparing hosted inference APIs rather than a chat subscription, context size is one more spec worth checking alongside pricing. NeverMetered's Qwen3.8-27B has a native context window of 262,144 tokens (256K), and how much of that a given account can use depends on the plan; see current plans for the per-tier context caps.