When should you clear your coding agent's context?

"At what % do you clear context and open a new chat?" keeps coming up on r/ClaudeCode, and the answers are usually a meter reading, or "whenever auto-compact fires." The research published this month points at a better trigger. Four research teams running long agent sessions in October, at Anthropic, Microsoft Research, UC Berkeley with Stanford, and the group behind a paper called Stateless Language Agents, found the same failure: the longer an agent works in one context, the more it anchors on its own earlier attempts and keeps circling them. Clearing your coding agent's context fixes that. Compacting it doesn't. The work survives the reset because it lives on disk, in files the next session can read.

TL;DR: Clear your coding agent's context when you switch tasks, when you've corrected it twice on the same issue, or when it keeps circling one idea. Write a short handoff note first. In one October study, research agents given fresh contexts on the same workspace beat one long run by 66% at equal compute.

Why does a coding agent get worse in a long session?

Two separate failures build up in a long agent session. The first is the one most people know as context rot: Anthropic's guide to Claude Code sessions (opens in a new tab) describes it as performance degrading "as context grows because attention gets spread across more tokens, and older, irrelevant content starts to distract from the current task." Claude Code's one million token window delays that point without removing it.

The second reason is newer, and it hurts more on hard problems. Drew Breunig, who writes about context engineering, calls it context inertia (opens in a new tab): the agent commits to a hypothesis and keeps pursuing it after the evidence says to stop. A UC Berkeley and Stanford team measured it in Scaling Discovery Requires Forgetting (opens in a new tab): as sessions grew, each agent "becomes anchored to its own past attempts, making fewer and smaller edits," and Breunig reports their thinking tokens per turn fell by 75%. In another paper Breunig covers, Stateless Language Agents (opens in a new tab), one long run made no tool calls at all in 98% of its final 1,500 turns.

You've seen the small version of this. The agent decides the bug is in the cache layer, and every fix after that is another cache tweak.

Does compacting the context fix it?

Microsoft Research tested this in its Fork-and-Flush (opens in a new tab) paper and found the fixation "persists despite periodic compaction of conversation history." A coding agent that's stuck stays stuck after /compact.

The reason is what a summary keeps. As Breunig points out, compaction is built to carry the current task and the work in progress into the next window, and the work in progress is exactly the idea the agent is stuck on. A summary of an afternoon chasing the cache layer is a short, confident note that says the bug is in the cache layer.

Anthropic's guide adds a second problem: because of context rot, "the model is at its least intelligent point when compacting." The summary gets written at the moment the session is at its worst. Compacting still has a job. It's the right tool when a single task is running long, the thread still matters and the agent is making progress. It's the wrong tool for a session that's going in circles.

What did the research do instead?

Every team that hit this in October landed on the same fix: throw the conversation away and keep the work. Breunig counted the four teams reaching the same conclusion within 10 days, with GPT, Claude, Qwen, GLM and DeepSeek models. These are research agents running for hours or days, and none of the percentages below transfer to an interactive coding session as numbers, though the mechanism does. Three of the teams measured it:

• Fork-and-Flush (Microsoft Research, 5 October) forks the agent into parallel runs. Each one inherits the workspace and starts with a fresh chat context, and the agent continues from whichever scores best. Across 13 long research and engineering tasks it beat a single long run by a relative 66.0% and best-of-N (several separate runs, keeping the best) by 44.4%, on the same compute budget. Part of that gain comes from picking the best fork.
• Scaling Discovery Requires Forgetting (UC Berkeley and Stanford, 14 October) gets its gain from a plain reset: it periodically discards every agent's session and restarts from the best candidate so far, for results up to 39% better than a single agent and up to 15% better than parallel agents.
• Memento, a harness in Anthropic's research on self-replicating AI (opens in a new tab), gives each agent a fixed slot (1.5 hours in one experiment), then has it write a short note on what it tried. Anthropic uses it for long tasks like getting a model's inference server running on unfamiliar hardware. A fresh agent inherits the code, the environment and the note, and nothing else. Anthropic built it after watching a Qwen agent debug package versions for hours when the real bug was an endpoint incompatible with the test's grading API.

When should you clear your coding agent's context?

Clear your coding agent's context on an event, not a percentage. A token count still helps as a warning light: Breunig says his is around 200,000 tokens, and past that he checks what's in the window before starting anything big. Treat any number like that as one person's habit, and let these four events decide:

1. You're starting a new task. Anthropic's rule of thumb for Claude Code: new task, new session. The last task's history only gets in the way of this one.
2. You've corrected it twice on the same issue. The Claude Code docs (opens in a new tab) put it plainly: after that, "the context is cluttered with failed approaches," so run /clear and start over with a better prompt that includes what you learned.
3. It's circling: the same hypothesis turn after turn, edits getting smaller, or a fix that undoes the previous fix. That's inertia. Telling the agent to drop its theory sometimes works; a fresh context is the reliable way out.
4. You're about to compact a session that went sideways. If the summary would mostly describe a dead end, write your own note and clear instead.

What should you keep before you clear?

Keep the state, in files, written for a reader who wasn't there. Anthropic's guide describes the /clear version well: you write down what matters ("we're refactoring the auth middleware, the constraint is X, the files that matter are A and B, we've ruled out approach Y") and start clean. Memento's numbers point the same way. In Anthropic's runs, Qwen3.5-9B agents that inherited the previous agent's notes and workspace completed their setup task 45% of the time in the first generation and between 61% and 84% in later ones.

I keep two things. A short handoff file:

And a failing test. I write the test before an agent writes the code, so when I clear, the definition of done is still sitting in the repo, red, and the new session starts from it instead of from my memory of the conversation. The note records what was tried; the test defines finished, and a summary can't quietly rewrite it. When the task has no testable finish yet, as in exploratory debugging, the Goal line has to carry that job alone.

Leave out the theory of the bug, and write the "tried and ruled out" line yourself, or edit the agent's draft hard. A stuck agent will describe its own theory as the lead, which is the same flaw as a compaction summary. The evidence goes in; the fresh session forms its own hypothesis from it.

What to do next

Next time you open a long session, watch for the events instead of the meter. When one fires, have the agent draft the handoff file, rewrite its "tried" line yourself, commit it with the failing test, run /clear, and point the new session at both. In Claude Code, /rewind is the lighter option when only the last attempt went wrong: it drops the failed turns and keeps the useful file reads.

The October papers measured agents running for days. The habit is the same at any length: keep the work in the repo, and let the conversation go.

I write about working with coding agents and new models on the gabs.app blog, with shorter takes on X (opens in a new tab). If you're hiring a senior full-stack engineer who builds test-first with agents, read how I work and get in touch.