When more context makes your coding agent worse: subagent, /compact, /clear or a headless loop
Tools in this post
When a coding agent gets worse as a session grows, the most likely cause is tool output, not the model: in a 22 September 2026 study of agents on Terminal-Bench 2.0, tool results made up 56% of the context and tool calls another 28%. To tell, rerun the request in a fresh session with a five-line brief. If the fresh run succeeds, the context was the problem, and the fix is to route work out of the main session: verbose reading to a subagent, a new task to /clear, repeated work to a headless loop, and lasting rules to the repository. This applies to Claude Code 2.1.296, OpenAI Codex 0.162.1 and Cursor's agent as of 13 October 2026.
The symptom, and how to tell context from the model
The symptom is a coding agent session that did good work for an hour, then starts repeating a rejected fix, ignoring a rule from CLAUDE.md, editing the wrong file or asking for something it already read. Claude Code's best practices put it in one line: "When the context window is getting full, Claude may start 'forgetting' earlier instructions or making more mistakes."
To tell context from the model, give the same request to a fresh session with a short written brief. If it succeeds, the old context was the problem; if it fails the same way, suspect the model, the task or the prompt. claude --safe-mode narrows it further by starting without your CLAUDE.md, hooks, MCP servers, skills and plugins. Chroma ran the same test at scale: focused prompts of about 300 tokens beat full prompts of about 113,000 on every model.
Long contexts are the norm. For TraceLab (June 2026), University of Washington researchers traced about 4,300 Claude Code and Codex sessions from 43 developers: the median Claude step re-read 126,180 tokens to append 857 new ones, and only 4.5% of Claude sessions ever compacted. On Stackness, as of 13 October 2026, 8 real profiles list Claude Code, 7 list Cursor and 2 list Codex, after removing bot accounts (data sources), all among the AI coding tools developers list.
Why does more context make a coding agent worse?
More context makes a coding agent worse because models do not use a long context evenly. Chroma's Context Rot report (July 2025) held each task constant, varied only the input length across 18 models, and found that "model performance consistently degrades with increasing input length", even on tasks as simple as repeating words.
For coding agents, SambaNova researchers measured SWE-bench Verified runs in early 2026 and found that "successful agentic trajectories typically remain under 20k-30k tokens". For GPT-5-nano, passing runs averaged 8,121 tokens and failing runs 14,809.
Figure 1 from The Limits of Long-Context Reasoning in Automated Bug Fixing by Raju, Ji, Upasani, Li and Thakker, 2026, CC BY 4.0.
The authors warn that the link may run both ways, since harder issues also need longer runs. Handing the models every relevant file up front did not help either: at 64,000 tokens, two models resolved 7% and 0% of issues. The causes below are ranked by how much of the context each takes and how often the vendors' docs name it; no study has counted which cause explains a bad session most often.
Tool output fills most of the window
Tool output is the largest cause because a coding agent reads files, logs and test runs into the same context it reasons in, and keeps them there. In the CliffCompaction paper by Tim Dettmers' group at CMU, tool results were 56.0% of context tokens and tool calls 28.0%, against 13.6% for the model's own thinking and 2.4% for the system prompt and task.
To test for it, run /context in Claude Code, which breaks the window down by category, or /status in Codex. Then ask the question Anthropic's Thariq Shihipar applies to his own sessions: "will I need this tool output again, or just the conclusion?"
The fix is a subagent. A Claude Code subagent starts with "a fresh, isolated context window", does the reading there and returns only its answer, typically 1,000-2,000 tokens according to Anthropic's context engineering post. Current Codex releases enable subagents by default, including an explorer for read-heavy work, and Cursor ships an Explore subagent. A tool that shrinks what the agent writes does much less: Caveman cut output tokens by 8.5% in a JetBrains test, against an advertised 65%, because tool output, not narration, fills the window.
When should work move into a subagent instead of /compact?
Work should move into a subagent before it fills the context, and /compact is for after. A subagent keeps the reading out of the main session entirely, so nothing has to be summarized later. /compact summarizes what is already there, and the summary is lossy. Use a subagent when you know a step will produce output you will not read again: a search across 40 files, a log, a test suite.
Subagents have costs. Their requests count toward the same usage limits, and a fresh one "may need time to gather context", per the subagent docs. A forked subagent (/subtask) inherits the whole conversation: one developer's traces, published by the vendor LangWatch in August, show forks starting at 523,000 tokens against about 30,000 for a fresh subagent.
Failed attempts stay in the context and steer the next one
A failed approach that stays in the context keeps influencing the agent after you have rejected it. Claude Code's best practices call it "polluted with failed approaches", and a Johns Hopkins and Apple paper on math and web search found that a model which solves a problem from a clean start "often fails when fed back its own flawed reasoning."
To test for it, count your corrections. If you have corrected the same thing twice, the context holds two wrong versions and one right one.
The fix is /rewind or /clear. /rewind returns the conversation, and optionally the code, to a checkpoint, such as the point after the useful file reads, so you can re-prompt with what you learned; it reuses the cached prefix, but it does not undo Bash file changes or most subagent edits. After two failed corrections, the docs say: "Run /clear and start fresh with a more specific prompt."
One session for unrelated tasks carries the old task's context
A session that moves from one task to the next carries every file and log from the first task into the second. The best practices call this "the kitchen sink session", and Thariq's rule is short: "when you start a new task, you should also start a new session."
To test for it, scroll up: if the context starts with work the current task does not need, it is a kitchen-sink session. /resume and --continue reload the old context "in full, baggage included", as Igor Irianto points out.
The fix is /clear (Claude Code) or /new (Codex) between unrelated tasks, with a written brief when the new task builds on the old one; for a related follow-up, Thariq notes, a new session has to re-read the files. The same reasoning gives the second-session review: "A fresh context improves code review since Claude won't be biased toward code it just wrote."
Compaction drops what you needed next
Compaction replaces the conversation with a summary that keeps what the model expected to matter. "Bad compacts can happen when the model can't predict the direction your work is going," Thariq writes. The post on context compaction covers what the summary loses.
To test for it, check whether the regression started right after a compaction. In LangWatch's traces, 41.9% of the developer's messages after a compaction contained a correction, against 17.7% otherwise, though he notes he sometimes compacted because things were already going badly.
The fix is to compact on purpose at a break, with a focus: /compact focus on the auth refactor, drop the test debugging. Claude Code re-reads up to five recent files after compaction and re-injects the root CLAUDE.md, per the context window docs. By default it compacts at the model's limit, about 967,000 tokens on 1M models, and /autocompact 300k moves that earlier.
Rules that live only in the chat get lost
A rule you typed into the chat lives in the context, so compaction can summarize it away. Claude Code's own docs say "detailed instructions from early in the conversation may be lost. Put persistent rules in CLAUDE.md." The opposite failure is a rules file so long the rules get ignored: "If Claude keeps doing something you don't want despite having a rule against it, the file is probably too long."
To test for it, ask the agent which rule applies to the step it is on, or run /doctor prompt-audit for contradictory instructions.
The fix is the repository, kept short: the docs target under 200 lines per CLAUDE.md. ETH Zurich's study of context files (v3, 29 September 2026) found LLM-written files raised cost by 20% to 23% with no significant change in success, so write the few rules the agent gets wrong, not a tour of the codebase. A codebase map such as aoci-code is the larger version of the same idea, and the posts on agent memory vs documentation and which layer each instruction belongs in go further.
Repeated work belongs in a headless loop
The same change applied to 300 files in one session piles 300 files' worth of output into one context. A headless loop gives each item its own short run. The best practices show the pattern:
for file in $(cat files.txt); do
claude -p "Migrate $file from Python 2 to Python 3. Return OK or FAIL." \
--allowedTools "Edit,Bash(git commit *)" --permission-mode dontAsk
doneRun it on two or three files first and refine the prompt. Codex's equivalent is codex exec, --max-budget-usd caps the spend, and inside a session /batch splits a change across 5 to 30 subagents in their own worktrees. No controlled study compares a loop with one long session; the closest evidence is SambaNova's finding that success comes from "task decomposition into short-context steps".
If you see this, check that, fix it this way
| You see | Check | Fix |
|---|---|---|
| Worse output after a lot of reading or test runs | /context: messages and tool output dominate |
Send verbose reading to a subagent |
| The agent repeats a fix you rejected | Two or more corrections on the same issue | /rewind to before the attempt, or /clear with a better prompt |
| Context from a previous task in the window | Scroll up, or /context |
/clear or /new, with a written brief |
| Regression right after a compaction | The transcript shows a compaction | /compact <focus> at a break; /autocompact earlier |
| A rule stops being followed | Ask which rule applies; /doctor prompt-audit |
Move it to CLAUDE.md or AGENTS.md, under 200 lines |
| The agent defends code it wrote earlier in the session | It reviewed its own diff | Second session or reviewer subagent |
| Quality drops as a batch job goes on | One session holds every item | Headless loop, claude -p or codex exec, or /batch |
| A fresh session with a brief fails the same way | Same failure without the old context | The model or the task: a two-agent study traced such failures to "implementation skill"; change the model or split the task |
Which of these do you use?
Nobody on Stackness runs aoci-code yet. Tick what you use and be the first.
