When does your AI coding agent's context run out?

You're three hours into a long implementation task. The agent is still returning code — completions come back, diffs look plausible. But something has shifted. Variable names get inconsistent. The agent hedges in ways it didn't earlier. It suggests an approach you already discussed and ruled out. You haven't changed the task. The model hasn't changed. What changed is the context.

This is the context window filling. Not hitting a hard ceiling — that would be obvious. Just degrading quietly, because the information the agent needs to stay coherent is getting crowded out by everything it's accumulated since the task started.

What the context window actually contains

Every Claude Code agent session has a finite context window — a fixed token budget that holds everything the agent can "see." At the start of a task, it's almost empty: your brief, maybe some project conventions, and a prompt. As the session runs, the window fills with the conversation: every file the agent read, every tool result, every diff it generated, every reply it gave. It doesn't erase old content to make room for new. It accumulates.

By the time you're deep in a task, that window holds:

• The original brief and all follow-up instructions
• Every file the agent opened to understand the codebase
• Every shell command result, every lint output, every test failure message
• Every generation the agent produced, including the ones it revised

Long tasks, large codebases, and agents that explore before they implement fill the window faster. A task that reads twenty files to understand a module before writing a line of code has burned a significant fraction of the window before it starts.

The degradation signal

There's no error. The agent doesn't stop. What happens instead is softer: the information in the early part of the session — the original brief, the decision to use one approach over another, the architecture note you dropped in at the start — gets pushed further back, and the model weights recent context more heavily than distant context. Coherence drifts. Decisions made at the beginning of the session stop binding decisions made at the end.

Three signals predict context saturation before you hit it hard:

1. The agent re-asks questions it already answered. It proposes an approach you settled and moved on from. It re-reads a file it already read earlier in the session.
2. Naming and convention drift. The code it produces late in the session uses slightly different patterns than the code it produced early — because the early conventions are no longer sharp in the window.
3. Excessive hedging. The agent adds more qualifications to its outputs, asks for confirmation on things that were clear before. This is the model's way of signaling that its confidence in the full picture is lower.

If you see all three, you're well into the window. Compaction at that point is corrective, not preventive.

What compaction does — and what it loses

Claude Code's /compact command summarizes the current conversation into a condensed context and starts fresh from that summary. The agent keeps an understanding of what has been decided and built; it loses the exact trace of how it got there — the intermediate reasoning, the alternative paths, the specific file contents it read.

Timing matters. Compacting at a natural task boundary — after a working implementation, before the next subtask — preserves almost all the relevant context, because the summary captures the settled state. Compacting mid-task, mid-decision, or mid-edit is riskier: the summary may not capture an in-flight constraint that was only in the trace, not yet reflected in any file the agent can re-read.

The general rule: compact when the task has a natural seam, not when you notice the window is full. Waiting until you notice the window is full means you're already paying the quality cost.

The effective practice is to compact preventively — before quality degrades — rather than reactively after you've noticed the drift. That requires knowing where the window is before it causes a problem.

Parallel agents multiply the problem

A single agent with a visible session length is manageable. You can develop a feel for it: "this task is deep, probably time to compact." What changes when you're running three or four agents in parallel — each in its own git worktree, each on a separate task — is that you have three or four independent windows filling at different rates, and you can't watch all of them at once.

Agent A is early in its task and fresh. Agent B is six hours in and almost certainly due for a compact. Agent C just compacted an hour ago. From the outside, they all look the same: they're generating diffs, they're making progress. The one running on a degraded context isn't announcing it.

This is where the broader coherence problem with parallel agents meets the context problem directly: not only are the agents' decisions not shared across sessions, their session health isn't visible either. You're making architectural decisions across a fleet of agents with no signal about which ones have been slowly losing the thread.

A practical compact schedule

A few patterns that hold up well:

• Compact at task boundaries, not time boundaries. "It's been two hours" is a poor heuristic — a two-hour task that reads twenty files is not the same as a two-hour task that reads three. The seam between a complete subtask and the next is the right unit.
• Compact before adding major new scope. If the task is shifting — "now also add tests" or "now also handle the error cases" — compact first. Starting a new scope with a fresh summary is cleaner than starting it at the bottom of a dense window.
• For long-running tasks, compact before you're forced to. Waiting until the agent is clearly degrading means you're already paying the quality cost. An earlier compact costs a few tokens of summary overhead; a late compact can't recover the drift that already happened.

Per-session visibility

The reason the preventive compact is hard in practice is that it requires knowing where the window is — and without tooling, that's a judgment call based on how long the session has felt. This is the problem defract addressed in v1.1.0: every session now shows a per-session context-window gauge that surfaces how full the current session is, with a nudge to compact before quality degrades. The nudge fires before you notice the drift, not after.

For a fleet of parallel agents, each session gauge is visible in the same view — so you can see at a glance which agents are running lean and which ones are due. The context problem doesn't go away, but it stops being invisible. You can act on it at the right moment instead of guessing, or catching it late.