Открыл новую сессию Claude Code в проекте, который не трогал две недели. Спросил «как там клиент, на каком этапе работа». Claude ответил с такими деталями, которых я ему в этой сессии точно не давал. Имя ssh-хоста, где живёт dev-стенд. Срок до приёмки. Папку для задач в моём Projects.

Я смотрю на ответ и думаю: я ему это не говорил. По крайней мере, сегодня.

Полез смотреть, что у меня хранится в ~/.claude/. Нашёл папку memory/ с шестнадцатью markdown-файлами. Открыл, и там лежит про меня всё: контекст по клиентам, мои предпочтения по тону, серверные правила, истории провалов. Всё, что Claude когда-то услышал и решил, что стоит запомнить.

Ну.

За час разбора понял: память у Claude Code не одна, а пять разных механизмов. Я пользовался одним. Двумя не управлял вообще. Один мог отключить и не знал. Один стоит ставить вручную, если строишь что-то серьёзное.

Теперь про каждый из пяти. Что куда положить, что куда не клади, и где у меня уже были грабли.

Сначала про то, как Claude вообще «помнит»

Если коротко, вот что улетает в API при каждом запросе:

• Системные инструкции (от вас или от Anthropic)

• Содержимое CLAUDE.md, если он есть

• История текущего диалога

• То, что Claude прочитал из файлов и тулзов в этой сессии

Всё это сжимается в один большой промпт. У Sonnet 4.6 окно 200К токенов. У Opus 4.7 в режиме 1M уже миллион. Но дешёвые токены это cache_read, и кэш ломается как только меняется содержимое в начале промпта. Поэтому экономия на памяти это не «не хранить», а «положить туда, где не сломает кэш».

Главное: Claude Code не помнит в человеческом смысле. Он каждый раз заново подставляет в промпт то, что считает релевантным. Интересно тут другое: кто и как это решает.

Поехали по уровням, от простого к сложному.

Уровень 1. CLAUDE.md, или то, что Claude видит ВСЕГДА

Самый старый и предсказуемый механизм. Кладёшь файл CLAUDE.md в корень проекта, его содержимое автоматически приклеивается к каждому промпту в этом проекте.

У меня в одном проекте CLAUDE.md выглядит так:

## Стек
Next.js 15, Postgres 16, Tailwind, shadcn/ui

## Запуск
- pnpm dev: локально
- pnpm test: Vitest

## НЕ трогать
- /legacy: старый код, на него завязан скрипт миграции
- migrations: только append-only, никогда не править существующие

Простой инфраструктурный текст. Около 2К токенов. Висит на каждом запросе.

Анти-паттерн, который я наблюдал у других: затолкать в CLAUDE.md всю архитектурную доку, инструкции по тестированию, истории фич. Получается 50К токенов, которые подгружаются в каждый запрос. На сотню запросов в день это лишние пять миллионов токенов в промпте, за которые мы заплатим.

Совет: держите CLAUDE.md под пять тысяч символов. Если хочется больше, выносите в отдельные .md файлы и пусть Claude читает их по требованию через Read.

Уровень 2. Auto-memory, или то, что Claude сам пишет про вас

Тут начинается магия, ради которой я вообще полез в эту тему.

Папка ~/.claude/projects/{ваш-путь-в-кодировке}/memory/. Внутри markdown-файлы и индекс MEMORY.md. Когда я в новой сессии задаю вопрос, Claude читает индекс, решает какие файлы релевантны теме, и подгружает их в контекст. Файлы, которые он сам же раньше написал.

Шестнадцать файлов. Структурированы по типам:

• user: что-то про меня (роль, предпочтения, экспертиза)

• feedback: правила работы со мной (как не надо, как надо)

• project: текущие проекты и их контекст

• reference: где что лежит (Linear, Slack, Yandex.Disk)

Что туда попадает само, без моего участия:

• feedback, когда я говорю «больше так не делай»

• project, когда рассказываю про нового клиента

• reference, когда даю внешнюю ссылку

• user, когда говорю про себя что-то характерное

Что я могу добавить руками: либо промптом «запомни, что я работаю в UTC+3», либо просто отредактировать markdown-файл напрямую.

Где это уже сэкономило мне время:

• В новой сессии через две недели спрашиваю «как там клиент Х». Claude отвечает по делу: где dev-стенд, под каким пользователем ходить, какая папка с задачами.

Где меня кусали грабли:

Один раз он записал в feedback моё раздражённое «вообще не трогай это», а я имел в виду конкретный файл, не подсистему. Потом две недели в эту подсистему он не лез, я не понимал почему. Открыл память, нашёл устаревшее правило, стёр.

Записал слишком общее правило про стиль кода. В итоге форматировал под него код, где этот стиль был неуместен. Снова открыл, переписал.

Главный урок: память живёт сама. Раз в неделю-две стоит зайти в папку и посмотреть, что Claude себе записал. Половина окажется лишней или устаревшей, четверть ещё актуальной, четверть реально полезной (особенно про клиентов и наших людей).

И этический момент: AI ведёт на меня досье. Текстовое, локальное, человекочитаемое. Это удобно, но я бы такое не отдавал в облако без проверки.

Уровень 3. Auto-compact, или что происходит, когда сессия становится длинной

Этот механизм ломал мне сессии раз пять, прежде чем я понял что это вообще такое.

Сценарий. Сидишь в одной сессии час-два, активно пишешь код. В какой-то момент Claude отвечает короче обычного, теряет контекст недавнего обсуждения, начинает повторно спрашивать то, что уже знал. В транскрипте видна строчка «Compacted (ctrl+o to see full summary)».

Это auto-compact. Когда контекст подходит к пределу окна, Claude Code пересжимает прошлую часть диалога в краткое summary. Вместо пятидесяти тысяч токенов истории остаётся пять тысяч пересказа. Сессия продолжается, но детали теряются.

Что теряется:

• Точные числа («у меня было 14 файлов» превращается в «несколько файлов»)

• Имена файлов и переменных, упомянутые мимоходом

• Договорённости в стиле «давай оставим этот вариант на всякий случай»

• Ход рассуждений (остаются выводы, теряются «почему»)

Что остаётся:

• Текущая задача

• Последние 3-5 сообщений целиком

• Список файлов, которые трогали

Чем можно управлять:

• /compact руками, до того как сожмётся автоматически. Тогда у меня есть управление, можно сказать «сожми, но оставь подробности про X»

• /clear, чтобы обнулить контекст полностью. Когда понимаю, что задача сменилась

• --resume при следующем запуске CLI, чтобы вернуться к предыдущей сессии с её историей

Мой выработанный подход: если чувствую, что обсуждение становится сложным и важным, делаю /compact сам, явно. После этого Claude помнит точно то, что я попросил его помнить, а не то, что показалось важным алгоритму.

И прямо противоположная стратегия: если завис в дебаге и Claude крутится вокруг неправильной гипотезы, делаю /clear. Чистый контекст бьёт богатую историю.

Уровень 4. Subagents, или память, которой иногда лучше не быть

Парадоксальный пункт. Иногда полезно не накопить контекст, а сбросить.

Что такое subagents. Это запуск отдельной мини-сессии Claude из основной, через тулзу Task. Я говорю основному «запусти агента типа debugger, дай ему вот эту задачу». Стартует новая сессия с чистого листа. У неё нет моих пятидесяти тысяч токенов истории, нет моих memory-файлов, нет CLAUDE.md (если я не передал явно).

Зачем это нужно:

• Чистый взгляд на проблему. Основной Claude уже зациклен на гипотезе, субагент смотрит свежо

• Параллельная работа. Запускаю одновременно три агента: один проверяет тесты, второй ищет дубли, третий пишет документацию

• Защита основного контекста. Если задача состоит в том, чтобы прочитать десять больших файлов и выдать резюме, лучше пусть это делает агент, а в основной контекст вернётся только резюме

Реальный случай. Я отлаживал баг два часа в одной сессии. Мы с Claude перебрали кучу гипотез, и каждая логически вытекала из предыдущей. Тупик. Запустил subagent через Task с одним простым промптом: «вот код, вот ошибка, что не так». Без всей нашей истории. Через четыре минуты ответ: проблема в порядке инициализации модулей.

Я бы сам не пришёл к этому. Был в плену своих двух часов рассуждений.

Цена: каждый subagent стартует с нуля, читает заново нужные файлы. Это плюс пять-двадцать тысяч токенов на старт. Не надо запускать subagent ради тривиальных задач.

Уровень 5. Внешняя память: hooks и MCP Memory

Самый мощный и самый рискованный уровень. Память, которая живёт за пределами Claude Code.

Hooks в settings.json. Это скрипты, которые срабатывают на события: pre-tool-use, post-tool-use, session-end. Я могу писать в файл-лог каждое действие Claude, а потом другая сессия может прочитать этот лог и понять, что было раньше.

Пример моего хука:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"$(date '+%F %T') $(jq -r .tool_input.file_path)\" >> ~/.claude/changes.log"
          }
        ]
      }
    ]
  }
}

Простая штука. Каждый раз когда Claude редактирует файл, дописывается строка в лог. Через неделю у меня вся история правок, отсортированная по времени. Можно скармливать новой сессии: «вот что я делал последнюю неделю, продолжай отсюда».

MCP Memory server. Отдельный процесс, который висит в системе и хранит факты в графе знаний. Claude обращается к нему через стандартный протокол MCP. Главное отличие от auto-memory: один и тот же MCP Memory виден всем проектам, всем сессиям. Это уже не «память про этот проект», а общая база знаний.

Что я туда выгружаю:

• Контакты и связи (кто чей менеджер, кто на каком клиенте)

• Долгосрочные факты о бизнесе

• Методические штуки (чек-листы, шаблоны)

Что не выгружаю:

• Любую персональную информацию

• Вообще ничего, что не должно лежать локально на компе год

Безопасность: и hooks, и MCP Memory это код, который выполняется автоматически. Если в hook написать rm -rf, будет выполнено. Если MCP Memory с открытым доступом смотрит в сеть, потенциальная утечка. Сначала тестируем на изолированных проектах.

Что когда брать

В сухом остатке

Из пяти механизмов сильнее всего меняет жизнь auto-memory. Это та самая магия, после которой возвращаться к «AI, который меня не помнит» уже неприятно. Но за магию надо платить вниманием. Раз в неделю чистить, иначе Claude будет следовать устаревшим правилам, и ты не сразу поймёшь почему.

CLAUDE.md и hooks. Старая школа, простая и предсказуемая. Их недооценивают, а зря.

Auto-compact живёт сам по себе. Главное знать, что он работает, и не удивляться, когда детали из ранних сообщений вдруг исчезают. Иногда сжимать руками через /compact лучше, чем ждать пока сожмёт алгоритм.

Subagents спасают, когда основной Claude застрял в гипотезе. Не каждую сессию, но в нужный момент экономят часы.

MCP Memory нужен только тем, кто строит долгие агентские системы. Большинству пока избыточен.

Теперь я каждый понедельник захожу в ~/.claude/projects/.../memory/ и читаю, что Claude про меня знает. Половину удаляю, потому что лишнее или устарело. Другую половину оставляю, она реально полезна. Когда AI начинает помнить, отношения с ним меняются.

И теперь я лучше понимаю того клиента, который год назад сказал: «Не хочу LLM с памятью. Я не готов к тому, что они помнят больше, чем я».