When to Start a Fresh Session vs. Continuing a Bloated One

Every long Claude Code session eventually faces the same question: keep going, or start over? Continuing feels efficient, all that context is still "in there," and starting fresh means re-explaining things. But a bloated session has costs that aren't always obvious until something goes wrong. Here's how to tell which situation you're in, and what to do about it.

What "bloated" actually means

A session isn't bloated just because it's long. It's bloated when the ratio of useful signal to accumulated noise has tipped, when old tool outputs, abandoned approaches, and resolved side-quests are taking up more of the context window than the information you actually need right now. Signs this has happened:

• Claude re-reads a file it already read ten messages ago because it's no longer sure what's in it.
• It starts contradicting decisions made earlier in the same session, or asks about something you already answered.
• Responses get slower or vaguer, or start missing details you know you provided.
• You find yourself repeating instructions ("remember, don't touch the legacy auth module") because they no longer seem to be landing.
• The session has been compacted or summarized once already, and you can feel information has gone missing.

None of these are about message count directly. A session with two hundred short, focused messages on one narrow bug fix might be fine. A session with twenty messages that each dumped a huge file or command output can bloat fast.

When to keep going

Staying in the same session is usually right when continuity itself is doing work for you:

• You're mid-task on something the model has real, still-relevant context on, it's read the relevant files, understands the approach, and nothing about that has gone stale. Restarting here means paying the re-orientation cost for no benefit.
• You're iterating tightly on the same narrow piece of code. Fixing a function, then adjusting it again based on test output, then adjusting again, this kind of back-and-forth benefits from the model remembering exactly what it tried and why.
• You're debugging something where the history of what's been ruled out matters. If you've already established "it's not the database connection, not the auth token, not a race condition," that negative information is valuable and expensive to reconstruct from scratch.
• The task is naturally continuous and not that large, a single-file refactor, a focused bug hunt, a small feature that touches two or three files. These usually finish before bloat becomes a real problem.

When to start fresh

A new session is usually the better call when the cost of losing history is lower than the cost of carrying it:

• You're starting a genuinely new task, even in the same repo. There's little reason for a session about fixing the checkout flow to also carry the full history of yesterday's logging refactor. Separate tasks, separate sessions, it keeps each one's context focused on what's actually relevant.
• The session has drifted through several unrelated detours. If you went down a path, abandoned it, tried something else, abandoned that too, and are now on your third approach, the session is carrying a lot of dead weight. A fresh session with a clean, current summary of "here's where we landed" often outperforms the tangled original.
• You've hit a point where the model seems to be working from a stale or confused picture, contradicting itself, forgetting recent constraints, or re-doing work it already did. This is the clearest signal: if bloat is actively degrading output quality, staying in the session is making things worse, not better.
• You're handing the task to someone else, or coming back to it after a long gap. A fresh session forces you to write down what actually matters, which is often a good exercise on its own, and gives whoever (or whatever) picks it up next a clean starting point instead of an archaeology project.
• You want a second opinion on work the current session produced. A session that wrote the code is prone to reviewing it with the same blind spots that produced it. A fresh session reviewing cold is closer to how an actual outside reviewer would catch things.

The middle path: checkpoint, then decide

You don't have to choose blind. Before deciding, ask the current session for a short summary: what's done, what's left, what's been ruled out, and any open questions. This does two useful things at once, it's a real-time check on whether the session's own picture of the task still makes sense, and it gives you a compact artifact you can carry into a fresh session if you decide to start one.

If the summary comes back clean and accurate, that's a good sign the session is still healthy and worth continuing. If the summary is vague, missing things you know are true, or takes real effort for the model to reconstruct, that's the bloat signal itself, better to have caught it now than three more messages in.

A practical habit: write that summary into a file (PROGRESS.md, a scratch note, whatever) rather than leaving it only in the chat. Then the decision to continue or restart stops being high-stakes either way, because the important state lives somewhere durable regardless of which session you're in.

A rough rule of thumb

• Small, continuous, still-coherent task → keep going.
• New task, drifted task, or visibly degrading output → start fresh, carrying forward a written summary, not the raw history.
• Unsure → ask for a checkpoint summary first, then decide based on how good that summary is.

The underlying goal is the same one that makes any long task manageable: keep the model working from an accurate, current picture of what matters, and don't make it pay the cost of dragging along everything that doesn't.