Memoria y comandos Compact

Claude Code runs inside a finite context window. As a session grows, two pressures appear: you want some notes to survive every session, and you want the running conversation to stay small enough to reason well.

Two commands handle these jobs:

• /memory — edits CLAUDE.md so instructions persist across sessions.
• /compact — compresses the current context to free space, at the cost of detail.

This lesson is from Domain 5 (Context Management & Reliability) and Domain 3 (Claude Code Config). Knowing exactly what each command does — and what it costs — is an exam favorite.

/memory opens your CLAUDE.md for editing. Whatever you write there is loaded into context at the start of every session — it is durable, not tied to one conversation.

Use it for stable facts the model should always know: project conventions, build commands, architectural rules, coding standards. Think of CLAUDE.md as your project's long-term memory; /memory is just the editor that opens it.

/memory can target different scopes, and scope decides who sees the note:

• User-level ~/.claude/CLAUDE.md — personal, NOT shared via version control. New teammates never see it.
• Project-level ./CLAUDE.md or .claude/CLAUDE.md — committed to VCS, shared with the whole team.
• Directory-level — scoped to a subtree of the repo.

Exam trap: if a rule must reach every teammate, it belongs in the project-level file. Putting a shared convention only in user-level memory means onboarding teammates silently miss it.

A giant CLAUDE.md burns context on every session. Two techniques keep it lean:

• @path imports modularize content, e.g. @./standards/coding-style.md pulls a file in by reference.
• .claude/rules/ files with YAML frontmatter paths load only when you edit matching files — saving tokens versus a monolithic memory file.

So /memory is not just "write everything down"; it is curating which durable instructions are always-on versus loaded on demand.

Where /memory is about persistence, /compact is about capacity. It compresses the current conversation — summarizing earlier turns — so you reclaim space and can keep working in the same session.

This is a form of progressive summarization. It is genuinely useful on long sessions before you hit the context limit. But summarization is lossy, and the losses are predictable enough to be examined.

Here is the cost the exam wants you to know. Progressive summarization makes exact numbers, percentages, and dates vague. "Refund of $487.10 on 2026-03-14" can collapse into "a refund earlier."

For an architect this is a reliability bug, not a cosmetic one. If a downstream decision depends on a precise figure or timestamp, /compact can silently erode the very facts the task hinges on.

The architect-grade fix: do not trust the summary to hold critical figures. Pull transactional facts into a separate "case facts" block kept verbatim outside the summary.

Before compacting, persist exact values — order IDs, amounts, dates, thresholds — in a place that won't be summarized (e.g. a notes file or a verbatim facts section). Then /compact can compress the chatter while the hard facts survive intact.

/compact keeps you in the same session. Sometimes that is the wrong move. A related pattern: starting a fresh session with a structured summary can beat carrying a long, noisy history forward.

This mirrors the sessions trade-off: --resume <name> continues a named session, but resumed tool results can be STALE if the codebase changed underneath you. When history is both bloated and outdated, a clean session seeded with a tight summary is more reliable than compacting stale context.

Context management is bigger than one command. Models attend to the start and end of context more than the middle — the "lost-in-the-middle" effect. So where a fact sits matters, not just whether it survived /compact.

Complementary habit: trim verbose tool output to the relevant fields before it enters context. Keeping context small and well-ordered reduces how often you need to compact at all, and keeps critical facts out of the neglected middle.

These two commands solve different axes, and good architects use both deliberately:

• /memory → persistence across sessions (durable instructions in CLAUDE.md).
• /compact → capacity within a session (lossy summarization to free space).

A typical long task: keep conventions in project CLAUDE.md via /memory; pin exact figures into a verbatim facts block; /compact when context fills; and if the carried history is stale or huge, start fresh with a structured summary instead.

Put it together on a multi-hour refactor:

• At setup, /memory records the build command and the rule "review in an isolated session."
• Mid-session you extract the exact failing test names and line numbers into a verbatim block.
• Context fills → /compact compresses the exploration narrative, leaving the verbatim facts and recent turns sharp.
• Hours later the branch has drifted → you abandon the bloated history and open a fresh session seeded with a tight summary.

Notice: persistence, precision-protection, and capacity are managed as separate decisions — never assumed to be free.

Apply the trade-off to a real scenario.

Key takeaways:

• /memory edits CLAUDE.md — durable instructions that persist across sessions. Project-level is shared via VCS; user-level is personal and missed by new teammates.
• Keep memory lean with @path imports and .claude/rules/ (frontmatter paths) that load only when relevant.
• /compact compresses live context to free space, but progressive summarization makes numbers, dates, and percentages vague.
• Protect critical figures in a verbatim 'case facts' block outside the summary before compacting.
• When history is stale or bloated, a fresh session with a structured summary can beat /compact or --resume. Mind lost-in-the-middle and trim verbose tool output.