Claude Memory Compaction: What Survives a Long Chat

Claude memory compaction usually refers to summarizing a long conversation so work can continue within the available context, the information used for the current response. That is different from saved memory, which carries selected information across conversations; neither should be treated as an exact project archive.

Before a long session changes shape, preserve the decisions, unfinished work, and evidence that the next action depends on. Tools like fenbs keep that reviewed work record outside the conversation, so a useful handoff does not depend entirely on what a summary retained.

What does compaction actually change?

Compaction changes the working representation of the conversation. Instead of carrying all earlier exchanges in their original form, the assistant continues with a shorter account. In its Claude chat limits guidance↗ (opens in a new tab), Anthropic describes automatic summarization for long conversations with code execution enabled, while preserving full chat history for reference.

A preserved history and active context are different things. You may still be able to open an old exchange without every sentence being present in the assistant’s immediate working material. For an important requirement, verify what the continuing session is using rather than assuming the original wording remains equally available.

Think of a project meeting reduced to meeting notes. The notes can preserve the decisions and action items very well, while leaving out an exception that seemed minor when they were written. The right response is to check the consequential details, rather than expecting the summary to replace the full record for every purpose.

How is this different from saved memory?

Saved memory concerns information available across sessions, while compaction concerns the working conversation you are already in. Anthropic documents chat search and memory↗ (opens in a new tab) as ways to bring earlier context into later conversations. Those features should not be confused with a guarantee that every detail of one long chat survives in its current summary.

The guide to Claude project memory covers project carryover separately. For the distinction between remembered facts and reusable procedures, see Claude memory versus skills.

What survives in Claude Code?

Claude Code has its own documented behavior. Anthropic’s context window guide↗ (opens in a new tab) says compaction summarizes conversation history, while certain instruction material reloads from disk. Project-root instructions and on-demand rules do not all return in the same way, so consult the current breakdown for the mechanism you use.

That distinction matters when debugging a missing instruction. A lasting repository rule may have a different route back into the session from a one-time request typed in chat. Ask Claude to read the applicable instruction file or source again when the exact requirement is important.

Do not assume that a conversation summary reverses a file edit or cancels a running process. The same guide distinguishes continuing background work from summarized conversation content. Check the actual workspace state before restarting an operation, especially if another session could duplicate the work.

For the separate local-memory workflow, see Claude Code memory. The practical point here is to recover the next action from current evidence, not just from a confident summary of what supposedly happened.

Which details deserve an explicit checkpoint?

Prioritize details that change what the assistant may do next. A general project description is useful, but an unresolved approval or a failed check is more likely to affect the immediate action. Preserve the wording of a requirement when paraphrasing could change its meaning.

• The current goal and the task being worked on.
• Decisions a person approved, including any important exception.
• What changed and where the result lives.
• Checks actually run, their results, and what remains unverified.
• Open questions and actions waiting for a person.
• The next step, including anything still running that must be checked first.

Say an assistant revises a customer proposal. A useful checkpoint says the text was updated to the approved scope, the attachment still needs review, and sending has not been authorized. “Proposal completed” loses the distinctions that protect the next session from assuming it can send.

Keep that checkpoint with the work using fenbs’s AI handoff workflow. A task’s specific progress and the project’s Where we left off answer different questions, so update both when their state changes.

How should you check a session after summarization?

1. Ask Claude to restate the current goal, binding requirements, unfinished work, and proposed next action.
2. Compare that account with the approved decision and the latest task record.
3. Restore missing details from their source, especially exact wording, exceptions, and failed checks.
4. Ask Claude to identify which information remains uncertain before continuing.
5. Check the result of the next action rather than treating a correct restatement as proof the task was completed.

Use a focused correction when something is missing. Instead of “you forgot everything,” state the requirement, where it came from, and what it changes. For example: “The proposal must exclude installation. That was the approved scope, so revise only the materials section.”

If the summary keeps carrying an outdated assumption, start a fresh conversation from a reviewed current record. Continuing a confused thread is not always more convenient than resetting its starting point. Preserve source links so the new session can verify the facts rather than trust another layer of summary.

How to do this with fenbs

1. Create a free account and add the project you want to continue across sessions.
2. Add the active tasks and record the choices a person has approved in Decisions and rules. Keep proposals and unresolved questions separate.
3. Connect Claude using the integration guide, then ask it to save task progress and Where we left off before the session ends.
4. In the next conversation, ask Claude to read the project context and state the next action, outstanding checks, and anything waiting on a person.

fenbs does not control Claude’s compaction or automatically read its chat history. If you only need to finish a short one-off conversation, a separate work record may add little; it helps when decisions and unfinished tasks must remain available after the conversation ends.

What makes a handoff trustworthy over time?

A handoff earns trust when it stays tied to evidence. Name the checked result, distinguish an assumption from an approved decision, and update the next step after real progress. A stale checkpoint is another outdated source, even when its original wording was excellent.

Keep a small record a person can review, with links to the detail when needed. The context engineering hub explains the wider practice. The goal is simple: the next assistant should know where to begin and what still needs checking before it changes anything.