Context window limits for coding agents

Context window limits for coding agents are the practical ceiling on how much text a model can work with in one session, and in real coding work that ceiling fills much faster than the conversation alone suggests. The window holds the system instructions, tool definitions, every file the agent reads, every command output it receives and every reply it writes. One verbose test run or a full read of a large module can take more room than an hour of chat. When space runs short, something gives: older turns are summarized or dropped, long tool outputs are clipped, and material buried in the middle of a long input is used less reliably. The symptoms look like carelessness rather than a limit. The agent re-reads a file it already read, edits an outdated copy of a function, or breaks a constraint you stated at the start. This article explains what takes the space, what goes first and how to work so the facts that matter stay in view.

What actually fills the window during coding work

Your messages are usually the smallest part. A typical coding session spends its window on four other things.

Fixed overhead: system instructions, project instruction files such as a CLAUDE.md or AGENTS.md, and the descriptions of every tool the agent can call. This is loaded before you type anything and stays for the whole session.

File reads: when an agent opens a 1,500-line module to change one function, the whole read lands in the window. Reading the same file twice after an edit costs the space twice.

Tool output: test runs, build logs, stack traces, search results and directory listings. A failing test suite with full tracebacks can be thousands of lines, most of it repetitive.

The agent's own work: its plans, explanations, diffs and the edits it writes back.

The practical consequence is that a session doing real work fills up from tool traffic, not from discussion. A session that 'only' fixed three bugs may have read twenty files and run the test suite eight times. That is why long sessions degrade even when you have said very little, and why durable project memory has to live outside the window rather than inside it.

What gets dropped first

Tools handle a full window differently, and vendors change their methods, so the safe assumption is general rather than specific. Three things tend to happen.

Old turns get compressed. When a session approaches the limit, earlier conversation is summarized or removed to make room. The early turns are usually where you set the ground rules, so they are exactly what you lose. What survives a summary and what does not is covered in what gets lost when an agent summarizes a long session.

Large outputs get clipped. Many tools cap how much of a command's output reaches the model. If the important line in a log is near the end of a long run, the agent may never see it and will reason from the part it did see.

Attention thins out. Even inside the limit, models tend to use material at the start and end of a long input more dependably than material in the middle. A constraint stated once, forty messages ago, between two large file reads, is in the window but easy to overlook.

None of this is announced clearly in the conversation. You usually find out from the mistakes.

How a full window shows up as mistakes

Context pressure produces a recognizable set of errors. Learning them helps you diagnose the cause instead of rewriting your prompt.

Stale edits: the agent read a file early, you or another process changed it, and the agent writes a patch against the version it remembers. The patch fails to apply or silently reverts a newer change.

Repeated work: the agent re-reads files, re-runs the same failing command or proposes a fix it already tried an hour ago, because the record of the first attempt was compressed away.

Forgotten constraints: 'do not change the public API' or 'keep the CSV format stable' disappears, and the agent makes the change you ruled out. This is the most expensive failure because the output looks reasonable.

Invented details: when the exact signature, config key or error text is gone, the agent fills the gap with something plausible. Function names that almost exist are a common sign.

Overconfident summaries: asked what it has done, the agent reports from its compressed notes, which can be tidier than the real history.

If these appear late in a long session and not early, suspect the window before you suspect the model.

Working inside the limit

You cannot make the window bigger, but you can spend it better.

Scope one task per session. A session that implements one well-described change and stops is less likely to hit the limit than one that wanders across the codebase. Tasks an agent can finish are also tasks that fit.

Read narrowly. Ask for the function or line range rather than the whole file, and search before reading.

Tame tool output. Run the single failing test instead of the suite, and ask for a short summary of long logs rather than the raw dump.

Put durable facts in files, not turns. Decisions, constraints and exact values belong in a record the agent reads at the start of each task, where they sit at the top of the window instead of in the middle.

Start fresh deliberately. When a session starts repeating itself, write down where you are and begin a new one. A clean session with a good handoff usually beats a long one with a degraded memory; see how to hand off an AI coding session.

Give each task a deliberate slice of the project. Bounded task context explains how to choose that slice and say what was left out.

QUESTIONS

Why does my coding agent get worse as a session goes on?

Usually because the window is filling with file reads, command output and earlier turns. Older material gets summarized or dropped and the middle of a long input is used less reliably, so constraints and exact details fade. Starting a fresh session with a short written handoff often fixes it faster than a longer prompt.

Is a bigger context window always better for coding?

It helps with large files and long logs, but it does not remove the problem. A bigger window fills with the same tool traffic, attention to the middle still thins, and the session still ends. Keeping tasks small and facts in files matters regardless of the model's limit.

Should I start a new agent session for each task?

For most work, yes. One task per session keeps the window focused and makes each session's results easier to review. Carry continuity in a written record, such as a task note or decision file, rather than in an ever-growing conversation. Long sessions make sense mainly for tightly connected exploratory work.

RELATED GUIDES

• What is a project management harness?
• How to create a project card in BRAIN FLUID Desk

RELATED HARNESS PAGES

• What gets lost when an agent summarizes a long session What gets lost when an agent summarizes a long session: which details survive, which vanish, and how to protect constraints and exact values.
• Bounded task context Bounded task context: give an agent the slice of a project one task needs, chosen by relationship, capped in size, with omissions stated.
• AI agent project memory AI agent project memory explained: why durable project records beat chat history, and how BRAIN FLUID keeps context with the work.
• Why did my AI agent forget what we decided yesterday? Agent sessions don't carry memory, and decisions left in chat vanish. Find where the decision lives, write a record, and read it at session start.