A clean white desk with a laptop, representing a fresh start

Stop Hoarding Context: Why Fresh Sessions Make AI Coding Agents Better

Long AI coding sessions get worse as the context window fills up. This is a practical guide to managing sessions, using the /clear command, and keeping useful memory in CLAUDE.md so every fresh session starts with what it needs.

26 February 20268 min readBy LibraBit Team

You've been coding with Claude Code for three hours. You started by scaffolding a new feature, then fixed a bug, tweaked some styles and asked it to write tests. Somewhere around prompt forty you notice the output is getting worse. The agent seems confused, it's repeating mistakes you already corrected, and it's ignoring instructions you gave twenty minutes ago.

So you repeat yourself, re-explaining the requirement and pasting in the same code block again. You burn through tokens restating things the agent should already know, and the results are still mediocre.

What's happening here is a predictable result of how context windows work, and it's one of the most common mistakes new users of AI coding tools make. The fix might feel odd at first, but it works well: stop trying to keep everything in one session.

How Context Windows Actually Work

Every AI coding agent (Claude Code, Cursor, Codex, Gemini CLI) works within a context window. This is the total amount of text the model can hold in its working memory at any one time. You can think of it like a desk with a fixed amount of space, where everything has to fit. Your messages, the agent's replies, file contents, tool outputs and system instructions all share that same space.

Claude Code's context window is roughly 200,000 tokens. That sounds enormous, but it fills up faster than you'd expect. A single file read might use thousands of tokens, and tool outputs, error messages and the back and forth of debugging all add up. MCP server configurations alone can use a big chunk before you've typed a single prompt.

When the context window fills up, the system doesn't just stop. It compacts, summarising older parts of the conversation to make room for new ones. The agent keeps working, but it's now working from a compressed summary of what happened earlier instead of the full detail, and this is where quality starts to wear away.

The Quality Curve

Research into large language model performance shows clearly that output quality gets worse as context length grows. A study by Chroma Labs measuring 18 LLMs found that "models do not use their context uniformly; instead, their performance grows increasingly unreliable as input length grows." Information in the middle of long contexts is especially likely to be missed, which researchers call the "lost in the middle" problem.

In practical coding terms, this works out as three quality zones, based on how full the context window is:

  • 0-40% capacity: Clean, accurate output, with instructions followed precisely and well-structured code.
  • 40-70% capacity: Quality begins to slip. The agent cuts corners, sometimes misses requirements, and needs more corrections.
  • 70%+ capacity: Noticeably worse output. Instructions are ignored or misread, and the agent starts writing code that contradicts decisions made earlier in the session.

Developers who have tracked their sessions carefully report the same pattern. Will Ness compared compacted sessions against fresh ones across 25 files and found that clearing context between tasks kept edits consistently in the high-quality zone, while the compacted approach pushed later work into degraded performance.

People have started calling this context rot. As the agent piles up more information than it can handle well, its attention gets diluted. Important constraints get buried, tool choices start to wander and key instructions get lost in the growing wall of text.

The Real Cost of Long Sessions

The drop in quality is bad enough, but the knock-on effects make it worse.

Rework spirals: When the agent produces lower-quality output, you spend more prompts correcting it. Each correction adds to the context and pushes quality down further, so you end up spending more tokens to get worse results.

Token waste: A 2025 analysis by GitClear found an eightfold increase in duplicated code blocks over two years of AI-assisted development. Copy-pasting rose from 8.3% to 12.3% of all code changes. Much of this comes from agents losing track of what's already in the codebase and writing code that was already there.

Debugging overhead: Google's 2025 DORA Report linked increased AI adoption with a 91% increase in code review time and a 9% climb in bug rates. Long, degraded sessions add directly to this, because the agent introduces subtle issues that take longer to find and fix than writing the code from scratch would have.

The METR paradox: A study by METR found that experienced developers actually took 19% longer to complete tasks when working with AI tools than without them, which went against their own predictions of a 24% speedup. The researchers put much of this down to the time spent reviewing, correcting and reworking AI output, and long, unfocused sessions make that worse.

The Fix: One Task, One Session

The fix is to treat each task as its own session. When you finish a piece of work, clear the context before you start the next one.

In Claude Code CLI, type /clear after each task. This wipes the conversation history and gives you a clean context window, and Claude re-reads your CLAUDE.md file and starts fresh.

In Claude Code Desktop, start a new chat for each separate task instead of typing into the same conversation for hours.

In Cursor, press Cmd+N (Mac) or Ctrl+N (Windows) to open a new session.

The same idea applies to any AI coding tool: fresh context means full attention capacity. The agent isn't carrying around compressed summaries of old work that doesn't matter any more, so every token of that 200,000 window is free for the task in front of it.

What Counts as a "Task"?

A task is a single piece of work that hangs together, for example:

  • Implement a new component
  • Fix a specific bug
  • Write tests for a module
  • Refactor a function
  • Update styles on a page

If you find yourself switching topics, say from a feature to a bug fix or from frontend work to backend work, that's a good sign it's time to clear and start fresh.

A useful rule of thumb is that if you'd make a separate git commit for it, it should be a separate session.

"But Won't It Forget Everything?"

This is the fear that keeps people clinging to marathon sessions. If you clear the context, won't the agent lose all the knowledge it's built up, and won't you have to re-explain everything from scratch?

It won't, and the worry comes from a small misunderstanding of how coding agents work.

When you start a fresh session, the agent doesn't begin from nothing. It has access to your whole codebase, so it can read any file, run commands, look at your project structure and configuration files, and see the current state of your code directly.

Reading the relevant files is how the agent knows your codebase in the first place, so it doesn't need to "remember" it from earlier in the conversation. It'll read them again in a new session when you give it a task.

Think about what a coding task actually needs:

  • The current state of the code, which the agent reads from your files
  • What you want changed, which you state in your prompt
  • Project conventions and preferences, which live in your CLAUDE.md file

None of these need a long conversation history. The first is always on disk, the second is your new prompt, and the third is loaded automatically every time.

What you do lose is the conversation about how you got to the current state, and that almost never matters for the next task. The agent doesn't need to know that you tried three different approaches to the nav bar before settling on the current one. It only needs to see the current nav bar and know what you want changed.

Persistent Memory: CLAUDE.md and Beyond

To work confidently with fresh sessions, make sure the important context lives outside the conversation.

CLAUDE.md

This is the most important file in your project for AI-assisted development. Claude reads it at the start of every session, so it works like a project brief that never expires.

A well-kept CLAUDE.md should include:

  • Tech stack: What framework, language, and key libraries you are using
  • Code conventions: Naming patterns, file structure, formatting preferences
  • Common commands: How to run the dev server, run tests, build for production
  • Architecture notes: Key design decisions that should not be revisited every session

If you don't have one, run /init in Claude Code to generate a starter file, then refine it as your project grows.

.claude/rules/ Directory

For larger projects, you can split instructions into separate rule files. Instead of one large CLAUDE.md, you create focused files like testing.md, api-design.md, or security.md inside .claude/rules/, and Claude loads all of them automatically.

You can even scope rules to specific file paths using YAML frontmatter, so your React component conventions only apply when Claude is working on React files.

Auto Memory

Claude Code also keeps its own automatic memory. As it works, it saves useful context (project patterns, debugging insights, architecture notes, your preferences) to a persistent directory at ~/.claude/projects/<project>/memory/, which is loaded into every new session automatically.

You don't need to manage this yourself, as Claude looks after it while you work. You can still tell Claude to remember something specific, such as "remember that we use pnpm, not npm" or "save to memory that the staging server is at staging.example.com", and it'll stick across sessions without you needing to repeat it.

AGENTS.md

Some teams use an AGENTS.md file (a convention that has emerged across multiple AI coding tools) to define how agents should behave in a repository. Claude Code uses CLAUDE.md natively, but you can reference an AGENTS.md from inside your CLAUDE.md if your team uses one. Either way, the idea is to keep persistent context in files, where every new session can find it.

A Practical Session Workflow

Here's the workflow we use and recommend to clients:

1. Start fresh. Open a new session or use /clear.

2. State the task clearly. Give it one prompt with one objective, for example: "Add form validation to the contact page. Email should be validated with a regex. Phone number should accept UK formats. Show inline error messages below each field."

3. Let the agent work. It'll read the relevant files, work out the current state and make the change.

4. Review and iterate. If adjustments are needed, make them in this session while the context is still focused and clean.

5. Commit your work. Once the task is done, commit the changes.

6. Clear and move on. /clear (or a new session), then start the next task.

Working like this has a few benefits. The agent works in its highest-quality zone for every task, and you spend fewer tokens because you're not dragging around earlier context that no longer matters. Your git history also ends up cleaner, because each session maps to a logical unit of work.

When to Keep a Session Going

There are times when staying in the same session makes sense:

  • Iterating on the same feature: If you're refining a component and each prompt builds directly on the last, keep going, as the context is still relevant.
  • Debugging a specific issue: If you're working through a single bug, the diagnostic context (error messages, stack traces, attempted fixes) is useful to keep.
  • Multi-step processes: If the agent is partway through a migration or refactor that spans multiple files, let it finish before clearing.

As a rule of thumb, if the next prompt directly depends on what just happened, stay in the session, and if you're moving on to a different concern, clear.

Key Takeaways

  • Context windows have limits. Every AI coding agent gets worse as the context fills up. That's simply how the technology works, so it's worth planning around it.
  • Clear often. Use /clear in the CLI or start a new chat on Desktop after each logical task, and you'll get higher-quality output.
  • The agent doesn't forget your code. It reads your files directly, so a new session gives it a clean, focused context and it can still see everything on disk.
  • Put persistent context in files. CLAUDE.md, .claude/rules/ and auto memory give the agent what it needs across sessions, because files are still there after a conversation ends.
  • One task, one session. If you'd make a separate git commit for it, give it its own session too.

So next time a session starts to feel sluggish, try /clear and give the agent its next task in a fresh session, with its full attention on the work in front of it.


References