Claude Code Context Window for Client Work (When to Clear vs Compact)

The Short Answer

The context window is Claude Code's memory of the current session, and it has a limit. As a client session runs long, that window fills with earlier questions, abandoned approaches, and old versions of files, and the model starts answering with a picture that is partly out of date. The result is subtle: not an obvious error, but slightly worse answers, a reference to a decision you reversed an hour ago, a suggestion that ignores a constraint you set at the start.

Two commands are how you manage it. Clear the context, which wipes the session back to a clean slate, when you finish one task and move to something unrelated. Compact the context, which summarizes the conversation so far and drops the raw detail, when you are deep in one long thread that is still relevant but has accumulated noise. And keep the client's real facts, their stack, their constraints, the scope, in a CLAUDE.md the session reads, so neither a clear nor a compaction ever costs you the things that keep the build correct.

What the Context Window Actually Is

Think of the context window as the model's short-term working memory for one session. It holds the conversation, the files it has been shown, and the reasoning it has done, all at once, so it can answer as if it remembers the whole build. That is exactly why Claude Code feels like it understands your project: it is holding the recent history in view while it works.

The catch is that the window is finite, and everything competes for the same space. A file you had it read three tasks ago is still sitting in there, taking up room, even though it no longer matters. A long debugging detour you eventually abandoned is still in there, still being weighed. On client work this matters more than on your own projects, because a paid build tends to run for hours across many small tasks, and the window quietly turns from an asset into clutter without any warning that it happened.

When to Clear the Context

Clear the context when you finish one task and move to something unrelated. Clearing wipes the session back to a clean slate, so the next task starts with nothing from the last one weighing on it. This is the right move far more often than builders realize, because most client sessions are actually a string of loosely related jobs, not one continuous problem.

1. You finished the booking form and are now moving to the email notifications. Nothing about the form's history helps the email work, so clear before you start, and the model gives the notifications its full, unclouded attention.
2. You spent twenty minutes down a debugging path that turned out to be the wrong lead. Clear it out so that dead-end reasoning is not still sitting in the window influencing the next attempt.
3. You are switching from writing code to writing a client-facing update or a scope note. That is a different job entirely, and a clean slate keeps the two from bleeding into each other.

The instinct to keep everything in one long session because 'the model knows the project now' is the trap. It does not know the project from the chat log; it knows it from the files and from your CLAUDE.md, both of which survive a clear. What the chat log actually holds by hour three is mostly noise, and clearing it is how you get a sharp answer back.

When to Compact Instead

Compact the context when you are deep in one long, still-relevant thread that has picked up a lot of detail. Compacting summarizes the conversation so far and drops the raw back-and-forth, keeping the gist of what you have decided while freeing up the space the verbose history was eating. It is the middle path between carrying everything and throwing it all away.

The distinction from clearing is about relevance. Clear when the next thing has nothing to do with the last thing. Compact when the next thing is a continuation, the same feature, the same bug, the same client decision in progress, but the conversation has gotten long enough that the noise is starting to crowd out the signal. Compacting keeps you in the thread without paying the full cost of every message you have sent to get here.

The Facts That Must Survive a Reset

The rule that makes context management safe on client work is this: never let the chat history be the only place a real constraint lives. Anything the build must respect, the client's stack, the data you are not allowed to touch, the agreed scope, the naming conventions, goes in a CLAUDE.md file that the session reads, so a clear or a compaction never loses it.

This is the same discipline covered in [the CLAUDE.md file for client projects](/blog/claude-md-file-for-client-projects), and context management is the reason it pays off. When the durable facts live in a file, clearing the context stops feeling risky, because the things that keep the build correct reload automatically while the noise gets left behind. Without that file, every clear is a gamble that you have not just wiped the one constraint you needed, which is why builders avoid clearing and let their sessions rot instead.

1. Put the client's stack, the scope boundary, and any data-handling rule in CLAUDE.md, not just in a message you sent once.
2. Treat the chat log as disposable working memory and the file as the source of truth. If a fact matters past this hour, it belongs in the file.
3. After a clear on a client build, glance at what reloaded and confirm the key constraints are present before you start the next task.

Why This Matters More on Client Work

On your own project, a cluttered context produces a slightly worse answer you shrug off. On a paid build, it produces a slightly worse answer you might ship. The failure mode is quiet: the model, working from a stale window, suggests a change that contradicts a decision the client signed off on, and because it sounds confident and you are moving fast, it slips through.

Managing the window is really a verification habit in disguise. A clean context means the model is reasoning about the build as it actually is right now, not as it was three detours ago, which makes the output easier to trust and easier to check. It pairs directly with the recovery discipline in [what to do when Claude Code writes wrong code on a client build](/blog/claude-code-writes-wrong-code-on-a-client-build): a fresh context is one of the cheapest ways to stop a wrong answer from compounding into a wrong deliverable.

A Context Routine for Client Sessions

1. Keep the client's durable facts in CLAUDE.md so nothing important lives only in the chat log.
2. Clear the context whenever you switch to an unrelated task, and treat that as the default, not the exception.
3. Compact instead when you are still inside one long, relevant thread that has just gotten noisy.
4. Watch for the soft signal that the window is degrading, answers a step behind the build, and reset the moment you see it rather than pushing through.
5. After any reset on a paid build, confirm the key constraints reloaded before you start the next task, so a clean slate never means a lost rule.

Common Mistakes

1. Running one endless session for a whole client build because 'the model knows the project,' when most of that history is noise dragging every answer down.
2. Never clearing the context, so an abandoned debugging detour keeps influencing new work hours after it stopped being relevant.
3. Relying on the chat log to remember a client's hard constraint instead of putting it in CLAUDE.md, then losing it on a clear or blurring it on a compaction.
4. Compacting when you should have cleared, carrying a summary of an unrelated task into work that has nothing to do with it.
5. Ignoring the soft signal of a degrading context and blaming the model for worse answers, rather than resetting the window that caused them.

Inside the Claude Code Profit Room, builders compare exactly how they run long client sessions, when they clear, when they compact, and what lives in CLAUDE.md versus the chat. It's $9 a month at https://www.skool.com/claudecodeprofitroom/about, come swap the routines that keep a paid build sharp from the first hour to the last.