What NOT to Save
In one line: Save only what the AI cannot derive from the code — judgment calls and context, not code patterns, git history, or ephemeral state.
Do this: Before writing a memory, ask "if a fresh session lacks this, what goes wrong?" If the answer is "nothing, it can read the code," do not write it.
What: Not everything belongs in memory. Over-saving dilutes the signal of genuinely important knowledge. Memory holds judgment calls and context — things the AI cannot derive from the code.
Do not save:
| Category | Why Not | Where It Lives Instead |
|---|---|---|
| Code patterns | Readable from the source code directly. Memory about code drifts as code changes. | The code itself. Reference memory can document why a pattern exists but should not duplicate the implementation. |
| Git history | Accessible via git log. Duplicating commit history in memory wastes context. | Git. |
| Debugging session details | Ephemeral. The specific port conflict or import error from Tuesday's debugging session has no lasting value. | Nowhere — let it go. |
| Test commands | Documented in CLAUDE.md (project instructions). | CLAUDE.md's testing section. |
| File-level documentation | Belongs in code comments, docstrings, or README files co-located with the code. | The source files themselves. |
| Current task status | Changes too rapidly. By the time memory is read in the next session, the status is stale. | Conversation context within the current session. |
The filtering principle: Before writing a memory, ask: "If Claude starts a fresh session tomorrow and does NOT have this information, what will go wrong?" If the answer is "nothing — it can figure this out from the code or CLAUDE.md," do not create a memory file. If the answer is "it will repeat a mistake we already corrected" or "it will propose an approach we already rejected," create the memory.
Evidence: The memory system is selective by design — it captures decisions (why we chose one tool over another), preferences (always use migrations), corrections (never blanket-delete a shared bucket), and state (which pillars are complete), not code snippets, debugging logs, or test output. The 24,000-byte hub budget (enforced by the budget-check hook) is what keeps it readable in full at session start: the hub links to topic files rather than inlining everything.